Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
Szerintem semmi. Olyan 50 hsz.-szel ezelőtt volt egy kisebb vita arról, hogy vajon kezdőknek jó-e a Visual Studiós IntelliSense, tehát hogy folyamatosan segít programozás közben. Kezdők szemszögéből egy bizonyos szempontból jó (egyből szól, ha para van), más szempontból nem biztos (nem biztos, hogy a fejébe verődnek a programozási alapelvek - vagy épp, hogy emiatt fognak, nyitott kérdés). Igazából nem egyértelmű, hogy jó-e vagy sem.
Sk8erPeter
-
dabadab
titán
válasz Sk8erPeter #1701 üzenetére
En annak idejen kockas papiron szamoltam a biteket, aztan az ertekeket kozvetlenul a memoriaba irtam, szoval tudom, hogy lehet igy is, de ezzel egyutt szerintem marhasag nem hasznalni az IDE-k automatizmusait.
DRM is theft
-
Vico87
tag
válasz pckownz #1696 üzenetére
C++ esetében nem indul automatikusan az Intellisense gépeléskor. Ctrl+Space kombóval lehet beindítani, vagy a beállítások között bekapcsolható, hogy gépeléskor egyből felkínálja a lehetőségeket. Ctrl+Shift+Space kombóval pedig függvények paraméterlistája kérhető (ha egy függvényhívás zárójelei között vagy). Azt vedd figyelembe, hogy nem lesz olyan pontos és gyors, mint egy Pascal vagy C# esetében, mert C++ nyelvet nehezebb feldolgozni.
-
Vico87
tag
válasz WonderCSabo #1705 üzenetére
Szerintem nem. Alapból gépeléskor nem, csak függvényhívás nyitó zárójelénél, tagpointernél (->) és scope operátornál. Azt külön kell engedélyezni (és alapból tiltva van), hogy úgy működjön, mint C#-nál, azaz bármit gépelsz, egyből felkínálja. Legalábbis eddig nekem VS2005 óta mindegyik alapból így működik (friss OS install utáni telepítéskor is, szóval joggal feltételezem, hogy ez a default).
Szerk.: C# esetén viszont az a default, amit mondasz.
[ Szerkesztve ]
-
ArchElf
addikt
Semmi baj nincs vele - az MS saját zárt könyvtáraiu miatt szokták ekézni. Ha kizárólag MS alá fejlesztesz, akkor nincs vele semmi gond.
AE
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
-
ArchElf
addikt
válasz Sk8erPeter #1709 üzenetére
Akkor pl. Qt.
AE
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
-
WonderCSabo
félisten
válasz WonderCSabo #1711 üzenetére
Bocs, lejárt a szerk idő.
Egyébként bmennyere IntelliSensenek hívja az MS, közel sem annyira intelligens. Az Eclipse kód kiegészítője sokkal jobb nála. És most természetesen nem arra gondolok, hogy nem bmi beíráskor ajánl fel dolgokat, mert azt be is lehet állítani... Ha az IntelliSensenél bhol rácsapok a Ctrl+Space-re, akkor mindig ugyanazt a listát dobja fel, amiben a találatok 99.99999%-a totál irreleváns az adott kódrészletre. Az Eclipse pedig felismeri, hogy éppen mit akarsz írni, és abban segít: végigiterálsz egy collectionon, vagy írsz egy felüldefiniált fvt, megvalósítasz vmi elcseszett generices fvt, tökmindegy, az Eclipse faszán kiegészíti, és azt írja le, amit éppen Te is akartál volna. Még a változónevek kitalálásában is segít, így konzisztens lesz a kód. Ezerszer jobb, mint ez az "Intelli"Sense.
-
Vico87
tag
válasz WonderCSabo #1712 üzenetére
Eclipse-t eddig csak Javara használtam, szóval nincs tapasztalatom a C++ képességeiről. Az igaz, hogy az Intellisense egy rakás "zajt" is felkínál, főleg, hogy ugye Windows alkalmazásoknál a windows.h miatt egy csillió deklaráció közül kell kikeresni a dolgokat.
Egy kis ideig használtam Code:: Blocks-ot. Ami tetszett, hogy kis egyszerű, minimalista a nagyágyúkhoz képest, viszont a kódkiegészítése nem a legjobb, ami miatt sokat kell gépelni.
-
n00n
őstag
Pont jól jött a kis vitátok, ugyanis pont most akartam kérdezni, hogy milyen IDE-t érdemes megnézni, ha a Code:locks kicsit "fapados" az embernek. Így most telepítem éppen az Eclipse-t, most azzal teszek egy próbát.
-
Davs
tag
nekem most a Qt creator IDE tetszik nagyon (autocomplete-tel egyutt, de van egy olyan gyanum, hogy csak Qt-t ismeri )
-
Sk8erPeter
nagyúr
válasz ArchElf #1710 üzenetére
Nem úgy értem, hanem hogy ezt írtad: "Ha kizárólag MS alá fejlesztesz, akkor nincs vele semmi gond." - mi a gond vele akkor, ha mégis VS alatt fejlesztesz más környezetre? Vagy platformfüggetlenül lefordíthatóvá szeretnéd tenni a kódodat?
A hsz.-edből úgy tűnt, tapasztaltál már komolyabb problémákat.
Mondjuk oké, azt a már-nem-emlékszem-melyik könyvtárat be szokta include-olni, az a hülyesége valóban megvan, de ezenkívül?(#1714) n00n : az Eclipse tényleg jó választás, már csak azért is, mert Linuxra és Windows-ra is van megfelelő változata, tehát ha épp másik platformra költözöl, akkor is használhatod a megszokott Eclipse-es környezetedet fejlesztéshez.
Vagy NetBeans.[ Szerkesztve ]
Sk8erPeter
-
dabadab
titán
A qtcreator is a .h-kbol meg a tobbibol szedi ossze a szukseges infot, szoval mukodik a kodkiegeszites mindennel (es a QT-t is csak onnan ismeri, szoval ha pl. nem includolod a QHash-t, akkor nem fogja tudni, hogy milyen metodusai vannak).
Egyebkent tudtatok, hogy QT-ben van foreach? Szoval a kovetkzo tok jol mukodik:
QHash<int, QString> stringHash;
.
.
foreach (const QString &s, stringHash)
qDebug() << s;[ Szerkesztve ]
DRM is theft
-
ArchElf
addikt
válasz Sk8erPeter #1716 üzenetére
A hsz.-edből úgy tűnt, tapasztaltál már komolyabb problémákat.
Nem tudom miből tűnt úgy a hsz-emből... (amúgy is azt ítam, hogy le fogják - nem hogy le fogom - harapni a fejét)AE
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
-
dabadab
titán
válasz Sk8erPeter #1716 üzenetére
"mi a gond vele akkor, ha mégis VS alatt fejlesztesz más környezetre?"
Nekem ugy tunt, hogy a "visual" resze csak MS dolgokat ismer.
"Vagy platformfüggetlenül lefordíthatóvá szeretnéd tenni a kódodat?"
Ez viszonylag problemas, mert nem tud makefile-t exportalni. Ha a VS-ben fejlesztett cuccot szeretned mashol is leforditani, akkor kenytelen vagy kulon, kezzel irni hozza makefile-okat.
Egyebkent meg tovabbra is qtcreator rajongo vagyok, mert annak rengetegsok elonye van, az egyik pl. az, hogy a shortcutok meglehetosen VS-kompatibilisek (es ha mar dolgozoban ugyis azt kell hasznalnom napi nyolc oraban, akkor ne kelljen az otthoni projektekhez valami tok masra atszokni).
[ Szerkesztve ]
DRM is theft
-
modder
aktív tag
válasz dabadab #1717 üzenetére
szerencsére már standard C++-ban is van
http://en.wikipedia.org/wiki/C%2B%2B11#Range-based_for-loop -
WonderCSabo
félisten
Hát sajna az Eclipse CDT azért közel sem annyira jó, mint a Java környezet, de azért a Code::Blocksnál valóban okosabb.
modder: Ezzel a foreach-el még én sem találkoztam, csak a Boost-os trükközös megoldással. És 4.6-os GCC már támogatja.
dabadab: Tudtommal nem is lesz finally.
[ Szerkesztve ]
-
modder
aktív tag
válasz WonderCSabo #1722 üzenetére
elég sok "új" feature van, amiket érdemes lenne átgyakorolni, hogy ne ragadjunk le a nyelv 10 évvel ezelőtti állapotánál. persze leginkább azoknak érdemes, akik aktívan használják.
-
válasz dabadab #1721 üzenetére
jaja, néztem is először, hogy ezt így hogy.
más: nyaralok, szóval találtam egy könnyű esti olvasmányt, Robert C Martin -- Clean Code című művét, ismeri valaki?
igazából ami nekem szöget ütött a fejembe, hogy az egy funkció - egy cél gondolatmenetet az extremitásig viszi, pontosabban nagyon rövid funkciókat ajánl. ami az olvashatóságot javíthatja, viszont sebesség szempontjából nekem eléggé problémásnak tűnik. másik oldalról persze az érthetőség/sebesség/kompaktság hármas korántsem egyértelmű problémakör, amíg elég gyors a program, addig igazából nincs baj.
persze a példákon keresztül (illetve saját tapasztalatok alapján is) indokolt a dolog, csak mégis... amire még gondoltam, hogy a compilerek elvileg eléggé sokat fejlődtek sebesség terén, funkcióhívások még mindig annyira kritikusak sebesség szempontjából, mint mondjuk 10 éve? elsősorban itt most nem olyan helyzetekre gondolok, ahol általában nincs szűk keresztmetszet a rendszerben végrehajtási sebesség szempontjából (tehát pl nem a grafikáért felelős részre egy játéknál).
Don't dream it, be it. // Lagom amount.
-
dabadab
titán
válasz proci985 #1724 üzenetére
Altalanos kodban - foleg desktopra szantban (de igazabol egyre inkabb mobilfronton is igaz) - nincs ertelme igazan a sebessegen meg a memorian gorcsolni, ha az ember nem csinal direkt okorsegeket, akkor nem lesz baj. Ha meg megis valahol feltunoen lassunak bizonyul, akkor meg az ember elokapja a profilert es optimalizalja azt az egy helyet, ami lelassitja.
En hajlamos vagyok maskepp latni a dolgokat, mert munkaidoban mondjuk a viruskereso engine CPU emulatorat pofozom es ha elvaras, hogy minden megtalalt .exe-t futtassa az elso par millio utasitasig, akkor ott tenyleg figyelni kell a sebessegre - ugyanakkor ha nem ilyen kod van, akkor sima C stilusu tomb helyett en is inkabb std::vectort hasznalok es magasrol teszek arra, hogy valamivel tobb processzorido meg memoria kell hozza, a gyakorlatban ezt siman behozza ott, hogy kenyelmesebb a hasznalata meg nincs buffer overflow.
DRM is theft
-
amargo
addikt
válasz dabadab #1725 üzenetére
"ha az ember nem csinal direkt okorsegeket"
Én azt vettem észre, hogy sokszor tisztában sincsenek azzal, hogy mit miért használnak, megszokták/így látták/csak mert és a kód már is borzasztó lassú lett.“The workdays are long and the weekend is short? Make a turn! Bike every day, bike to work too!”
-
Vico87
tag
válasz proci985 #1724 üzenetére
Én így gondolom: ha elfogadható egy felügyelt környezet (Java VM, .NET CLR) overheadje (és az üzleti/web alkalmazások esetében az, webes esetben a PHP-t nem is említve), akkor a C++ függvényhívások overheadje is elfogadható. Ezeknél az alkalmazásoknál a tiszta, karbantartható kód az elsődleges szempont.
Teljesítménykritikus esetben adott helyzettől függ, hogy mennyit vagyunk hajlandók áldozni az olvashatóságból/érthetőségből a teljesítményért. Néhány esetben megéri a mikrooptimalizálás, ahol már tényleg arra mész, hogy minimalizáld a cache-miss-t, az elágazásokat, stb... de ez általában nem triviális kódot eredményez és kevés esetben hoz látványos pluszt. Persze ha ezt a kódot megfelelően dokumentálod, akkor nincs gond.
A Visual C++ tud olyat, hogy __forceinline, ami egyrészt kierőszakolja egy függvény inline-osítását, másrészt így az optimalizáló jobb eredményt ad, mert a "hívást" a kontextusával együtt képes feldolgozni.
-
-
Vico87
tag
Ahogyan doc is rávilágított, csínján kell bánni az inline-nal. A különbség az inline és a VC++ __forceinline között az, hogy egyrészt előbbi szabványos, míg utóbbi nem, másrészt az előbbi csak javaslat a fordító számára (amit olyan esetekben, amelyekben nem lenne jó, figyelmen kívül hagy), míg utóbbival kifejezetten kéred, hogy mindenképp inline-osítsa. Mint mindennel a programozásban, jól végig kell gondolni, hogy mit csinál az ember, és ha jó indoka van rá, akkor nyugodtan használja. Nem jön és esz meg a raptor, ha leírsz egy goto-t, __forceinline-t, amennyiben jó okod van rá. Különben jön és megesz.
-
doc
nagyúr
"Nem jön és esz meg a raptor, ha leírsz egy goto-t, __forceinline-t, amennyiben jó okod van rá. Különben jön és megesz. "
b+
ezt viszem alairasba ha lehetamugy teljesen egyetertek, amig az ember nem teljesen biztos a dolgaban, ne akarjon okosabb lenni mint a fordito (valoszinuleg ugysem fog sikerulni )
-
Davs
tag
Hi!
Qt-ben tanulgatok es szeretnek egy olyan programot irni, ami atirja a gomb szoveget, ha felemegyek a kurzorral..
Szoval van egy QMainWindow-om, benne egy darab PushButton-nal..
Ami eloszor az eszebe jutott, hogy irni egy void MainWindow::mouseMoveEvent(QMouseEvent *event){} fuggvenyt, amiben nezem a gombom x,y poziciojat, szelesseget, magassagat es lenyegeben irok egy szimpla collision-detection-t ra. A kerdesem, hogy ez-e a helyes megkozelites, vagy van ra valami direkttebb megoldas?
(itt nem a szovegvaltason van a hangsuly, hanem hogy az egyes Widgetekre tudjak mouse-eventet irni akar kulon-kulon..Javaban pl listener objektumokat kellett irni, de az mar regebben volt, el is felejtettem )[ Szerkesztve ]
-
doc
nagyúr
nem helyes
vannak ra megoldasok, en pl ugy csinalnam, hogy letrehoznek egy osztalyt a gombnak, aminek csinalnek egy enterEvent(QEvent* event) { setText("mouseover");} es egy leaveEvent(QEvent* event) { setText("mouse out"); } metodust
ezeket az esemenykezelo meg fogja hivni a megfelelo alkalmakkor (egerkurzor fole kerul, illetve elmegy rola)[ Szerkesztve ]
-
Davs
tag
szerintem most nagyon mellenyultam ezzel az otlettel igy :
mainwindow.cpp
#include "mainwindow.h"
#include "ui_mainwindow.h"
#include <QDebug>
#include <QtCore>
#include <QtGui>
class button : public QPushButton {
public:
button(QWidget *parent = 0);
void enterEvent(QEvent *event);
void leaveEvent(QEvent *event);
};
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
j=0 ;
ui->setupUi(this);
button xy ;
xy.show();
}
MainWindow::~MainWindow()
{
delete ui;
}
button::button(QWidget *parent)
: QPushButton(parent)
{
setText("default");
}
void button::enterEvent(QEvent *event){
setText("over");
}
void button::leaveEvent(QEvent *event){
setText("off");
}de nem jelenitodik meg a gomb
[ Szerkesztve ]
-
bucsupeti
senior tag
válasz CoolBoy323 #1396 üzenetére
bocs
[ Szerkesztve ]
"Nem gond ha nem vágod a párologtatók bináris nyelvét..."
-
válasz WonderCSabo #1734 üzenetére
ezt én is így tudom, ahogy olvastam a compilerek ezen a téren eléggé sokat fejlődtek.
dabadab: köszi az észrevételeket, egy sor dologban megerősítettél.
sebesség tényleg lehet kritikus, az általad leírt probléma pedig különösen érzékenynek tűnik.
Vico87: köszönöm Neked is.
picit igazából rácsodálkoztam, hogy pár év alatt milyen hatalmasat változott a szemlélet, avagy az architektúra (és a különböző patternek) mennyire fontossá váltak. ugyanez a tesztelhetőségre is igaz.
[ Szerkesztve ]
Don't dream it, be it. // Lagom amount.
-
Gyuri16
senior tag
van egy makefileos projektem amit linuxon fejlesztek, es most kellene belole egy windowsos exe-t varazsolnom (amit el tudok masnak kuldeni, es tudja futtatni minden tovabbi nelkul). mi erre a legfajdalommentesebb megoldas? windowson eddig csak dev c++t hasznaltam, talan ez is megeszi. oldalan olvasom, hogy a futtatashoz kell az MSVCRT.DLL, ami szerinte ott van minden mai windowson, van ezzel tapasztalatotok?
Nem vagyok egoista, csak uborkagyalu!
-
Gyuri16
senior tag
válasz dabadab #1742 üzenetére
"van linux ala is"
ha ezt tudom fel oraja.. atbootoltam windowsba, amit kb felevente hasznalok, es ilyenkor felsir az osszes program, hogy elhanyagolom oket. jo par percig eltart, mire hasznalhato a gep.ha cygwinnel forditom, akkor az rendesen futtathato lesz mas rendszeren cygwin nelkul?
mindenesetre kozben sikerult dev-c++t ravenni, hogy leforditsa, ez is mingw-t hasznal, ha minden igaz, szoval remelem jo lesz
Nem vagyok egoista, csak uborkagyalu!
-
Davs
tag
Hali!
Most olyan dolog erdekelne, hogy a compile sebessege mitol fugg? i3-2330M-es notim van 8GB ram tarsasagaban egy 64bites win7 / arch linux-szal. Qt-ben kisebb projektek is neha 10++ masodpercig fordulnak(annyira nem veszes, de szeretnek javitani rajta), lehet, hogy a HDD fogja vissza a teljesitmenyt? Egy SSD kihatna a compile idore is?[ Szerkesztve ]
-
dabadab
titán
Nezed forditas kozben a CPU terhelest, ha alacsony, akkor az IO lassitja.
Mivel ugyis van 8GB-d, viccbol csinalhatsz egy RAM drive-ot is es kiprobalhatod, hogy hogyan hat a sebessegre, ha ott van a forras meg a QT-s headerek.szerk: meg lehet, hogy nincs bekapcsolva a parallel make, ha qtcreatort hasznalsz, akkor menj a Projects fulre, ott a Build beallitasok, a Make-nel nyomj a Detailsre es a Make argumentshez ird be hogy pl -j4 - enne hatasara egyszerre negy szalon fog futni a forditas.
[ Szerkesztve ]
DRM is theft
-
Davs
tag
válasz dabadab #1749 üzenetére
Ha 2magos+ht == nagyjabol 4 magos a gepem, akkor nem -j5 -ot kell megadni? szoval j(magok szama+1)?
Amugy Qt-s headereket hogyan lehet mozgatni? Windows Path-ban nem lattam jelet nekik, meg azt se tudom pontosan merre keressem oket G:\QtSDK-ba lett telepitve a Qt, a headerek a Desktop/qt/../include konyvtarban vannak? Igy elsore talan a lib, bin es include mappakat is jo lenne odadobni, nem?
Új hozzászólás Aktív témák
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- sziku69: Fűzzük össze a szavakat :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Láncfűrész topik
- Samsung Galaxy A54 - türelemjáték
- Politika
- Futott egy Geekbench kört egy új HTC készülék
- LG 34GS95QE-B: OLED paneles, ívelt gamer monitor
- Az USA nem akarja visszafogni Kína növekedését
- Kerékpárosok, bringások ide!
- PlayStation 5
- További aktív témák...