C/C+: Hogyan kell jól csinálni?

 ( medvetalp | 2009. december 12., szombat - 2:00 )

Üdv mindenkinek!

Kb. a címben olvasható a kérdésem. :)

Programoztam már más nyelveken, és az alapfogalmakkal meg az oop szemlélettel is tisztában vagyok. Most szeretnék C-vel és később C++-al (tudom, tudom teljesen máshogy kell a dolgokat bennük) is foglalkozni. Első körben csak a C-vel.

A gondom az, hogy amennyire látom, sok lehetőségem van rosszul megoldani a dolgokat. Szeretnék néhány kört megtakarítani és mindenekelőtt az alapvető lépéseket magabiztosan és helyesen alkalmazni. Van olyan doksi/tutorial, vagy bármi ami a követendő eljárásmódot ismerteti a különféle szituációkban? Legjobb online lenne, de persze könyvajánlatnak is örülök, ha úgy vélitek azok jobban segítenek ebben. Kezdetben az elemi dolgokat szeretném megtanulni, jó példákat látni pointerek, adatszerkezetek és memória helyes kezelése, i/o, file-ok, socket-ek, párhuzamos végrehajtás témában, hogy csak hirtelen párat mondjak...

Egyelőre sok a homály és a bizonytalanság.

Volt már szó az ittani topic-ok közt a témáról, de szeretnék általánosan, összefogottan is beszélgetni erről, talán hasznos útbaigazítás lesz másoknak is és ez a bolygó majd jobb hely lesz mindnyájunk számára.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Elso ! eheheh

Nehez altalanossagban beszelni arrol amit kerdezel. Tapasztalatom alapjan a jo programozas szinte nyelvfuggetlen. OO szemlelet is mukodik Cben (fuggveny pointerek, callbackek), megha joval korlatozottabban is mint az ezt tamogato nyelveknel. Ugyanazt a kenyelmi szintet nem fogod persze megkapni. De ha a problema megkivanja, nyugodtan hasznalhatod. A hatekonysag is elegge hasonlo elveken nyugszik mint mas nyelveknel: lehetoleg zero copy, lazy init, stb...

Cben is ugyanaz az aranyszabaly van mint mashol: modularitasra torekedni (pl az elso amivel talalkozni fogsz nagy esellyel az a dinamikus tomb igenye - erdemes kulon megcsinalni, aztan mar csak hasznalod).

Amiben masabb mint a menedzselt nyelvek az ugye a szemetgyujto hianya. Erdemes tiszta szabalyokat teremteni modulok kozott, hogy ki felel adott memoria foglalasert es ki felel annak felszabaditasaert.

Amiket emlitesz (socketek, fajlok, stb), azoknak megvannak a rendszer szintu APIjai, ott sokat nem lehet varialni. Hasznalod es kesz. Amit te magad epitesz fel, ott sokkal inkabb erdekesebb a kerdes hogy mit hogyan.

Mivel Cben inkabb magan a nyelven lehet szepen elcsuszni (foleg az elejen, kesobb ezzel mar nem lesz gond), egy igazan jo C referenciat ajanlanek elso korben, annak fogod talan a legtobb hasznat venni. Sajnos oszinten szolva igazan jot nem ismerek; majd ajanlanak biztosan sokan valamit :)

Amit meg tudok javasolni ha most indulsz neki, sokat tud segiteni egy vizualis debugger (pl gdb es ddd paros *nix alatt) es egy futasi ellenorzo (pl valgrind). Ezekkel egyreszt gyorsabban megtalalod a kezdeti hibaidat, masreszt latni fogod miken lehet elcsuszni es nem a kodbol meg konyvekbol kell kibogaraszni.

Ez az alap: The C++ Programming Language by Bjarne Stroustrup
Ez a másik, ami fontos: Effective C++ by Scott Meyer
Ezeken kívül még egy könyvtárral is érdemes megbarátkozni. Én a Qt-t javaslom.
--
http://www.naszta.hu

Fontos a sorrend betartasa. Nagyon.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Hát ha most kezd a nyelvvel megismerkedni akkor én azért nem a Stroustrup féle könyvvel kezdeném.

A C++ bizonyos szempontból gazdagabb nyelv, mint a C. Ennek megfelelően bonyolultabb és sokkal nehezebb is jól programozni. A Bjarne könyv állat, a nyelv minden eszközéről meg lehet tudni belőle, hogy mire használható, miért van a nyelvben. A "Thinking.." könyvekben meg sok olyan dolog van, hogy mit hogyan érdemes/szabad használni, hogy normálisan működő programokat írjunk. Jópár dolog nekem nem nagyon tűnt addig fel, amíg nem olvastam róla (csak legfejlebb nem értettem, hogy miért nem úgy működnek dolgok, ahogy én gondolom).
Még egy - méltatlanul keveset emlegetett - forrás van szerintem, ami rengeteg C++-ban való programozással kapcsolatos kérdésre ad egyértelmű vagy nem annyira egyértelmű :) választ. Ez a C++ FAQ Lite. Ha valaki túlesik a nyelv alapjain meg szintaktikáján, tudja hogy mi az, hogy OOP, operator overloading, templates, stb., akkor a FAQ Lite az egyik legértékesebb információforrás C++ programozás ügyben a neten.
"Dúrva" vagy nem annyira triviális dolgokat lehet még látni a Boost-ban is, meg azt használni is érdemes, ha valami feladathoz tud segíteni.

A lényeg az, hogy el kell kezdeni programozni.

A C++, Qt párosítás szerintem is jó kezdés.

Természetesen kezdetben nem fogsz olyan programot írni, amire 20 év múlva is büszke leszel.
Az egyetemista programjaimat én sem mutogatom, pedig nagyon sokat tanultam belőlük.

Én Commodore 64 assembly után váltottam C-re (C64-en!), utána C++-ra, ez pedig igencsak mély nyomot hagyott bennem.
A C64-et/DOS-t nem lehetett szépen programozni, csak gányolás volt minden. Ezt modern operációsrendszereken nem lehetett folytatni.

Évek kellettek, míg a 8 bites marhaságokat kinőttem (a változónév ne legyen 6 karakternél hosszabb, mert egy sorban max 80 karakter lehet, 32k lehet maximum a forrásfájl mérete, lehetőleg mindent kódot 1 fájlba írj, mert az 1541-es floppy kegyetlen lassú, meg egyébként sem tudsz egyszerre 2 fájlt szerkeszteni, 64k-nál nagyobb memóriát farmalloc-kal kell lefoglalni, char far * -gal lehet címezni, oda kell figyelni, hogy 32767-nél az INTEGER túlfordul,...).

Ebből a szempontból előnyből indulsz, mert a rosszat eleve nem tanultad meg. Viszont hazudnék, ha azt mondanám, hogy a C64/DOS ártott nekem.
A gondolkodásmódomban sokat segített, csak a megtanult hibás beidegződéseket kellett levetnem.

64k-nál több memóriát biztosan nem foglaltál le semmivel C64-en ;))

az ügyesebbek biztos tudtak swap-pelni Commodore-on is. :)

Kazettara :)

----------------------
while (!sleep) sheep++;

Nem feltetlen. diskre is lehet.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"overlay"-nek hívtuk.

> Sol omnibus lucet.

1. Tedd fel magadnak a kérdést: jó lesz-e neked egyáltalán a c, c++ ?
Itt a hatékonyságot fontosabbnak tartjuk a gyors programkészítésnél , de cserébe felvállaljuk, hogy veszélyesebb az eszközünk, a programozónak kell figyelnie és észben tartania dolgokat, amiket más nyelv alapból ad. Így gyorsabb és kevésbé memóriazabáló kódot tudunk írni.
Ez lényegében a "profi liga", ami sok tanulást és lassabb kódfejlesztést igényel, vagyis sokkal többet kell adott feladat megoldásához a gép előtt görnyedned majd. Fel van készülve erre? Ne pocsékold az idődet, az élet túl rövid: ha ez mégsem a te világod, ne vágj bele.

2. Szerintem C-vel ne szivasd magad. Csak c++ -al foglalkozz, mert a C++ sokkal gyorsabb programfejlesztést tesz lehetővé, és mára C-re csak egészen szűk területen lehet szükség (beágyazott eszközök,linux kernel, elavult C-s GUI könyvtárak és kb itt ki is fújt).
példa: egy adatstruktúrát rendezett dinamikus tárolóban kell tartani, oda beszúrni, törölni, abban gyorsan keresni stb. C-ben ez 1-2 napos küzdelem, mire jól fog működni, c++ -ben 1-2 perces.

3. Ne legyél elfogult, ne hirdesd, hogy a c, c++ mindig a legjobb választás, mert ez nem igaz. A feladatod ugyanis a munkahelyeden nem az, hogy programozz(gass), hanem hogy elfogadható minőségű terméket állíts elő minél olcsóbban. Nem tökéleteset, hanem elég jót, ami jobb, mint a tökéletes. Ehhez néha el kell fogadni, hogy néha a c, c++ fejlesztés túl lassú.

4. Manapság a nyelv jó könyvtár támogatás nélkül semmi. A c filozófiája az, hogy szinte semmi könyvtárat nem ad. A c++ -ban belátták, hogy ez így tragikus, és legalább az STL-el adtak alap tároló osztályokat. De ez ma még mindig elég kevés. Én is a Qt-t javaslom: ingyenes, multiplatformos, jó minőségű, GUI-ra is nagyszerű.

> legalább az STL-el adtak alap tároló osztályokat

Az STL-t matematikusok írták, nem programozók. Gondolom a matematikusok használni is tudják, de programozásra teljességgel alkalmatlan.
:)

Hat, remelem ezt csak viccnek szantad. :)

A templatek es az OO teljesseggel ortogonalis koncepciok, ez is a C++ egyik szepsege es nehezsege.

----------------------
while (!sleep) sheep++;

Nem viccnek szántam:

Hihetetlen nehézkes a kezelése.
Iterátorokkal kell össze-vissza bohóckodni indexek helyett, az std::string használhatatlan (próbálj meg vele unicode-ba, vagy UTF-8-ba kódolni,
vagy r=1 műveleteknél bonyolultabbakat csinálni, nem beszélve arról, hogy rengetegszer kell char* -ra kasztolni).

Ha a Qt-t megnézed, nem azért nem használja az STL-t, mert nem tudná, hanem mert egyszerűbb volt nekik saját használható osztályokat létrehozni,
mint az std::string-gel, std::vector-ral,... pepecselni.

Vannak OpenSource projektek (Wesnoth), amik használják az STL-t, de nem irígylem őket érte. A Wesnoth is néhány STL-es osztályt újraírt, hogy használni lehessen valamire.

Ha a MFC-nek, Qt-nek, C#-nak, STL-nek, Java-nak összehasonlítod az azonos osztályait, az STL messze a leggyengébb.

Szerintem az iteratorok jo dolgok, amugy meg a legtobb helyen (igaz nehezkesen, de) van lehetoseg indexek hasznalatara.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"Iterátorokkal kell össze-vissza bohóckodni indexek helyett"

Láncolt listát indexelni? Te most biztosan viccelsz. Iterátorokkal lineáris, indexeléssel négyzetes az elérés.

És mennyivel gyorsabb FIFO-nál vagy stack-nél (konstans idejű beszúrás és törlés a sor elejére és végére). Arról nem is beszélve, hogy nem másolgatja folyton a memóriát. Ha nincs szükség index-re, nagyon gyorsan el kell felejteni a vector-t és list-et kell használni. Aki csak index-el tud bánni, az ne C++-ozzon. Szerintem. :)
--
http://www.naszta.hu

Alapvetően az iterátorokkal nincs bajom. Az STL-es iterátorokkal viszont igen. Ha a 9. elemet törölnöm kell, akkor:

list.erase( list.begin() + 9 );

Nekem indexre van szükségem és mégis iterátorral kell marháskodni. Ez a problémám.

list.eraseAt( 9 )

Nem természetgyógyász vagyok, hogy rituális szent szövegek mormolásával írjak programot, hanem programozó. Iterátorokat akkor kell használni, ha iterálni akarok, indexeket akkor, ha indexelni.

A kettőt nem akarom keverni.

De ez azért van így, mert a listában tényleg nincs index. Ha látod leírva így a kódot, akkor azonnal tudod, hogy nincs index, hanem operátorral dolgozol, tehát észnél kell lenni.

Nincs ezzel baj. :)
--
http://www.naszta.hu

Azert igazabiol illene befogni a szankat, mert nagyon sok framework implementalta mar ezt a dolgot.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Simán implementálom magamnak, ha kelleni fog. :D
--
http://www.naszta.hu

Ok, igazad van, tévedtem:

vector.erase( vector.begin() + 9 );

kell

vector.eraseAt( 9 )

helyett.

A vectorban van index, mégis iterálni kell.
- a beszúráshoz is iterátor kell, index helyett
- nem beszélve a push_front hiányáról
- szerintem a vector eleve felesleges, list-tel kellene mindent megoldani

Az STL-lel alapvetően az a fő bajom, hogy kényelmetlen.
Nyugodtan implementálhatták volna az eraseAt-et 3 sorban. Úgyis template és nem foglalja a helyet a generált kódban feleslegesen. Rengeteg ilyen kényelmi 3-soros kimaradt.

A hash-tábla hiánya viszont nagyon komoly baj.

Nem elsősorban a meglévő kóddal van bajom, hanem ami kimaradt. Így félkészen diplomamunkaként tartom számon az STL-t.

> - szerintem a vector eleve felesleges, list-tel kellene mindent megoldani
hat ha kurvalassura akarsz csinalni mindent, de akkor feleslegesen pazarlod az idodet c++al, a java vagy c# sokkal nagyobb produktivitast kinal, ha a sebesseg nem szamit.

> Az STL-lel alapvetően az a fő bajom, hogy kényelmetlen.
I beg to disagree. szemely szerint a kombinalhatosaga es bovithetosege miatt messze a leg-kenyelmesebb container frameworknek tartom.

> Nyugodtan implementálhatták volna az eraseAt-et 3 sorban. Úgyis template és nem foglalja a helyet a generált kódban feleslegesen. Rengeteg ilyen kényelmi 3-soros kimaradt.
igen, rengeteg kimaradt, es ki is fognak maradni. ez egy tervezesi dontes volt.

> A hash-tábla hiánya viszont nagyon komoly baj.
Nem ertem miert lovagol ezen mindenki. 555 hashtablat tudsz letolteni a googlebol 10 perc alatt, hasznalhatod amelyik neked tetszik. STL kompatibiliseket.

> Nem elsősorban a meglévő kóddal van bajom, hanem ami kimaradt. Így félkészen diplomamunkaként tartom számon az STL-t.
Azert erdekes diplomamunka amibol eleg sokan ledisszertaltak mire elkeszult, es koncepcioban lassan 15 eve etalonnak szamit :-)

Jogomban áll nem használni és ha lehet, meg is teszem.
Ez a szép a szoftver iparban, hogy lehet választani. :)

Sőt, ha már hash-tábla implementációt úgyis be kell szerezni, akkor miért is ne cseréljük le teljesen az STL-t?

mi lecsereltuk :-)

Több százezer soros rendszereket fejlesztünk 95%-ban c++ -ban, mert a teljesítmény nagyon számít.
Röviden: besz@rnánk, ha nem lenne STL.

Annyira nagyon sokat könnyít az életen, hogy csak sajnálni tudom azokat, akiknek nem ilyen eszközökkel kell dolgozniuk. A Qt-ben is nagyon haszonló egyébként a tárolók koncepciója.

Az iterátorokról: abban mi a bonyolult, ha a pointert más néven nevezünk, de ugyanúgy kell használni? Nem értem. A vektor, map indexelésére pedig ugyanúgy használható az index.

Az std::string az tényleg rossz, a QString mindent visz, majdnem tökéletes.

De összefoglalva: a konténerek félelmetesen jól használhatóak.

Ha csak parancssorban operálsz angolul, akkor az is király. :)

Meg olyanokkal szép játszani még, hogy ++iter az gyorsabb, mint az iter++, mert így implementálják az iter++-t: :)


Iter operator++(int)
{
Iter tmp(*this); // store the old value in a temporary object
++*this; // call pre-increment
return tmp; // return the old value
}

--
http://www.naszta.hu

és ez miért baj? egyszerű tárolókra, pl vector::iterator ez pointerekkel egyenértékű, vagyis 2-3 gépi kódú regiszterben tartott értékkel megoldható. Teljesítmény veszteséged semmi a pointerhez képest.

De nem csak egyszerű tárolók vannak. :)
--
http://www.naszta.hu

ha STLrol beszelunk, akkor a compiler mindent inlineol, es valojaban az it++ es a ++it ugyan azt a kodot fogja generalni(szo szerint), sot, ha azt csinaljuk, hogy *it=lofasz; ++it; vagy azt, hogy *it++=lofasz; akkor is ugyan az lesz a vege.

Hát ha sok a kód, akkor vagy kicseréli, vagy nem. Ilyen szempontból például a GCC elképesztő dolgokra képes.

http://www.cppreference.com/wiki/stl/iterators
--
http://www.naszta.hu

hat mi is beszarnank ha csak olyan lassu szarok allnanak rendelkezesunkre mint az STL, de szerencsere van helyette sajatunk :-)

+1

Azért nem mindent éri meg lecserélni és erősen compiler függő a sebesség is. Én a dll felületek miatt kerülöm Windows alatt, de tapasztalatom szerint főleg a fordítás idő növekszik meg miatta jelentősen, a teljesítményükkel nincs baj.

Ráadásul - ebben talán egyet értünk - szemléleti szempontból elsajátításuk kötelező. Aki nem ismeri őket, nem biztos, hogy jó saját környezetet épít.
--
http://www.naszta.hu

remek szemlelet, csak tul altalanosak a tarolok. a mi taroloink is teljesen STL kompatibilisek, csak arra amire mi hasznaljuk jobbak. a mai remek compilerek mellett mar igazan gyerekjatek egy stl tarolo megirasa, megis alig latok ilyeneket, pedig gyakran jol jonnek.

szerk: a forditasi idovel nekem csak a verlazitoan lassu visual studio c++ compilerrel van bajom neha, de ha barmilyen mas, tisztesseges fejlesztesi kornyezetet hasznalsz, ami tud parhuzamosan forditani, akkor csak vegyel procit meg ramot. joval olcsobb mint a te idod.

Nem tapasztaltam, hogy a VS sokkal lassabb lenne. És a 8.0 és a 9.0 (2005 és 2008) alatt tudtam párhuzamosan fordítani. Személy szerint én még Linux-os dolgokat is szivesebben írok alatta, az intellisense miatt. Lehet kövezni! :)
--
http://www.naszta.hu

intellisenset en is imadom, illetve nem is az intellisenset, hanem a VisualAssistX intellisense replacementjet. ezert vagyok hajlando elviselni a compiler sebesseget is :-(
amugy itt egy 3Ghzes Core2-n a MS compiler visual studioval kb 2x lassabb a linux/gcc/bjam kombonal.

Egyébként a fordított kód - nálam - gyorsabb MS alatt, úgyhogy én úgy voltam vele, hogy biztos ezért fordít lassabban. (Több időt áldoz optimalizációra.)

Mondjuk ha a kód sebessége nagyon fontos, akkor mindig az intel compiler a nyerő nálam. Hála Istennek, bele lehet varázsolni a VS-ba. :)

Újabban - mivel egy G5*-öt bírtak alám adni - megbarátkoztam a KDevelop-pal is. De jobb a VS. :)

*Debian-nal hajtom. Aki látta már az XCode-ot belülről, szerintem tudja miért... :)
--
http://www.naszta.hu

jah, az MS compiler kicsit gyorsabb kodot fordit.
xcode meg egy rakas fos, ha epp nem visual studios napom van, akkor VIM :->

Amit gyorsabbra meg lehet irni, azt meg fogjak. Emiatt szuletik sok STL "varians" is. Ennyi.

"hat mi is beszarnank ha csak olyan lassu szarok allnanak rendelkezesunkre mint az STL, de szerencsere van helyette sajatunk"

add meg légyszíves a munkahelyed telefonszámát
azonnal szeretnék ott dolgozni, ahol belefér a havi munkaidőbe az alapeszközök több platformon, több compileren való újrafeltalálása, tesztélese, betanítása...
ilyet meg csak akadémiai környezetben láttam, iparban sose

Miert kene tobb platformra es tobb compilerre megcsinalni? Arra a platformra es compilerre kell megirni, amit hasznalnak.

mi több platformra és több compilerre fejlesztünk egyidejűleg.
ha most feltalálsz valami alap osztályt, ami esetleg valami partikuláris jelentőségű tesztben gyorsabb, azt ki is kell tesztelned N platform K fordítójával.
Ezt nem lehet felvállalni, ezért használjuk az általában mindenhol kielégítő minőségű standard STL-t, aminek tesztelését mások már elvégezték.

Mi mérnökök vagyunk, nekünk az elég jó az jobb mint a tökéletes.

" az általában mindenhol kielégítő minőségű standard STL-t"

Az STL melyik implementaciojat? Amit a GNU-sok csinalnak? Vagy amit masok? Implementacio es implementacio kozott is hatalmas lehet a kulonbseg.

Csak extrém estben éri meg lecserélni, általában a compilerrel/rendszerrel érkezőt szoktuk használni. Oka: ennyivel több a hordozott könyvtár, az meg sok platformnál nem praktikus.
--
http://www.naszta.hu

biztos nem lattal meg olyan helyet ahol 10^-6s szinten optimalizalnak, igazabol rajtunk kivul en sem.

Nalunk clocktickre optimalizalas is van, bár igazából c fordító által generált asm kódot kézzel, szóval gondolom az nem ér :)

az is szep muveszet :)

hat akkor a te esetedben neked nem jo az stl, no problem.
Mi a teljesitmeny problemakat inkabb GPU-val probaljuk megoldani.

azok nekunk nem jok :-(

"ilyet meg csak akadémiai környezetben láttam, iparban sose"

Az ipar huzza a vilagot, nem az akademia. A szabvanyositas is kabe az ipar utan kullog vagy annak osvenyet hinti elore; azok a piacvezeto cegek akik ezeket iranyitjak, azoknal ezt bosegesen meg fogod talalni. Kar, hogy ilyenben meg nem volt reszed, tenyleg jo dolog :)

Az std::string keveset tud. Talán még nagyobb gond, hogy az STL többi része nem használja, ezért állandóan kell a c_str().

A konténerek rendszere, az iterátorok, meg az egész algorithm rész egyszerűen jó. A baj az vele, ami a C++-szal is. Egy kezdőnek kényelmetlen.

Vannak persze dolgok, melyek kényelmi szempontból nagyon hiányoznak (boost::range, Qt-féle kényelmes fv-ek, c++0x lamba expressions, stb), de azért vegyük észre, hogy egy 98-as szabványról beszélünk. Egyrészről probléma, hogy ilyen ritkán kerülhetnek új dolgok a nyelvbe, másrészről pl az MS-nek mikor sikerült egy szabványos C++ fordítót/STL-t összehoznia? 2005-ben?

Az STL nem tökéletes, nem is igyekszik minden kívánságnak eleget tenni.
Az idő, és a a kialakult programozási gyakorlat rámutatott a hiányosságokra. Ezek '98 előtt nem feltétlenül voltak ismertek, az egész generikus programozás új volt.

A széles körben ismert, és elfogadott problémák egy részét megoldották a TR1-ben, egy másik részét a C++0x-ben fogják.

Egyesek iterátorok körüli picsogása meg egyszerűen nevetséges.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

+1 de nagyon :) (a második mondat kivételével, csak a stream osztályokban kell char*, az meg nem is része az stl-nek...)
----
Hülye pelikán

Ok, az C++ Standard Library, aminek az STL része. A lényegen nem változtat.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

+1 de nagyon!

"Ezek '98 előtt nem feltétlenül voltak ismertek, az egész generikus programozás új volt."

Ada, 1977

--
NetBSD - Simplicity is prerequisite for reliability

ML, 1952 :-) Amugy az Ada csak a 85os szabvannyal vezette be nem?
talan abban viszont megegyezhetunk, hogy a C++al kezdett igazan mainstreamme valni a generikus programozas.

allitolag alapbol benne volt es mondhatjuk, hogy mainstream programnyelv
mindegy, csak arra probaltam ravilagitani, hogy ezek a ficsurok mar osregen leteztek (es benne is vannak sokkal jobban osszerakott nyelvekben) es c++ nem hozott semmi ujitast :p

--
NetBSD - Simplicity is prerequisite for reliability

" ficsurok mar osregen leteztek (es benne is vannak sokkal jobban osszerakott nyelvekben) es c++ nem hozott semmi ujitast "

Te most vagy a C++-t nem ismered, vagy a többi nyelvet.
(Azt mondani, hogy az ada generics mindent tud amit a template-ek (azaz a template rendszer "nem hozott semmi újítást"), hát, khm., merész.)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

"Te most vagy a C++-t nem ismered, vagy a többi nyelvet.
(Azt mondani, hogy az ada generics mindent tud amit a template-ek (azaz a template rendszer "nem hozott semmi újítást"), hát, khm., merész.)"

Ez is merész állítás.

Adában nincs template metaprogramming, a generics nem Turing-teljes (tehát önmagában egy mindenre alkalmas programozási nyelv, csak győzze a fordító), ellenben ott a sablon-szerződés modell, hogy ránézel a sablon specifikációjára és már akkor tudod, hogy az általad használandó típussal vajon működni fog-e a kód. Elég csak a sablonparamétereket ismerni, már megvan ez az információ. C++ esetén viszont csak akkor tudod ezt biztosan, amikor végignézted a teljes sablon forráskódot, amit felhasználsz. Ha ezek valamelyikében van olyan, amit az aktuális típus nem támogat, akkor nem fordul le, de ez a sablon paramétereiből még nem derül ki. És az is lényeges, hogy az Adával ellentétben nem a teljes sablont fordítja le a C++ fordító ehhez a típushoz, hanem csupán a ténylegesen meghívott függvényeket. Az, hogy a maradék függvényekben milyen nem támogatott műveletek vannak, az egyáltalán nem számít.

"Ez is merész állítás."

Ez nem tudom mire vonatkozott, ugyanis sehol sem írtam, hogy a C++ template mindenben több mint az Ada generics. Azzal vitatkoztam, hogy "nem hozott semmi újítást".

Valóban nincs explicit sablon-szerződés modell. Egy darabig nem is lesz, a C++0x tervezetből alig két hónapja dobták ki.

"Az, hogy a maradék függvényekben milyen nem támogatott műveletek vannak, az egyáltalán nem számít."
Az, hogy ez előny vagy hátrány szerintem szemlélet kérdése.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

"""
"Az, hogy a maradék függvényekben milyen nem támogatott műveletek vannak, az egyáltalán nem számít."
Az, hogy ez előny vagy hátrány szerintem szemlélet kérdése.
"""

Látom, te is kicsit másképp érted, amit írok, mint én a tiedet :) Semmiféle előnyről vagy hátrányról nem beszéltem, csupán arról, hogy ha egy sablon esetén bizonyos részeket nem használ fel a rá épülő program, akkor ott bármilyen szintaktikailag helyes kód állhat, mivel azt úgysem akarja lefordítani a fordító.

Tevedsz, a C++ template metaprogramok Turing-teljesek.

----------------------
while (!sleep) sheep++;

Hol írtam, hogy nem azok?

Sehol nem irtad, en neztem felre. Elnezest.

----------------------
while (!sleep) sheep++;

-- nyomorult bongeszo --
----------------------
while (!sleep) sheep++;

-- nyomorult bongeszo --

----------------------
while (!sleep) sheep++;

csak erdekessegkeppen: c++ -ban bizonyos szinten kikenyszeritheto a szerzodes modell, csak ra kell allitani egy fv pointert ;)

Mutass egy példát!

Látom, végülis megoldható, csak míg az Ada esetén egy sorban megvan az alprogram megadása, esetleg egy teljes képernyőnyi (24+ sor) kell ugyanahhoz C++-ban.

Erről szól a C++: mindent lehet, emiatt nagy a nyelv, így bizonyos dolgok körülményesebbek. A sablonszerződés olyan, mint a funkcionális nyelvek vagy a rossz vodka: tisztán nem finom. Elméletileg jól hangzik, és szűk területen okés, de általánosan nem az igazi. No meg ha nem fordul le a kód az miért nem elég sablonszerződés kényszerítés?

----
Hülye pelikán

Ada 83 inkább :)

Ok, az alapok már léteztek. Azért a C++ template rendszere sok szempontból jóval több mint az Ada generics.

Itt elsősorban arra gondoltam, hogy pl template metaprogramming, meg a fordításidejű "kódfuttatás" jóval a szabvány megjelenése után jelent meg.
(Érdemes nézegetni a boost-ot, hogy miket képesek megcsinálni template-ekkel.)

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Fentebb írtam, hogy viszont a C++ legalább egy lényeges szempontból sokkal-sokkal kevesebb, mint az Ada generics (sablon-szerződés modell)

Eredetileg ezt írtam:

"Azért a C++ template rendszere sok szempontból jóval több mint az Ada generics. (Más szempontokból pedig kevesebb)"

Aztán a zárójeles megjegyzést töröltem, mivel úgy ítéltem meg, nem hordoz többlet információt, ugyanis a "sok szempontból" eleve kevesebb mint a "minden szempontból".

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Tudod a C++ pontosan azért lett népszerű, mert nem az egyetemen találták ki a professzorok, hanem az ipar szülte, szükségből. Azaz pontosan azt tudja, amit (amikor kitalálták) tudnia kell. Azért került bele a template, mert akkor ért meg a generikusság a mainstream használatra.

Az meg, hogy a sablonszerződés... persze, papíron, matematikus fejjel jól néz ki. Gyakorlatban a template is tesz egy implicit sablonszerződést, amit vagy a fordító ellenőriz, vagy megírja kommentben/doksiban a template írója, hogy mihez mit kell tudnia a típusnak, és te leszel okos. Mindenesetre megvannak az igen nagy előnyei a dolognak (pl list-t is tudsz rendezni, de ha nincs < akkor is használhatod a konténert), a hátránya pedig (az én gyakorlatomban) elhanyagolható. Nem matematikusoknak készült. Amúgy az ada is szép nyelv, csak nem arra, amire a C++.
----
Hülye pelikán

? Matematikusok??? Na ne...

Mi köze van a matematikának meg az adának egymáshoz? Ja, tudom, ami a C++-nak és a matematikának.

Komolyra fordítva: az adát arra tervezték, hogy kritikus helyeken fusson, ahol nem engedhető meg az, hogy egy hibára az legyen a válasz, hogy "Ja tényleg, erre nem gondoltam, hiszen lefordult...". A fordító igyekszik a lehető legtöbb hibát kiszűrni (nyelv tervezési sajátossága), vagy figyelmeztetni. Sokkal szigorúbb nyelv, mint a C++, erősebben típusos.

"(pl list-t is tudsz rendezni, de ha nincs < akkor is használhatod a konténert)"

Ja, mert alapból az std::less-t használja, ami meg a "<" operátort. De bármikor írhatsz sajátot (funktor osztály).

Minél szigorúbb a nyelv, annál közelebb van a matematikához. Mármint annak mai modelljeihez, mert természetesen bármire lehet modellt adni, de a mostani algoritmizálási, programozáselméleti, akármilyen modellek erősen korlátozottak. Az ADA ezzel a szigorúságával közelebb áll ezekhez a modellekhez értelemszerűen. Igen, pont azért, hogy könnyebb legyen ellenőrizni és nehezebb legyen hibázni. Ettől még egy igencsak mesterséges nyelv: azt mondta a kormány, hogy legyen, és lett. A C++ mögött is van tervezési elgondolás, de sokkal inkább ad-hoc nyelv. A templatek körül pont nem értem, mi a gond a fordítással, rusnya fordítási hibákat kapsz, ha valami nem jó, az ADA meg megmondja konkrétan, hol/mi a baj, de egyik sem fordul le rossz kóddal. A template-k többet engednek, sok ezek közül persze megoldható máshogy is (például két listet írsz, egy simát meg egy sortable_list-t, de azért ez rusnya).

A list-es példámat nem érted úgy látszik. Arról beszéltem, hogy ha van két dolgod, amit nem tudsz/akarsz rendezni (pl mátrixok), akkor is beleteheted a listába, hiába van sort()-ja, ami az std::less-en keresztül az operator<-t használja, mert ugye nem is próbálja lefordítani. Csak ennyit mondtam.
----
Hülye pelikán

> nem az egyetemen találták ki a professzorok, hanem az ipar szülte, szükségből

Szabványt fejleszteni úgy nem lehet, hogy mindig hozzáadogatok valamit, amire éppen szükségem van. Az nem szabvány, hanem gányolás.

Ahhoz, hogy a C++ szabvány legyen:
- le kellett ülni, összegyűjteni az implementálandó feature-öket
- kitalálni egy olyan keretrendszert, amelybe logikusan be lehet illeszteni
- és konzisztens is legyen

Ez nem rutinmunka volt, hanem komoly agyi erőfeszítést és gondolkodást igényelt. A C++ szabvánnyal nekem semmi bajom nincs, azt értelmesen átgondolták, konzisztens, használható.

Az STL sajnos nem így sikerült. Ahogy az std::string-gel kapcsolatban is leírták, konvertálni kell néha char *-ra, mert az STL egyes részeinek arra van szüksége. Ahogy esett, úgy puffant, inkonzisztens, gányolás.

Itt kellett volna egyetemi tanároknak leülni és átgondolni, hogy mit hogyan csináljanak, akkor nem ez lett volna a végeredmény.

Jopar szabvany a meglevo implementaciokat dokumentalja, van ami abszolut takolas, van ami szinte a hazi feladat szintjen mozog es termeszetesen vannak nagyon jol megirtak is. Ugyanaz a tortenet, mint barmely mas teruleten. :-) Azert hogy a c++ egy roppant atgondolt es konzisztens valami lenne, haat... inkabb az ipar ize jobban erzodik rajta :-)

Ráadásul ha egy roppantul átgondolt és konzisztens valami akart volna lenni, akkor a c-vel való kompatibilitás kapásból ugrott volna..

Stroustrup igen komolyan átgondolta, és úgy vélte, hogy soha a büdös életben senki nem használná, ha nem lenne relatíve kompatibilis a C-vel. Márpedig hiába csinálsz egy jó nyelvet, ha senki nem hasznjálja. Hidd el, hogy a nyelv elég komoly tervezés során lett ilyen.
----
Hülye pelikán

Tobb olyan nyelv is van, amit kevesbe terveztek meg, meg kevesbe gondoltak at, valamint abszolute nem kompatibilis a C-vel, cserebe milliok hasznaljak. Csak egyet emlitenek meg: PHP. Akkortajt is volt ilyen, csak akkor BASIC-nek hivtak.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

És ezek közül melyik az, amelyik a C területén (rendszerprogramozás, akkoriban még alkalmazásfejlesztés) erős? A BASIC-nek nem véletlenül ez a neve, pont ahogy pacalt is sokan használnak mert ezt tolják sok suliban még mindig (akkor már tanítanának ADA-t), úgy a BASIC-et is nehezen hagyta ott sok ember, ha már megtanulta. Ettől még.

Én kizárólag a C++ vonatkozásában mondtam, hogy a C kompatibilitás igen fontos alapelv volt, nem mondtam, hogy jó nyelvnek az az alapja. Jó nyelvnek tartom például a szísárpot, oszt mégse kompatibilis. Sőt, hogy okosat mondjak, a Fortran se (nem tudom, feltűnt-e, hogy mindkét nyelv szintén kényszer szülte).
----
Hülye pelikán

Felreertheto volt. Egyebkent meg szerintem is vannak pontok, ahol jobb lett volna, ha elvetik a C-vel valo kompatibilitast, egyszerubb lenne a hasznalat. Legalabbis en koca c++ proggerkent igy latom, aztan lehet, hogy ha bovebb lenne a tudasom, belatnam, hogy nincs igazam.

Mindenesetre en elsosorban arra reagaltam, hogy stroustrup (nincs elottem, hogy kell helyesen irni a nevet...) ugy gondolta, a kutya nem hasznalna majd ha nem lenne C kompatibilis. Erre reagaltam azt, hogy szerintem igazabol mindenki magasrol, ha amugy egy tok jo nyelvet es platformot talalnak ki, like PHP, Perl, Ruby, etc. Jo, jelen esetbe a C kompatibilitas miatt sokan racuppantak, de szerintem ha nem lett volna C kompatibilis, akkor is megvettek volna, marcsak azert is, mert a Pascal-nal lenyegesen tobbet ad - szerintem. Marpedig abban az idoben nem volt tul sok _elterjedt_ nyelv.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Szerintem nem ilyen egyszerű. Igazából a C++ nagyon sokszor (szinte mindig) C-s szolgáltatásokat fed el (nézz meg egy new és egy delete implementációt). Ráadásul mivel a legtöbb OS felülete C (vö.: POSIX, Win32 API stb.), muszáj közel lenni hozzá, a teljesítmény érdekében. Szerintem nagyon sokszor a C++ csak kényelmi funkció. Tipikus példa a legtöbb mutex locker osztály. Én a C++ erősségét a típusosságban, a template-ekben és az objektum kezelés szabadságában látom. Pont e miatt a nagy szabadság miatt lehet nagyon nehéz is. :)

Ráadásul: általában azt a 100 sort, ami kritikus, azt egy függvényen belül végzed, legfeljebb inline tagokkal, ergo C-ben.

Én egyébként nem tudom megítélni, hogy mennyire vagyok expert. 10 éve programozom C és/vagy C++ környezetben. Valamit nagyon jól tudok használni (STL, Qt, VTK, ParaView és néhány rendszerhívás Win32 ill. POSIX alatt), más könyvtárakat meg csak nagyon mérsékelten ismerek. Tudja a fene.
--
http://www.naszta.hu

Sajnos GUI fejlesztésre nem a legalkalmasabb a C++.

A QT-s signal/slot kezelést ki kellene terjeszteni standard C++-ra is, hogy ne kelljen precompilerekkel/moc fájlokkal ökörködni.

Nem kellene a QT-s változatot 1-1-ben átvenni (az is hack), de maga a signal/slot mechanizmus fontos lenne.

A C# ugyan csinált megoldást erre, de messze nem olyan kényelmes, mint a QT-s. Érthetetlen számomra, hogy a QT idősebb, mint a C#, a Microsoft mégis olyan megoldást választott, ami igencsak messze van az optimálistól.

A C++-ra ráférne egy specifikáció frissítés.

:)

Csak kotozkodes: Qt.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

libsigc++.
az egyetlen amit nem sikerult megertenem a QTbol, hogy miert eroltetik a sajat ratyi preprocesszoros signals&slots implementaciojukat amikor van mar pure C++ megoldas, ami tudasban tokeletesen lefedi, es ki is terjeszti azt :-(

ratyi, lol :)
ilyen erovel mondhatnad, hogy minek vannak benne widgetek, hiszen az van a gtk-ben, wxwidgets-ben, sot motifban is
vagy minek bele containerek, hiszen azok vannak az stl-ben
minek bele IO osztalyok, mikor ott az iostream
stb
en speciel orulok, hogy a Qt egy nagyon jol hasznalhato, szinte mindent lefedo csomag, igy nem kell 1000 kulonfele libet hasznalnom, hanem eleg egyet, ami egy eljesen konzisztensen felepitett rendszer

hat igen, eleg ratyi :-)

A Qt doksiban egész érthetően le van írva, miért erőltetik.

Egyrészről tudásban nem fedi le tökéletesen (autoconnect, asynchron connect), másrészről a moc nem csak a signal-slot-ról szól, hanem a MetaObject systemről, ami nélkül a QtScript, illetve még egy csomó minden nem működne olyan kényelmesen/szépen ahogy.

Lehet nem szeretni, de attól még nem hülyeség...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Jo, hat vegulis minden valamirevalo nyelv C szolgaltatasokat fed el, ez igy akarmire is igaz lehet, gondolj bele, a legtobb oop nyelvben van new (=memoria allokalas), es mindegyik implementaciojaban valahol ott van vagy egy malloc(3) hivas, vagy valamilyen memoria heap-rol valo kiosztas. Ehhez speciel nem szukseges C kozelinek lennie, a runtime-nak kell a C szolgaltatasok fole API-t nyujtani.

A legtobb OS felulete C, ez igaz, ugyanakkor szerintem a mai gepeken nem sokat nyom a latban az, hogy direktbe hivogatom, vagy valamilyen wrapperen keresztul. Jo, nyilvan a teljesitmenykritikus dolgoknal celszeru direkt C-ben hivogatni, de nagy altalanossagban boven elegendo az, ha valamilyen wrapperen (peldaul Qt-n, vagy akar Ruby-n at) hivogatja ezeket az ember. Ma mar annyira keves a direkt C-s hivas szuksegessege, hogy a legtobb esetben elhanyagolhato.

Szerintem az expert-seg elsosorban a tapasztalaton mulik, es nem a lexikalis tudason. Ha te 10 eve programozol, akkor igencsak jartasnak kell lenned a C++-ban. Tehat kimerited a "tapasztalt programozo" fogalmat :-)
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Igazából C-t és C++-t csak teljesítmény éhes helyen érdemes használni. Ha csak kell egy GUI és alap dolgok, akkor a Java vagy a C# sokkal jobb választás. Gondolkodom is a Java megtanulásán, mert gyorsabb benne összehányni az egyszerű cuccokat. Viszont C++-t relatíve tudom, úgyhogy nekem most gyorsabb ezekre is a Qt. Fene tudja, hogy mikorra szánom rá magam.
--
http://www.naszta.hu

Ha csak GUI kell, akkor is inkább C++ Qt mint Java swing/awt. (Az véleményem szerint konkrétan szar).

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Viszont hamar kesz van benne barmilyen GUI.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Qt-ban is... Főleg szerkesztővel. A QtDesigner szép és letisztult kódot generál, semmi hátrányod nem származik abból, ha szerkesztőt használsz.
Ezt semmilyen más általam látott framework-szerkesztő párosítás nem tudta produkálni...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Nekem elsosorban a c++ a problemam, szerintem sokkal nehezkesebb nyelv a Java-nal, de ez persze inkabb szubjektiv velemeny, mintsem objektiv tenymegallapitas.

Framework-szerkeszto: VB6 melle egesz jo szerkesztot csomagoltak anno :-)
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ha már RAD eszközről beszélünk, akkor a Delphi 5,6,7 verziót semmi nem űberli. :)
Talán a Visual Studio már ott van azon a szinten.

Akkor nezd meg ezt:
http://www.youtube.com/watch?v=wDN_EYUvUq0

majd rajossz hogy a "szep" java (es a libjei) valos enje neha azert kiszivarog ;) Tanulsagos :)

A nyelv valóban sokkal egyszerűbb, mint a C++. Az előadás meg az API-ról szól főleg. Az meg abszolút nem nyelvfüggő, hogy az API-ja milyen.

Mondom java ES libjei. Ez sztem abszolut ugyanaz mint az:
"Az előadás meg az API-ról szól *főleg*" (kiemeles tolem).

De szolj ha tevedek.

Az en kommentem viszont a nyelvrol, es nem az API-rol szolt. Szoval nem, nem tevedsz, csak epp kevesse related amit irsz.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Igazából erősen related. Mivel az API, a könyvtárírási képesség határozza meg, mennyire lesz hosszú távon élő a nyelv. Mert a végén szinte mindig arra bontódik le a kérdés, hogy melyik nyelven van kielégítő implementáció, ergo jó könyvtárakat kell írni. Ez pedig erősen függ a nyelvtől, amiben a Java sok helyütt fail (a C++ is, más helyeken).
----
Hülye pelikán

Ertelek, viszont a Javat mint nyelvet konnyu megtanulni, mig a c++ -t sokkal-sokkal nehezebb (eleg csak a tobbszoros oroklodesre, a virtualis fuggvenyekre, a szazfele castolasi modra gondolni, de mondhatnam a konstruktor-destruktor koruli teendoket is — es most nem API-rol, csak es kizarolag a nyelvrol beszeltem). De ez persze szigoruan IMHO.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Abszolút igazad van, hogy nehezebb megtanulni, sokkal "nagyobb" nyelv.
De a nehézkesség egy másik fogalom. Az sokszor pont a nyelv egyszerűsége miatt jön elő, mivel körülményes megoldani benne egy problémát, ha nem biztosít eszköztárat hozzá. Itt már előjön az API kérdés.
----
Hülye pelikán

Igazából a C++-t becsületesen megtanulni évek kérdése. Cserében viszont nincs olyan mélység, amíg el nem mehetsz. Amíg pelyhes az állad, addig egy jó könyvtárra tök jól rá építkezhetsz pl.: Qt, ahol ha az objektumok szüleit beállítod, még a memóriával sem kell vesződnöd a legtöbb osztály esetében. Aztán ahogy borul el az agyad, egyszer csak azt veszed észre, hogy saját stream osztályokat írogatsz log-nak STL alapon, saját allokátorral stb. Én éppen a VTK-ba vagyok "szerelmes", jól eltalált rendszer ahhoz, amivel éppen foglalkozom.
--
http://www.naszta.hu

Ez elmondhato a Java-rol is, el lehet kezdeni pl. Swing-gel vagy JSP-vel, a vegen azt veszed eszre, hogy performance tesztereket irogatsz, vagy eppen servlet containert.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

... sikerült kétszer felvinnem a kommentet, bocsi ...
--
http://www.naszta.hu

szerintem tobb programot irtak delphi-ben meg visual basciben, mint c++-ban, de igy statisztikat nem tudnek idezni

--
NetBSD - Simplicity is prerequisite for reliability

azert nem mindegy, hogy ideszamoljuk-e a hatvanotezredik Nibbles-klont, vagy sem
'komoly' cuccok szerintem nagyobb szamban keszulnek/keszultek C++-ban mint Delphiben vagy VB-ben

Megis mennyire meltatlanul mellozotte valtak, foleg a VB. Bar az MS most nagyon felturbozta az uj VB 9.0-t mindenkepp meg akarom majd nezni.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A PHP szabványosítva lett?

Azért kérdezem, mert az SXW is vissza lett dobva, az ODF szabványt meg azóta sem sikerült az ooo-nak 100%-ig implementálni.

A C# Windows formja sem szabvány, szemben a C# nyelvi elemeivel, ahol az MS-nek kellett gyúrnia, hogy rendes szabvány lehessen.

Pont erről szól a D nyelv, és lám nem is használja senki.

Csak McHalls cinizmusára reagáltam; alapelv a C-kompatibilitás, ez érződik is rajta, de anélkül nem beszélnénk most C++-ról.
És pont azért, mint amit te is mondasz, még mindig sokkal több annál, mintsemhogy egyes hobbiprogramozók:P "jobban összerakott nyelvek"-et emlegessenek :)

Hee, en nem is voltam cinikus :>

Azt meg plane egy szoval sem mondtam hogy jo vagy rossz lenne, csak azt, hogy ez erzodik rajta. :-)

+1

Annyi megjegyzésem lenne az Ördög védelmében, hogy a VS2008 viszont már tartalmazza a tr1-et is, tehát már egész jól halad az MS a szabványokkal. :)
--
http://www.naszta.hu

Az on vedence azonban szamos egyeb vadpontban is alaposan gyanusithato, szoval ez nem oszt es nem is szoroz, tisztelt ugyved ur.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

hasznaltad komoly fejlesztesre? ha nem, akkor inkabb maradj csondbe, nem kell mindenben expertkedni

nekem muszaj volt par honapig vs-ban dolgozni, soha nem ert el nalam olyan szintet a fuck/sec mint abban az idoben... iszonyat...

Vannak alapveto dolgok, amik nekem nem annyira jonnek be, ugyhogy meg hobbifejlesztesre se igen hasznalom, ha nem VB-be programozok. Sokkal jobban bejon a NB, barcsak lenne komplett .Net package hozza VB-vel.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Hát, az stl tele van hiányosságokkal.

Hozza magával a 80-as évek struktúráit. Próbálj meg írni egy allocatort, meglátod miért.

A string elavult, kényelmetlen.
vector képtelen a memóriát dealloc-álni.
deque-nál nem tudod megadni a blokkok méretét.
vector indexelése lassú (legalábbis az általam próbált implementációkban).
Az iteratorok koncepciója (mégpedig, hogy az iterator két elem közötti határra mutat és nem az elemre) elvileg szép, de a gyakorlatban életszerűtlen koncepció.
Hiányzik a hash_map a hivatalosból.
Nem tudsz a konténerekből származtatni a nem virtuális destruktor miatt.
Allocator-t csak template-es koncepcióval tudsz írni, és ez kizár egy csomó alkalmazási területet.

Soroljam még? Sajnos sok esetben érdemes megírni a konténerek egy részét. Nekünk van saját vector, list és string osztályokat felváltó cuccunk, mondjuk mi embedded platformra is dolgozunk.

> vector képtelen a memóriát dealloc-álni.
vector v(500); // ez egy 500 elemu vektor
v.swap(vector(200)); // ezutan mar csak 200 elemu lesz a v
regi trukk :-)

> Az iteratorok koncepciója (mégpedig, hogy az iterator két elem közötti határra mutat és nem az elemre) elvileg szép, de a gyakorlatban életszerűtlen koncepció.
Az iteratorok nem elemek koze, hanem az elemekre mutatnak, illetve ket nem letezo elemre (az elso elottire, es az utolso utanira).

> Hiányzik a hash_map a hivatalosból.
Jah, hianyzik. szerencsere van igen sok public domain hash_map, amibol lehet valogatni, illetve a TR1ben is benne vannak mar.

> Allocator-t csak template-es koncepcióval tudsz írni, és ez kizár egy csomó alkalmazási területet.
Jah, az allokatorok eleg hasznalhatatlanra sikerultek :-S

Ezt a swap-os trükköt nem ismertem. Vicces. :-)

Ezt írod:
"Az iteratorok nem elemek koze, hanem az elemekre mutatnak, illetve ket nem letezo elemre (az elso elottire, es az utolso utanira)."

Ez sajnos tévedés. Az iterator koncepció mögött az van, hogy list.end() ugyanaoda mutat, mint a list.rbegin(); illetve a list.rend() ugyanoda mutat, mint a list.begin(). Ebből pedig következik, hogy az iterator az stl-es designer asztalán nem az elemre mutat, hanem az elem előtti határra.

Ezt tudni kell, hogy ne szopjuk be a reverse_iterator-okkal.

a list.end() egy invalid elem, a list.rbegin() pedig egy valid elem.
a list.begin() egy valid elem, a list.rend() pedig egy invalid elem.
nem ugyan oda mutatnak. az implementaciorol nem tudok nyilatkozni, valszleg mindenki maskepp csinalja, ahogy azt mar a meltan hires es elismert LGT is megzenesitette.

Lehet, hogy nem értesz.

Az iterator nem az elemre mutat (persze így használjuk, mintha oda mutatna), de az stl-t tervező think tank az iterator jelző nyilacskát nem az elemre rajzolta, hanem két elem közé.

Hogy a rend() es begin() ugyanoda mutatnak, az gyorsan belátható ezzel a tesztprogrammal:


#include
#include

int main() {
std::vector< int > v;
for ( int i=0; i < 5; ++i ) {
v.push_back( i );
}
printf( "begin():%d \n", *(v.begin()) );
std::vector< int >::iterator i = v.rend().base();
printf( "rend():%d \n", *i );
}

Természetesen a v.rend() egy invalid elemet jelentő iterator.
Azonban nem az elemre mutat, hanem az elem mögé.


v rend()............v rbegin()
| 0 | 1 | 2 | 3 | 4 | lista vége
^...................^ end()
begin()

ezzel szepen bemutattad, hogy az rend().base() epp oda mutat ahova a begin(), ami nem is meglepo, mivel a base() tudva levoleg shifteli az iteratort.
a nyilacskak pozicioja pedig csoppet sem erdekel, jo regen volt mar amikor meg rajzolgattam ilyen diagrammokat. az STL 101-es kurzus utan feleslegesnek erzem.

Az rbegin() a 4-re hivatkozik, az rend() a -1-re (az nincs), a begin() a 0-ra, végezetül az end() az 5-re (az nincs).

Az end() és az rend() mindig az utolsó utáni elemre hivatkozik, különben nem lehetne megállapítani bejárókkal, hogy a tároló üres, valahogy így: begin() == end() és rbegin() == rend().

Látom mindenki használt már iteratort és reverse_iteratort. :))

Amiről beszélgettünk és nem értünk egyet - szerintem - abszolut elméleti kérdés. Mindannyian tudjuk, hogy hogyan kell használni ezeket az osztályokat. Viszont nem értünk egyet azzal, hogy mi járt a fejükben azoknak, akik kitalálták ezt a shit-et.

Amúgy onnan indultunk ki, hogy mi van elkúrva az stl-ben, és szerintem az iterator-kezelés több helyen is nem eléggé praktikus. Mondhatnék más példákat is, hogy miért fos: pl. nem lehet elkérni az utolsó valid elemet kényelmesen iterator-ként. Az más kérdés, hogy ez teljesen más koncepciót igényelne.

A back() és az rbegin() fv. miért nem elég Neked (az utolsó elemre és iterátorra)? :S
--
http://www.naszta.hu

Szepen kerlek, mutass egy olyan fuggvenyt, ami az utolso valid elemre mutato iteratort visszaadja. Az rbegin() reverse_iterator-t ad vissza, a back() pedig elemre mutato referenciat.

Akar nevetseges ilyeneken hoborogni, akar nem, nekem ez kenyelmetlen, cserebe naponta kell hasznalnom.

azert nincs ilyen fuggveny, mert nem biztos, hogy van utolso valid elem. egy ilyen esetet csak kiveteldobassal lehetne ellenorizni, es az STL interfeszeket ugy terveztek, hogy az at() metodusokon kivul(amit direkt kiveteldobasra tettek oda) _semmi_ nem dob kivetelt. hat ezert nincs. nem tudom miert volna kenyelmesebb mindenfele szar kivetelkezeloket tenni a kododba :-(

Aha. És a begin()? Az sem mindig valid. Oda nem írsz kivételkezelőt?

nem, mert akkor bele sem lepek a ciklusba :-)

Joejszaka: &lt; es &gt; < >
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

inkabb <code> tag

code taggal volt, de a tabot beszopta. Bocsika.

Lenyegtelen, a forummotor megeszi a <code> tagok kozti < > jeleket.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Szerintem nagyon szépen használható a C is ha megírod magadnak az alapvető adatstruktúrákat, vagy GLib-et esetleg más libraryt használsz. A GLib különösen jó, mert sok dologot meg lehet csinálni vele rendszerfüggetlenül.
C++ elkezdését nem javasolnám C tanulás nélkül, szerintem csak káoszhoz vezet.

Franc se akar meg egy lancolt listat irni az std::list helyett, mondjuk..

----------------------
while (!sleep) sheep++;

+1

Az is a jó programozó ismérve, hogy nem találja fel a spanyol viaszt. Ezzel az erővel kezdj írni compiler-t assembler-ben...
--
http://www.naszta.hu

A c++-hoz kell egy kis C, ezzel egyetertek. Hogy strukturakat nevezzunk el objektumoknak, na azzal viszont nem. Ismerem en is a Glib-GObject vilagot, nezegettem is, de nekem ez nagy eroszaknak tunik. Inkabb maradok a c++ mellett; lassabb talan a forditas, de szebb a kod es jobb a vegeredmeny.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Szerintem erre érdemes egy pillantást vetni: http://library.gnome.org/devel/glib/unstable/glib-data-types.html
Gyakran használt adatstruktúrák implementációi, semmi GObject nincs benne, szépen használhatóak, gyorsak, _minimálisak_. Egy nagyobb projectnél ahol szükséges az OO valóban lehetséges, hogy inkább c++-t kellene annak választania aki GObjectet fontolgatja, de egy láncolt listához nem kell GObject a GLib-ben sem, nyugodtan használhatod. Ha nem tetszik a GLib használj mást szerintem akad sok más adatstruktúra implementáció.

http://library.gnome.org/devel/glib/unstable/glib-data-types.html -> ez gányolás. Ezért szeretem sokkal jobban a Qt-t.
--
http://www.naszta.hu

Mi ebben a gányolás? Nem tudom, hogy lehetne ezt jobban megcsinálni c-ben, ha te tudod nyugotan írd le, engem érdekel. Azonban ha szerinted a c-ben minden gányolás abban az esetben ez a vita tárgytalan.

Nem. Az ganyolas, hogy eronek erejevel szeretnenek emberek objektumorientalt dolgokat tenni egy olyan nyelvbe, ami nem objektumorientalt. a g_list_add(lista, elem) helyett mennyivel szebb mar az, hogy lista.add(elem) ? Soot, lista << elem !
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Semmivel nem szebb. De: ha Gizikéke container-be bele tudok pakolni Gőzekét (hiba üzenet nélkül), az engem zavar, mert ezt ellenőrizhetné a compiler is.
--
http://www.naszta.hu

C-ben is megoldható a típusok ellenőrzése pl. a GLib függvényeinek becsomagolásával, amik belül persze cast-olnak ezerrel. De ez a megoldás nem mérhető a C++ nyújtotta biztonsághoz.

A kérdés inkább az, hogy a becsomagolósdi megoldás esetleg nem elegendő-e bizonyos esetekben. Pl. ha többmillió példányban eladott beágyazott kütyüben az OOP kerülése miatt az ember olcsóbb procit, esetleg kevesebb RAM-ot is beépíthet, legyártott darabonként megspórolhat mondjuk 5-10 Eurót.

De pl. GUI-s asztali alkalmazásoknál vagy üzleti logikánál általában sokkal jobban megéri "rendes" megoldásokat alkalmazni. Ha sebesség- vagy memóriaprobléma van, azt általában máshol kell keresni.

Egy mai PDA 600Mhz-ről indul és 1GHz környékén fejeződik be. Ráadásul ha normálisan le van kódolva a program, és a jó minőségű a compiler, akkor az osztályok overhead-je sem jelentős vagy szinte nincs is kód szintjén már ezeken a gépeken sem. Szerintem lassan eljött az ideje annak, hogy nyugodtan lehet ilyeneket rakni kis gépekre is. (Ld: Qt-t Maemo-n és S60-on.) Ráadásul a típusbiztosság például elsősorban a compiler-nek többletmunka, az meg úgyis normális vason megy (jó esetben).

Viszonyításképp: 2001-ben 550Mhz-es PIII-ason 512 MB RAM-mal ment az XP normálisan, aztán ezek a kézi OS-ek azért jóval csupaszabbak, mint egy asztali XP.
--
http://www.naszta.hu

Akkor gcc-vel nem biztos, hogy érdemes fordítani.
Volt egy elvetemült, aki megnézte a gcc által fordított kódot és komoly kérdéseket rakott föl, ilyeneket hogy a "MOV ECX,0" minek kell, ha a fordított kód az ECX-et egyáltalán nem használja,...?

Persze lehet, hogy azóta javítottak valamit, de a vak bizalom nem biztos, hogy célravezető.

:)

Intel 386-ra a sorrend, sebességre (csak arra!) az én progimnál (bő egy éve): intel compiler 10.0, MS compiler 8.0 SP1, (amíg szórakoztam ezzel a bug halmazzal) Borland 6.0 compiler és csak a legvégén a GCC. Mivel Win alatt gyakorlatilag csak az MS-t használom mostanában, lehet, hogy változott a sorrend.
--
http://www.naszta.hu

http://www.hwsw.hu/hirek/43631/intel-ftc-monopolium-antitroszt-per-processzor-piac-amd-nvidia.html

"A többször hallott panaszokhoz azonban újabbakat is csatolt az FTC, amely szerint az Intel titokban úgy alakította át fordítóprogramjait, hogy a versenytárs processzorok teljesítményét rontsa. A vállalat azt állította a vásárlóinak és a közönségnek, hogy a szoftverek gyorsabban futnak a saját chipjein, de azt nem tette hozzá, hogy ez részben vagy egészben a fordítóprogram kialakításának köszönhető."

Ha ez igaznak bizonyul, akkor bojkottálom az intel compilert. :S
--
http://www.naszta.hu

Ez régóta ismert, volt is egy patch ami a binárisból kiszedte a CPUID-s részt, és ettől AMD gyorsult pár százalékot...

http://techreport.com/discussions.x/8547

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Smartphone, PDA, netbook, laptop, desktop... szoftverfejlesztés szempontjából manapság nem nagy a különbség köztük. De van azért alsóbb kategóriákban is élet és ott jól jöhet a GLib.

Ezzel azt akartad mondani, hogy a Qt nem alkalmas sebesség/memórialimitek betartására?
----
Hülye pelikán

a Qt-ben vannak olyan mechanizmusok, amik pont a sebesseg/memoriahasznalat teren segitenek nagyon sokat (pl. implicit sharing)
regebben en kimondottan utaltam a Qt-s programokat a sebesseguk miatt, amig ra nem jottem hogy ha az ablakkezelo inditasakor betoltom a Qt-s libeket, akkor villamgyors minden :)

Pont ezt mondom én is, hogy az "alsóbb kategóriák"-ra is tökéletesen alkalmas lehet a Qt, mivel amúgy eléggé hatékony... legalábbis én képfeldolgoztam vele, és villámgyors volt, pedig az eléggé cpu/memória igényes cucc...
----
Hülye pelikán

Nono, én nem azt mondom, hogy a Qt nem villámgyors. De ha mondjuk egy mini HiFi cuccot építesz, ahol a stringkezelés kimerül az USB-s eszközök fájlrendszerének kezelésében és az MP3 tag-jeinek olvasásában, akkor oda vagy statikusan allokálsz memóriát (egy konytár max. 1000 fájl, max. 50 hosszú fájlnév, 50 hosszú együttes név, 50 hosszú szám cím -> 150kB) vagy dinamikusan, amire a GLib-féle GString nagyon jó. Ebben az esetben a fenének kell Qt, C++ meg Linux. GLib, C és lecsupaszított NetBSD jobb választás.

Ez már erősen súrolja a beágyazott rendszer kategóriát, attól függetlenül, hogy te valószínűleg egy hagyományos számítógéppel gondoltad (amennyiben nem, úgy méginkább), de amit a C tud azt tudja a C++ is, ki lehet kapcsolni a kivételkezelést, minden más csak akkor vesz erőforrást, ha használod. Kapsz cserébe erősebb típusellenőrzést, STL-t, template-ket, konstruktorokat/destruktorokat.
Természetesen ilyen helyre felesleges a Qt, de a feljövő okostelefonokról volt szó emlékeim szerint, ahol általános célú feladatokat kell megoldani.
----
Hülye pelikán

Akkor kiemelnék néhány mondatot feljebbről:

"többmillió példányban eladott beágyazott kütyüben"

"Smartphone"... "De van azért alsóbb kategóriákban is élet és ott jól jöhet a GLib."

Tehát pont smartphone alatti kategóriájú beágyazott rendszerekre gondoltam, sőt, le is írtam.

> Kapsz cserébe erősebb típusellenőrzést

Kell a fenének. Tudom, hogy stringeket raktam be a láncolt listámba, mást nem is kezel a HiFi-m.

"> Kapsz cserébe erősebb típusellenőrzést

Kell a fenének. Tudom, hogy stringeket raktam be a láncolt listámba, mást nem is kezel a HiFi-m."

Eheh. Ez így önmagában is humoros.
----
Hülye pelikán

Az érdekelne, hogy miből gondolod, hogy egy GLib-es lista kevesebb memóriát/prociidőt használ mint egy C++-os Qt-s...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Nyilván a listakezelést az STL és Qt fejlesztői is jól meg tudták írni, gyors és kicsi. A probléma nem is ebben van. Viszont ha egy objektumot veszel a listából és azon műveletet végeznél (metódushívás, operátor), akkor a pontos típusnak megfelelő metódust kell meghívni.

Egy QList<QString>-be berakhatsz Mp3Title típusú objektumot, ha az Mp3Title a QStringből származik. A típusunkban pl. a toAscii() metódus másképp kezeli az ékezetes betűket, mert az LCD-n úgy sem tudnának megjelenni. Tehát a list[i].toAscii() híváskor az Mp3Title::toAscii() hívódik meg, hiába QString-ekből áll a lista.

Ilyenkor a valódi típus metódusának keresgélést futásidőben lehet csak megtenni. Tehát futásidőben kell keresgélni, típusinformációkat (pl. metódusok) kell tárolni és extra kód is kell hozzá. Ehhez többlet CPU erőforrás és memória kell.

Ha az MP3 dekódolást célcsip végzi, akkor a lista és stringkezelési műveletek lesznek a CPU fő feladatai. Azaz ha ezeken spórolni lehet, akkor jön a korábban említett igencsak jelentős pénzmegtakarítás.

Nem reagálod túl a virtuális függvényhívás overheadjét meg a vtable-höz szükséges memóriát? Főleg, hogy stringekről beszélsz, amikhez nagyságrendekkel több memória kell, és a műveleteik is sokkal időigényesebbek mint egy dereference..

+1

A QString jelenlegi leírása sem javasolja beágyazott rendszerekhez a QString használatát.

Gondolom a probléma egyik forrása az, hogy a QString QChar-okból áll, tehát bármilyen karakterre vonatkozó művelet megint csak mindenféle metóduskeresgélést von maga után. Inkább a QByteArray-t javasolják.

Szerintetek a Qt szerzői ennyire nem ismerik a saját terméküket?

Szerinted ha a bájtokból álló tömböt ajánlják a jóval összetettebb, unicode karakterekből álló sztring helyett, akkor az olyan meglepő? a QByteArray felel meg a char[] típusnak (előjelet most hagyjuk). A QStringbe ezzel ellentétben lényegében bármilyen karaktert (értsd: karaktert, nem pedig 0-255 közti számot) bele lehet tenni. Vajon melyik a hatékonyabb? És melyik az, amelyik jobban használható?

Ha eladható terméket szeretnél, muszáj legalább 16 bites karakterekkel dolgozni, mert abba már belefér szinte minden, pl. japán és egyszerűsített kínai mellett még a hagyományos kínai szimbólumok legfontosabb elemei is. (Igényesebb desktop megoldások nyilván a teljes 32 bites Unicode-ot támogatják.)

A QByteArray használata esetén az UTF-8 kódolás elengedhetetlen. Az UTF-8 nyugaton 1,1, Közel-Keleten és Oroszországban 1,7, míg Távol-Keleten 3 bájtot eszik. Tehát átlagosan kb. 2 bájtot foglal egy szimbólum.

De ezt a Qt fejlesztői is tudják, és még így is a QByteArray-t ajánlják a 16 bites QChar-ból álló QString helyett.

Ezt a "keresgélést" felejtsd már el plz. A függvényhívás az overhead, nem a "keresgélés" ( = dereference).

No, akkor kukkants ide!

"Experiments indicate that approximately 6-13% of execution time is spent simply dispatching to the correct function, though the overhead can be as high as 50%"

Függvénytől függ. Amúgy a wikipediát bárki szerkesztheti, így nem feltétlenül valós információk vannak rajta.

Vannak esetek, amikor a C a praktikusabb, mert a gyorsaság számít. Viszont legtöbbször a karbantarthatóság és a bővíthetőség még fontosabb, így lesz C++ a kód, például Qt-vel.

a Qt -s mocos dolog, meg prekompajl eleg gusztustalan, tegyuk hozza. brr.

Nem pre-compile, hanem kódgeneráló. Szerintem elfogadható mértékű gányolás, ahol a hozzáadott érték arányban van a randasággal. :)
--
http://www.naszta.hu

(dupla)

Van ott egy évszám is, ami miatt továbbra sem hiszek neked.
Ellenben nézd meg ezt, a bekezdés végén van a lényeg:
http://www.parashift.com/c++-faq-lite/virtual-functions.html#faq-20.4

Jó kis leírás. Kevésbé érthető formában, a Wikipedián is ezt a mechanizmust írták le, évszám ide vagy oda.

A csúnya teljesítménycsökkenést viszont egy zárt kódú projektben sikerült megtapasztalnunk. A feladat jellemzően számításokat szinte egyáltalán nem tartalmazott, csak szövegfeldolgozást és a kinyert adatok strukturálását.

teljes zöldségeket írsz, az egész érvelésed hamis feltételezéseken alapul: a QChar az bizony == wchar_t, csak nagyszerű típusellenőrzéssel és kényelmi függvényekkel van kiegészítve.

"The QChar class provides a 16-bit Unicode character.

In Qt, Unicode characters are 16-bit entities without any markup or structure. This class represents such an entity. It is lightweight, so it can be used everywhere. Most compilers treat it like a unsigned short."

Az egész érvelésem arra alapul, hogy a QChar az egy osztály, amit költséges kezelni, míg pl. a wchar_t nem.

Nézőpont kérdése: a QChar-hoz vannak segédfüggvények, míg a wchar_t-hez nem, így a wchar_t-t költséges kezelni, míg a QChar-t nem.

Nem, a QCharhoz metódusok vannak. Segédfüggvényei a wchar_t-nek vannak, általában "wcs" van a nevükben.

Van a QChar-nak virtuális függyvénye?

KisKresz

Na, végre egy jó ellenvélemény! Első ránézésre valóban sem a QCharnak sem a QStringnek nincs. Tehát nem a virtuális metódusok miatt nem jó beágyazott rendszereknél a QString a Qt fejlsztői szerint. De akkor miért?

"virtuális metódus" jajj...

lol, csak jelölésben van különbség. Csak hogy érthetőbb legyen:

package Matrices is
  type Matrix is tagged...;

  function Get_Determinant(M : Matrix) return Float;
end Matrices;
[code]

Használata:

[code]
with Matrices, Text_IO;

procedure Main is
  M : Matrices.Matrix;
begin
  -- ...

  -- hagyományos, "segédfüggvény forma"
  Text_IO.Print_Line (Float'Image (Matrices.Get_Determinant (M)));

  -- objektum-orientált, metódus (fv):
  Text_IO.Print_Line (Float'Image (M.Get_Determinant));
end Main;

Bár ez Ada 2005, de teljesen jól érzékelteti, hogy igazából semmi különbség nincsen a kettő között, pusztán nevezéktan (jelölés), vagyis ez az egész nem több, mint szintaktikai cukor.

Nyilván, de ez csak azért igaz, mert a QString/QChar-nak nincsenek virtuális metódusai. Egyébként lényeges a megfelelő terminológia.

Virtuális alprogramok illetve nem virtuálisak - ez a jelölés szempontjából nem nagyon számít. C-ben is lehet objektum-orientált kódot írni, amiben akár virtuális függvények is vannak (hiszen függvénypointer C++ esetén is), csak egy kicsit macerás. Bár nem nevezném ezt OO-nak, mégis annak szokták mondani. Szóval csak azt próbálom mondani, hogy nem értem az első mondatodat.

A terminológia lehet, hogy lényeges, de nem látok sok különbséget a kétféle elnevezés és forma között egy olyan típusnál, amelynél az öröklődés nincs kihasználva (sem nem leszármazott, sem nem ős). A példámban egy ősosztályt adtam meg, amiből lehet származtatni, ha nem lehetne (nem tagged típus lenne), akkor persze a második forma (objektum.alprogram) nem működne.

Nyilván nem hangsúlyoznám a különbséget, ha nem volna. Virtuális metódusok címét az osztalyleíró táblázat tartalmazza, amit futásidőben kell kiolvasni. A nem virtuálisak meg fordítási időben dőlnek el, így gyorsak, mint egy hagyományos függvényhívás (mert lényegében az is).

Sokat játszottam C-ben ilyen ál-OOP-t anno. Ahogy írtad, lényegében virtuális metódusokat hozva létre. A C++ "virtual" és Java "final" kulcsszavakban az a jó, hogy szépen megkülönböztethetőek a virtuális és nem virtuális metódusok.

A C++ nem referencia alapú nyelv. Ha a QStringben QChar-ok vannak (és nem QChar* vagy QChar&), akkor teljesen mindegy, milyen virtuális vagy nem virtuális függvények vannak, +4 byte az osztálynak (ez speciel QChar-nál valószínűleg többszöröse lenne az igazi adat méretének), de ugyanúgy statikusan kötődik. Ez minden más osztályra is áll, ha nem mutatón vagy referencián hívod akkor nincs dinamikus kötés (persze lehet gányolni (&object)->method()) formában, de a QString féle dolgokról volt szó.
----
Hülye pelikán

Hú, így most mákosbejgli sütés közben nem sikerült megértenem, varázslás nálkül miért ne lehetne dinamikus kötés...

Ha van egy A típusú objektumod, az nem lesz B típusú, csak úgy hirtelen. Csupán ezért. Márpedig az egyszerű konténer osztályok (lásd QString) nem referenciát vagy pointert tárolnak, hanem ojjektumokat.
----
Hülye pelikán

Hopp, teljesen igaz. Tehát ha van egy gyümölcs konténerem, amibe almát meg körtét rakok be, akkor onnan ki már csak gyümölcsöt vehetek ki, almát vagy körtét nem.

Aha, tulajdonképpen logikus. Viszont ha a konténerem gyümölcs mutatókból áll, akkor - mint arra feljebb tetra is utalt - képbe jön a vtable, így az objektum valódi típusának megfelelő metódusok hívódnak meg. Cserébe meg kell oldanom, hogy felszabadítsak mindent, amit lefoglaltam.

Raadasul virtual t f() = 0; szintakszist használva absztakt osztályt is csinálhatok a gyümölcsből. Hát ez szuper.

Viszont mindez egy cseppet sem változtat a QString-től való idegenkedésemen. Ha nem átlagos desktop alkalmazást írok, nekem ne szórakozzon semmi sok ezer QChar példánnyal, implicit sharing ide vagy oda.

Kivenni kiveheted mindkettot, csak utana castolnod kell, mert ami a gyumolcs kontenerbol kijon, az gyumolcs lesz, nem pedig a konkret megvalositas (alma/korte)
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

A virtuális függvénytáblát, amire gondolsz, a konstruktorhíváskor, futási időben építi fel a program. Ezért nem lehet még hivogatni virtuális függvényeket a konstruktorból, ugyanis ekkor még úgy viselkednek, mintha nem-virtuálisak lennének. Persze e pillanattól kezdve már nincsen különbség virtuális és nem virtuális függvény között, mert ugyanúgy a tábla eleje + offset formában kerül meghívásra mindkettőnél, az egyetlen különbség, hogy hol is van az a tábla...

Ha így van, akkor igaz, amit korábban írtam, hogy minden metódushívás egy plusz v-table olvasás, így érdemes kritikus helyeken esetleg mellőzni az OOP megoldásokat.

De több oldalon is azt írták, hogy a nem virtuális osztály-függvények címét statikusan rakja bele a kódba a fordító. Nekem ez hihetően hangzik.

Nem mondtam, hogy nem hihető. Szándékosan beszélsz el mellettem.

Kritikus helyen hatékony kódot kell írni, ha ennyire számít a vtable-vel való játszadozás, akkor ott a függvényhívás maga túl költséges, függetlenül attól, hogy most az virtuális-e, avagy sem.

Igen, én is így gondoltam, hogy stack-kel szórakozni meg függvényt hívni sokkal költségesebb, mint egy táblázatból kivenni egy címet. Így kicsinek kéne lennie az extra munkának.

Épp ezért nem értem ezt a másfél évtizeddel ezelőtti irományt. Azóta nyilván fejlődött minden, de akkor sem értem.

-

Mondjuk STL-t asszem pont nem kapsz kivételkezelés nélkül...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Ha azt mondom a fordítónak, hogy ne, akkor nem lesz. Az STL ha jól tudom csak az at() esetén dob kivételt, ha azt nem használod meg se próbálja lefordítani, a saját típusaid másolásánál, megsemmisítésénél, létrehozásánál meg ne dobálj kivételt és akkor nem lesz baj.
----
Hülye pelikán

Sajnos nem ilyen egyszerű...
A new dobhat kivételt (elfogy a memória). Van ugyan new(nothrow), de nem tudod megmondani a vector-nak, hogy azt használja, tehát amikor beraksz egy új elemet van rá esély, hogy kivételt dob.
(Azt most hirtelen nem tudom, hogy le se fordul kivételkezelés nélkül, vagy csak elszáll, ha mégis van kivétel...)

Ha írsz egy saját allokátort, akkor még működhet a dolog, bár a push_back sehogy nem fogja neked jelezni, hogy nem sikerült a bepakolás.
Ha még azt is megcsinálod, hogy le tudod kérdezni, hogy volt-e hiba, akkor már annyi mindent újraírtál, és annyira használhatatlan, hogy egyszerűbb ha új tárolókat írsz.

Persze mondhatod, hogy az életben nem foglalkoztál még azzal, hogy a new dob-e kivételt, hiszen "sose" dob, de ne felejtsük el, hogy beágyazott környezetről beszélünk ahol nincs 2 GB ram, meg virtuális memória.

Mondjuk egy mai "zero cost" kivételkezelő nem okozna nagy szívfájdalmat beágyazott környezetben sem, de pont a kivételkezelés az, ami hiányozni szokott a g++ ezen változataiból.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Az STL-nek saját allokátorai vannak, ezért (is) nem származtathatunk belőle saját osztályt. Erre az szokott lenni a megoldás, hogy saját allokátor osztályt írsz. De tény, hogy ezzel az erővel akár írhatsz új tároló(ka)t is, bár az allokátor mellett szól, hogy akkor van STL-ed. Én a gyártók helyében (nagy szavak :) ) megírnám azt az allokátor osztályt, és kínálnék saját STL implementációt a minivashoz. Gyakorlatilag viszont nem tudom hogy csinálják, mert kisvasra még nem fejlesztettem.
--
http://www.naszta.hu

Odáig oké, hogy a saját allokátorod nem dob exception-t. (nothrow new-t használ és kész).
No de hogyan jelzed vissza, hogy nem sikerült?
A push_back-nek nincs visszatérési értéke. Az allokátor egy statikus fv-e még megoldás lehet, no de minden push_back után még egy ellenőrző fv hívás elég rusnya. Tényleg egyszerűbb ha írsz egy saját tárolót...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Itt már elmennék olyan randaságokig is, hogy globális változóba írom az eredményt és akkor a függvényhívás költségén is spórolok. (Gyakorlatilag errno-t használ az ember újra ld.: C)
--
http://www.naszta.hu

Mintha lenne is standard hiba a memoria elfogyasara...
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Most, hogy a Qt licensze normális lett, bizony meg vannak számlálva a Glib napjai...
--
http://www.naszta.hu

Nem hinnem, hogy egy komplett vilag meg tudna szunni egy csapasra. A Gnome nem fog Qt-ra valtani szvsz.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

a gnome nem, viszont a kereskedelmi szoftverek a Qt-t valasztjak (bar ez nem ujdonsag), ezzel alaposan megloditva az elterjedeset
a fejleszto meg, ha egyik toolkitet sem ismeri, inkabb valaszt olyat, amit amugy is lat mindenhol
arrol nem beszelve, hogy a Qt fenyevekkel a GTK(mm) elott jar :)

Attol fugg. Egy alapvetoen C alapu program fejlesztoje szerintem nem fog csak a GUI miatt Qt-t valasztani (legalabbis en nem valasztanek egy relative ismeretlen nyelvet a program egy egeszen kis reszeert), ugyanugy, ahogy egy alapvetoen C++ program fejlesztoje nem fog Gtk-t valasztani.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

az elso reszevel teljesen egyetertek, ha valaki ragaszkodik a C-hez, akkor gyakorlatilag nincs mas valasztasa mint a GTK (felteve hogy nem akar 1000 eves, obsolete toolkiteket hasznalni)
a masodik felevel viszont nem, anno en is nezegettem a GTKmm-et, ami a C++ -os GTK, de szerencsere sikerult mar elotte annyira megutalnom a GTK-t hogy inkabb a Qt-vel kezdtem ismerkedni, amit azota is imadok :)

A Gtkmm-mel az a baj, hogy nem a Gtk C++-os ujragondolasa, hanem csak egy wrapper a Gtk fole. Ilyen szempontbol nagyon nagy tisztelettel adozok a Ruby-Gtk2 fejlesztoinek, ok valoban ujragondoltak a Gtk-t, teljesen Ruby-ssa teve. Sajnos nem 100%-ig hibatlan a dolog, de maga az alapelv tetszik. Nem kell force setValami/getValami-t hasznalni, ha a valami-t akarom beallitani. C++-os teren viszont elegge... hogy is mondjam... kevesse komfortos a Gtkmm (mondjuk en a Qt utan probaltam ki, szoval... akar eloitelet is lehet...)
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Az általad említett típusokban gpointer (void*) generikus pointer típus használatos. Ez nem egyéb, mint színtiszta gányolás. Beleteszek körtét, és gond nélkül kivehetek úgy almát, hogy észre sem veszem, belül kukacos és dióízű. Hát ez a baj a glibbel. C++ viszont erősen típusos, ott vannak a template-ek, ott nem szükséges ilyet tenni. A Qt is ilyeneket használ szerencsére. A glibmm megint csak ocsmány, ráadásul dokumentálva sincs. Forráskódból nyilván kitalálhatnám, hogy melyik osztály mire való, de azért ez no comment. Ja, és a glibmm-es tárolóknál GObject-ből kell származtatni. Ami egy vicc, mert ha nem saját osztályról van szó, be kell burkolni egy sajáttal, ami ebből származik, a'la std::queue az std::deque-t.

Azért ez erős túlzás, már az stl-t a C-s gányolásokhoz hasonlítani ;) Pont az általad említett template lehetőségek miatt nagyon jól működik ez, akármit beletehetsz a queue-ba aminek van push/back - pop/front-ja (vagy fordítva? mindegy). De értem mire gondolsz, gyakorlatilag a queue csak egy igen vékony wrapper...
----
Hülye pelikán

Ha életedben nem használtál még se template-et, se stl-t, akkor miért szólsz hozzá?

A generikus tárolóknak pont az a lényege (Ada, Java, C++), hogy a tároló típusa meghatározza, hogy mit tartalmaz.

Az almás kosárba nem tudsz körtét rakni.

Ezzel szemben C-ben csak kosarad van. A traktor is belekerülhet.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Hogy jön ez ide?
A leges legutolsó mondathoz szóltam hozzá, amit ha olvastad volna amit írok (olvasás: az írott szöveg információvá alakítása, nem csak kibetűzése), te is észreveszel. A queue és dequeu kapcsolata nem egészen olyan, mint a GObjectes móka, pont mert nem polimorf hanem template.

Kérdezhetném, hogy ha nem tudsz olvasni csak agresszívan próbálni oltogatni, akkor minek szólsz hozzá?
----
Hülye pelikán

akármit beletehetsz a queue-ba aminek van push/back - pop/front-ja

ezért

Úgy értve, hogy alátenni... szerencsétlen szóválasztás egy konténer esetén, valóban, de azért meg lehet érteni.
----
Hülye pelikán

Nem, nem lehetett...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

lancolt listahoz jobb helyeken eleg egy sys/queue.h :)

--
NetBSD - Simplicity is prerequisite for reliability

Nem azért nem ad könyvtárat, mert lusták voltak, hanem mert a nyelv erre nagyon alkalmas: könyvtár írására. Amit nem lehet abszolút általánosan megírni, azt inkább nem írják meg, de ez nem is baj, mert születtek nagyon jó megoldások platformokra. Az más kérdés, hogy az emberek szeretik újrahasználni a tudásukat, így a Qt-féle crossplatform megoldások népszerűek lehetnek. Mondjuk az új szabvány pöppet bővíti majd a könyvtárat, az jót fog tenni...

Aki meg szídja az STL-t... válts fordítót/könyvtárat.
----
Hülye pelikán

Szia,

egy rövid receptet kérek csak, c++ -t szeretnék használni, csak a minimum érdekel.
(mint abszolút kezdő)
1. csomag hozzá (gcc, ...)
2. forráskód megírása után fordítás parancsa?
3. futtatható kód előállítása?
4. futtatási jog beállítás (chmod +x)
kész?
(Ubuntuban)

Használj CMake-et (http://www.cmake.org). Így egy txt fájl a projekt+maga a forrás és menni fog szinte minden compiler-rel. Szerintem így a legkönnyebb.
--
http://www.naszta.hu

Én azt javasolnám, hogy kezdj a Kernighan - Ritchie C könyvvel, hogy meglegyenek az alapok, aztán olvasd el Andrew Koenig C csapdák és buktatók című könyvét, az segít a gyakori hibák elkerülésében.

Itt megtalálod őket angolul:

http://skl-projekt.hu/leirasok/programming/Kernighan_Ritchie_-_The_C_Programming_Language.pdf

http://www.literateprogramming.com/ctraps.pdf

Amúgy mindkettő kapható magyarul is. Ezentúl meg a konkrét stílusbeli konvenciók projektfüggőek, de pl. a FreeBSD style(9) manual oldala szerintem elég jó útmutató. Vannak benne pl. makrózással és kommentezéssel kapcsolatos tanácsok is. Ezek segítenek abban, hogy Te magad kiismerd a kódot és ne ess bele gyakori hibákba, másrészt abban is, hogy utána más könnyen megértse a kódodat.

http://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=0&manpath=FreeBSD+8.0-RELEASE&format=html

Én anno vettem egy könyvet a ComputerBooks sorozatból, a "Programozzunk C++ nyelven"-t. Nem mondom, hogy a legátfogóbb, a legtökéletesebb, de magyarul van, rettentő sok példaprogram van úgy a mellékleten, mint a könyvben is és az alapokat egész érthetően elmagyarázza.
Ez persze még kevés, nem árt a fentebb, kollégák által említett olvasmányokat is átrágni. S persze gyakorolni, gyakorolni.

The C++ Programming Language by Bjarne Stroustrup - ez van magyarul is: http://www.kiskapu.hu/index.php?BODY=BookInfo&OP=details&ID=19100&VISIT=1
Effective C++ by Scott Meyer - és ez is: http://www.kiskapu.hu/index.php?BODY=BookInfo&OP=details&ID=41246&VISIT=1

Személyes véleményem az, hogy ha tudsz angolul, akkor azt vedd meg!
--
http://www.naszta.hu

Petho" A'da'm: C (programozasi nyelvkonyv). Kicsit regi (1991-es, asszem), akkor me'g linux, win se nagyon volt: msdos alapokat es 16bites int-eket feltetelez. De maga't a nyelvet nagyon jol leirja, peldak jok, stbstb. Erdemes erre is vetni egy pillantast (az elemi dolgokat szeretném megtanulni, jó példákat látni pointerek, adatszerkezetek és memória helyes kezelése, i/o, file-ok temakban alap). A tobbi (socket-ek, pl.) mar utana gyerekjatek lesz ;) Szerk: nem tudom honnan lehet a konyvet megeszerezni mostanaban, igy ~20 e'v utan. Szkennelt valtozat az van belole.

A C vs. C++ erveleshez me'g annyit igy szubjektive, hogy noha az STL sok nyu"got probal levenni az ember vallarol, alap-rendszer szintu dolgokban mindig C-hez kell visszanyulni (tehat alacsonyszintu file-kezeles, socket-ek, halozati dolgok /netinet, netdb/, hardverkozelibb dolgok /pl soros port/, multitaszk, parhuzamositas, interprocessz-kommunikacio, stbstb). Ha ilyeneket progrmaozol c++-ban, akkor a "cin" meg a "cout"-on kivul nem sok c++ lesz a programodban, hacsak nem irsz mindegyikre kulon osztalyt. Egyes TL-ek (Qt, pl) sokmindent implementalnak ezekbol, de valszeg az sem teljes.

A.

A második bekezdésedre lásd ACE framework és Boost Concurrent Programming kategória. Szerintem nem szabad, de nem is érdemes komolyabb feladatoknál ezek "alá" menni.

A masodik reszre: nezd meg a boost-ot, rengeteg sok lib van hozza. Ne feledjuk, azert szokott az ember a POSIX Socket API C-ben valo programozasahoz, mert nincsen C++ lib hozza a rendszerben alapbol, nem pedig azert, mert socketeket ne lehetne C++ lib-bel programozni. Es ami fontos: A Qt es a tobbi lib platformfuggetlen. POSIX-style halozati programozas Win-en csak cygwinnel van.
Ami nagy problema meg: nincs szabvanyos C++ ABI, minden fordito olyan name manglinget csinal, ami neki tetszik, igy aztan a shared object fileok nem lesznek kompatibilisek egymassal. Ez hatalmas szivas.

Szerintem - ha csak nem driver-t írsz - az OS közeli részeket könyvtárra kell bízni, mert nem éri meg hosszú távon benyalni a függvényeket. Idővel persze úgyis fennragad az emberen, de a személyes véleményem az, hogy nem kell feltalálni a spanyol viaszt. (Mi a túrónak írnék egy n+1-edik mutex és mutexlocker osztályt?) Ezért javasoltam a Qt.

Én személy szerint nem ismerem jól a boost-ot, de valóban sokan dicsérik. Eléggé sokan ahhoz, hogy érdemes foglalkozni vele (lassan nekem is :) ).
--
http://www.naszta.hu

Sok reszet azert lehet erdemes megtanulni, mert resze lesz a kovetkezo C++ szabvanynak.

Termeszetesen a Qt is jo, csak valakinek nagy. Meg nincs belole hivatalos runtime-only verzio. Van az SDK, aztan epits magadnak alkalmazast statikusan, vagy csomagold a .dll-t, vagy bizd az r=1 felhasznalora, hogy oldja meg a program futtatasat. A Java emiatt szimpatikusabb, sot meg a GTK is.

Van runtime verzió, amit magadnak tudsz fordítani, de ha megveszed - tehát nem csak LGPL van - akkor tudsz statikusan linkelni kereskedelmi progit is. Másrészről szerintem a GB-os ramok korában nem kéne, hogy a 7MB-os GUI, a 2 MB-os core vagy 0.5 MB-os Network modul fektesse el a vasat. :)

--
http://www.naszta.hu

A GUI 7Mb lenne? QtCore.dll+QtGUI.dll 40 mega felett van, ha emlekezetem nem csal. Nehogy minden alkalmazas statikusan forditsa be maganak a Qt-t, tok felesleges. En arra lettem volna kivancsi, hogy ha opensource Win32 fejleszto vagyok, akkor tudod-e mas megoldast, mint a statikus linkelest...de sajnos nem latom, hol van Qt Runtime binaris letoltes r=1 userek szamara, mint JRE letoltes.

Küldöd az exe mellé, miért gond ez? (Nem egy fájl, hanem három.) Ez nem akkora gond. A méretet külön megnéztem az előző komment miatt, úgy írtam. Ez Qt 4.3.5 Visual Studio 2005 SP1-vel fordítva (én fordítottam).
--
http://www.naszta.hu

Azert, mert ez elsosorban nem az alkalmazas resze, hanem a frameworke. Jobb lenne, ha letoltheto lenne egy kulon Qt runtime kornyezet, igy ha az ember tobb Qt alkalmazast hasznal, akkor nem kellene ezeket a libeket mindannyiszor felpakolaszni a gepere.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Elvileg a telepítőbe beépítve felmásolhatod a Windows\System32-be, és akkor "framework", de azért nem javaslom ezt, mert könnyen lehet, hogy más is így tesz és keresztbe tesztek egymásnak. :)

Tulajdonképpen miért zavar, ha 3 fájl van a csomagban és nem 1?
--
http://www.naszta.hu

Ezek szerint nem probaltad ertelmezni amit irtam. Nem az a bajom, hogy 1 helyett 3 fajl van a telepitobe, hanem az, hogy ez _nem tartozik az alkalmazashoz_! Semmi koze hozza kabe. Ez a runtime, es ennek elvben kulon telepithetonek kene lennie, es nem mindenki disztributalja a sajat verziojat, aztan lesz 80x az user gepen a qt egesze. Ez igy idiotasag volt a Trolltech reszerol, de hat ez van.

Nem az en meg a te alkalmazasoddal van baj, hanem a logikaval. Nincs kulon terjesztheto runtime pack -> mindenki hozzacsomagolja a dll-eket -> a Qt 80x fenn lesz az user gepen. A gyokerproblema az, amivel bajom van.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Pontosan értettem, amit írsz és valóban semmi köze hozzá, de: a Qt valószínűleg nem akart annyi szemetet hordani magával (nem akart a verziókból eredő rengeteg overhead-et a binárisban), mint például a .net. A Qt 4.3-as dll-ek neve megegyezik a 4.5-ös dll-ek nevével, de nem garantált, hogy a 4.3-assal fordított bináris megy is azzal a 4.5-ös könyvtárral. Ráadásul ha megnézed, Linux alatt tud független framework-ként is viselkedni, egész normálisan, mert ott illik a rendszeren lévő verzióval fordítani.
(http://qt.nokia.com/developer/changes/changes-4.5.3)

1) Az első ok ott keresendő, hogy sokan egy verzióra tesztelik le a programjukat (Pl.: ParaView és Qt 4.3 stb.) és azzal működnek biztosan jól. Kereskedelmi terméknél ilyenkor biztosítani kell hozzá a könyvtárat, a Qt meg nem akart verzióból eredő nagy overhead-et: lett kicsi, amit viszonylag sokszor másolunk a gépre, Windows alatt (Linux-on nem gond, ugye).

Egyébként ha körbenézel, akkor láthatod, hogy sokan például egy egész java runtime-ot csomagolnak a progi mellé (Lotus Notes stb.), csak azért, hogy a Java megfelelő verzióján futhassanak (ami ki van tesztelve). Ilyen szempontból egyedül a .net tűnik normálisnak, de annak azért igenis van overhead-je.

2) Különböző compiler-és C++ könyvtárak: valljuk be, hogy csúnya lenne, ha a Qt könyvtár a VS 8.0 SP1-es STL-jét manifestálná a Dll-ekben, mert abban fordult, te pedig a VS 9.0-ás STL-t használnád, mert a progid abban készül. Ez nyilván nem, vagy iszonyat nehezen járható, tehát ésszerűbb, hogy magadnak fordítod a könyvtárat és terjeszted a Qt-t. Ez minden olyan könyvtárnál probléma MS alatt, ami támogatja az STL-t.
(http://doc.trolltech.com/4.6/supported-platforms.html)

3) 64 bit. Most könnyű a dolgod: leforgatod magadnak és jó lesz. Ha ezt ők programozzák runtime-ban, akkor ez is egy szép nagy overhaed tud lenni.

Szumma: én a kb. 7MB-nyi dll-t elfogadhatónak tartom a saját programmal együtt való terjesztésre 40x is, ha így biztosan jó verzióval dolgozom együtt. (280MB, a HDD-d meg 500GB; az OS, amin megy 2-3GB és 40 programról beszélünk...)
--
http://www.naszta.hu

Ezen leginkább azoknak van ideje rágódni, akik maguknak fordítják a saját rendszerüket (Gentoo), vagy akiknek egy alkalmazás kiválasztásánál az a fő szempont, hogy mennyi idő alatt fordul le és mennyi függősége van (BSD).

Néhány ember abban élvez, hogy egy kompakt rendszere van. Másnak meg munkaeszköz, és leszarja, ha 80x fenn van a Qt, mert olcsó a HDD, és azt is leszarja, ha 8x benne van a memóriában (pl. egyszerre 8 Qt-s programot használ), mert a RAM sem drága.

Reszemrol valoban leszarom, azonban kulonbseg van egy fejleszto hozzaallasa, es egy user hozzaallasa kozott. Nem feltetelezhetem, hogy az user is leszarja, hogy egy lib 8x van a memoriaban, mert lehet, hogy neki epp abbol van keves. Melyen elitelem azokat a fejlesztoket, akik olyan szemleletben fejlesztenek, hogy ha az usernek nem tetszik, vegyen meg memoriat/diszket.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Melyen elitelem azokat a fejlesztoket, akik olyan szemleletben fejlesztenek, hogy ha az usetnek nem tetszik, vegyen meg memoriat/diszket.
+1

Vagy fizesse meg azt az időt, amit a fejlesztő kódoptimalizációra fordít.

--
http://sandor.czettner.hu

Hmm... es ki beszelt itt kodoptimalizalasrol?

Amugy meg... vannak olyan dontesek, amiket mar fejlesztes, sot tervezes kozben is meg lehet hozni, es optimalisabb kod lesz a vege. Es meg csak penzbe se kerul.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Oke, jogos. A debug verzio az, ami nagy.

"Sok reszet azert lehet erdemes megtanulni, mert resze lesz a kovetkezo C++ szabvanynak."

Tudom, egy részét ismerem is, de még nem merem használni éles kódban. Mást meg nem írok most. :)
--
http://www.naszta.hu

Statikusan linkelni lehet az opensource verzióval is, csak úgy kell lefordítani.
A statikusan linkelt bináris mérete annyira nem egetrengető pld. Eagle nyáktervező Windowsos binárisa 9,1 MB Linuxosé 12.8MB. QtGui, QtNetwork, QtOpenGL mindenképp benne van.

Szerintem a Qt IO resze elegge teljes, nagyon sok mindent meg lehet benne csinalni a C gyokerekhez valo visszanyulas nelkul. Legalabbis, ami az altalanos fajlkezeleshez kell, azt biztosan.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Így van.
A Qt-t használva 95%-ban elfelejtheted a c megoldásokat, helyette kapsz egy jó minőségű, objektumorientált könyvtárat (I/O, networking, thread területen is).

A Pető féle megvan még nekem, de már az összes lapja kijár :). Az assembly sorozata is megvan. Nagyon jó könyvek, érthető nyelvezeten, de nem terjengősen és nem is szárazon magyaráz. Természetesen nem eladó ! :)

Furcsa, hogy eddig nem jött elő a valgrind.
Ha "szépen"-C-sen nem is tanít meg fejleszteni, de a nagy hibákra, "más nyelvről váltósakra" rávilágíthat.
Azán jól jönnek a különböző kódelemzők is (pl cppcheck).
Ezek használatával kialakulnak benned olyan ökölszabályok, amelyek sosem árthatnak...
Unit testek írása - build rendszerbe építése.
Minél több forráskódot tanulmányozz - lehetőleg azokét a libekét, amiket használsz.
Az is zavaró tud lenni, ha adott libhez más lib "stílusában" fejlesztesz.

Aztán: http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.1

Ott van a legelso hozzaszolasban, en irtam. Szoval nem olvasod el a hozzaszolasokat ? :D

mea culpa.

Két könyvet ajánlanék:

Thinking in C++
Dewhurst: C++ hibaelhárító

Meg pár év gyakorlatot valami jó cégnél, anélkül nem megy.

+1 a thinkingnek
es Effective C++

-- nemide --

@Som-som:

Jahogy az adott virtuális függvény törzse alig csinál valamit, és sokszor van meghívva? Erről eddig nem volt szó, de abban az esetben tényleg jelentős az overhead, és érdemes teljesen átszervezni a programot.

Ezt tenném hozzá a topichoz, remélem, még nem írta senki ("style guide" szavakkal, oldalon belüli keresésre nem volt találatom)
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
Ez szerintem egy mindenre kiterjedő, részletes, áttekinthető leírás.
Egyvalamire azonban sehol nem találtam választ.
Pascallal, Delphivel kezdtem a programozást, önerőből állok át azóta is folyamatosan a C/C++/Java -ra.
Pascalnál alakult ki bennem, hogy az utasításblokkokat hogy tagoljam:

begin
utasitasok;
end;

Namármost én ezt előszeretettel folytattam volna, de azt látom, nem ez a bevett formátum, hanem

main(){
utasitasok;
}

pedig mennyivel szebb és átláthatóbb ha a { már új sorba kerül:

main()
{
utasitasok;
}

Nos, nekem legalábbis átláthatóbb. Az volna a kérdésem, hogy ez szépséghibának számít, vagy használhatom így nyugodtan?
Köszi: Schwartz
--
Hogyha III. András 5 év alatt 15 törvényt adott ki, akkor 25 év alatt 50 törvényt hanyadik Béla adott ki?

Csak Java-nál van ilyen "hivatalos" preferred coding style, egyébként pedig sokféle van, vagy használhatsz sajátot is. A lényeg, hogy konzisztens legyen, és az átláthatóság érdekében néha rugalmas.

http://en.wikipedia.org/wiki/Indent_style

Feltéve, hogy az "utasitasok;" beljebb vannak, csak a tab-ot elvitte a cica, ez az Allman style, és én is ezt használom (ha én döntök).

Ha semmi nincsen beljebb, akkor az nem saját stílus hanem ökörhugyozás, arról sürgősen át kell szokni...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Ottvoltak azok, két space formájában most épp, csak a hup motor elvette! :)
Most nem írok a sor elé space-t.
Most írtam.
De miután elküldöm, nincs is ott, akkor sem, ha < code > -ok közé teszem :/
--
Hogyha III. András 5 év alatt 15 törvényt adott ki, akkor 25 év alatt 50 törvényt hanyadik Béla adott ki?

> Ottvoltak azok, két space formájában most épp, csak a hup motor elvette! :)

  hup
    motor
      elvette

> nincs is ott, akkor sem, ha < code > -ok közé teszem

"A [code] elemet bekezdésen belüli fix szélességű betűkészlettel való megjelenéshez lehet használni, vagy egy blokk megjelenítéséhez (általában programkód)." (http://hup.hu/filter/tips)

:O
Akkor csak nekem nem tiszta?
hup
huphup

--
Hogyha III. András 5 év alatt 15 törvényt adott ki, akkor 25 év alatt 50 törvényt hanyadik Béla adott ki?

> Akkor csak nekem nem tiszta?

Mi nem tiszta?

A whitespace megőrzése.. nem akarok feleslegesen flémelni. Keresek "ide lőjetek" topicot! :)
--
Hogyha III. András 5 év alatt 15 törvényt adott ki, akkor 25 év alatt 50 törvényt hanyadik Béla adott ki?

> A whitespace megőrzése.. nem akarok feleslegesen flémelni.

Nem tudom mit lehetne ezen "feleslegesen flémelni":

[code]

  program

[/code]

Milyen jó dolog, ha a whitespace a sor elején releváns információt hordoz a kódban... Ja, az egy másik nyelv... :-)

Amire gondolsz, az vagy a , BB-tag, vagy pedig a , HTML címke. A egy bekezdésen belüli részletről mondja azt, hogy úgy kell megjeleníteni, mint egy kódot. De attól még sima mezei HTML elem, vagyis a benne megadott whitespace-ek száma nem számít: ha van legalább egy, az pontosan egynek felel meg, ha 0, az 0-nak. Bekezdés eleji whitespace megint csak nem számít, akárhány is van...

hihi

Lehet, látsz a sorok között :D

[ code ] és <pre> a két elveszett jószág ebben a sorrendben whitespace nélkül.

mchalls de szemetvagy :D

varazslat!

--
NetBSD - Simplicity is prerequisite for reliability

+1

Mindig azt a stílust kell követni, amit a közösség meghatároz. Amikor egyedül kódolsz, úgy teszed, ahogy akarod, de saját és mások érdekében is jó, ha konzisztens. Én speciel mindig új sorba rakom a nyitó kapcsost és nem nyitok blokkot, ha nem muszáj, de ez az én stílusom, van aki teljesen máshogy csinálja. No meg az se mindegy, hogy C vagy C++, előbbiben általában jellemzőbb a hosszabb kódrészletek egy függvényben, ergo másfajta tagolást érdemes alkalmazni az olvashatóság fenntartásához. A hibaellenőrzés is más, szóval.
----
Hülye pelikán

Megmondom oszitnen, en a Java-s default style-t kedvelem jobban, mert egyreszrol feleslegesnek tartok egy kulon sort arra aldozni, hogy a kapcsos ott legyen (egyfelol, ha nincs ott, az IDE ugyis szol, masfelol, mivel ez egybem sorzaro is lehet, az ilyen C-s nyelveknel egyszerubb igy (szamomra)), masreszrol pedig mivel eleve sok blokkot kell irni (if, for, metodus, C/C++ eseten class definicio, struct, satobbi, igy sporolok soronkent 1 avagy 2 karaktert is. (Mielott valki nekiallna hozongeni, a sorzaro pontosvesszo utan van ertelme sorvaltast eszkozolni, mert o nem egyedul all a sorban).

Arrol nem beszelvem, hogy az atlathatosagon nagyon-nagyon minimalisat tud javitani az uj sorba tett {. Ha eleve attekintheto a kod (tabulalt, nincsenek hosszu sorok, funkcio szerinti blokkositas van), akkor nem tud pluszt adni hozza, ha pedig egyebkent olvashatatlan a kod, akkor nem ettol lesz olvashato.

Termeszetesen a fentiek szigoruan SZVSZ vannak igy, ezt keretik figyelembe venni.

Amit viszont mindenkepp vegy figyelembe: a Java-s vilagban altalaba nem tesszuk a nyito kapcsost kulon sorba; ha publikusba tolsz ki kodot, akkor erre figyelj oda, jo pont tud lenni, noha nem szamit szepseghibanak.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"masreszrol pedig mivel eleve sok blokkot kell irni (if, for, metodus, C/C++ eseten class definicio, struct, satobbi, igy sporolok soronkent 1 avagy 2 karaktert is."

ezert szokas az allman/bsd/knf/solaris stilusban csak fv definicio utan kulon rakni kapcsosat :-)

masreszrol amit ajanlani tudok, az hogy if utan mindig rakjunk { } jeleket, megha csak egy sor is kovetkezik utana es if (i != NULL) vagy if (i != 0) helyett ne irjunk if (i)-t

--
NetBSD - Simplicity is prerequisite for reliability

szerintem pedig az if-ben kiírni, hogy != NULL sokszor feleslegesen növeli az adott sor hosszát(bonyolultabb feltételeknél csak kevésbé lesz átlátható).
Pl. van egy 'exist' nevű változó, szvsz sokkal szebb az, hogy if ( exist )..., mint az, hogy if ( exist != 0 )
Persze pointereknél is mindíg kiírom...azt azért mindíg jó jelezni, hogy épp mutatóról van szó :)
És _szerintem_, akár egy ciklusnál is teljesen átlátható és szép megoldás
Pl. én egy string bejárásában is szépnek látom a for (i=0; s[i]; i++) -t.

Mióta van std::string, szerencsésebb C-stílusú ~nek, 0-terminált stringnek, char* vagy char[]-nek nevezni.

Az exist mondjuk valószínűleg bool lenne, de pointernél egyszerűen a nyelv része, hogy akkor igaz, ha nem nulla, mert a null az egyezményes érvénytelen pointer. Egyszerűen kifejező. Persze kezdők bebukják néha, de a kezdő meg írhatja úgy, ahogy ő megérti.
----
Hülye pelikán

Én inkább kiírom. Tudom, hogy nem lenne muszáj, de nekem így áttekinthető.
--
http://www.naszta.hu

Én ajánlanám ezt a stílust megszokni: Linux kernel coding style
-----
IBM R50e > Debian GNU/Linux, Windows XP Home

Hu, csak az elejeert tornem le emberek kezeit. Inkonzisztens az egesz, plusz megengedi a gyakorlatilag tagolatlan felteteles utasitasokat.

Arrol nem beszelve, hogy a typedef-nek igenis van ertelme, ha struct-ot rovidit vele az ember, a preprocesszor definicio sokkal kellemetlenebb tud lenni.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.