GCC: C, C++ sebességkülönbség

 ( ispanov | 2006. június 9., péntek - 21:34 )

Sziasztok!

Az lenne a kérdésem, hogy körülbelül mennyivel lassabb GCC(4.0.3)-vel egy C++ kód egy C kódnál? Van valahol valamilyen benchmark?

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ő.

Nem ide tartozik, de úgy is mindenki szereti a benchmarkokat :)

http://blogs.sun.com/roller/page/dagastine?entry=java_is_faster_than_c

A Python gyorsabb, mint a Java (bizonyos esetekben):
http://twistedmatrix.com/users/glyph/rant/python-vs-java.html

Valaki még valaki bizonyítsa be, hogy a bash script gyorsabb mint a Python, és minden C programomat átírom bash alá :-)

Ha valaki (számolásigényes) python kód írására adja a fejét, akkor mindenképp próbálja ki a psyco-t.
Saját tapasztalat alapján 5x-10x gyorsabb lesz tőle a program.

Ha meg további gyorsítás kell, érdemes kipróbálni a pyrex-et.
Az én esetemben (ami azért kicsit speciális volt) a gyorsulás 50x-es, a memóriaigény pedig kb 0.2x-es lett a legelső változathoz képest...

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

Így első ránézésre egy gyors kötözködés:

- A konzolra írás roppant releváns :)
- a Hashtable-ös tesztnél az almát hasonlítjuk a narancshoz, ugyanis amit ő Java-ként implementált, az leginkább hárommillió objektum-létrehozást (és annak GC-jét) méri, nem pedig a hashtáblát (aminél a hashmap amúgy is gyorsabb), ha kell, akkor megírom a feladat-identikus java kódot.
- Az IO tesztnél nem ismeri a BufferedWritert, ami nem próbálja kevés számú bájtonként lemezre írni az adatot
- A vectornál is inkább ArrayList-et lehetett volna használnia, az gyorsabb
- Az interpreter initialisation tényleg roppant releváns :)
- azt hiszem minden más esetben a Java gyorsabb volt, jah, meg a vectornál is :)

Szóval mutass egy olyan tesztet, ahol Java-ban ugyanazt akarják megcsinálni, mint phythonban, mert az, hogy valaki kiméri az A feladatot pythonban, a B-t meg Java-ban, annak nincs összehasonlító ereje :)

Jah, releváns példaként a saját mérésemet tudom ajánlani :)
http://sourceforge.net/project/showfiles.php?group_id=160620

Nem állítottam hogy egyetértek a teszttel. Csupán arra kívántam rávilágítani, hogy a neten mindenre lehet bizonyítást találni, beleértve mindennek az ellenkezőjét is.
Ugyanakkor azzal sem értek egyet hogy egy sima numerikus benchmark akármit is elmondana arról, hogy milyen gyorsan működhet egy az adott nyelven írt átlagos alkalmazás (c vs. java).

jah, ez olyan mint az átlagos mosópor :)

Azért nem írod, hogy hagyományos mosópor mert az már reklám lenne? :D :D

a kódtól függ, meg attól, hogy mennyire ért hozzá, aki írja?

nézz itt körül:
http://shootout.alioth.debian.org

egy példa:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=spectralnorm&lang=all

Ez utóbbi linket annak is ajánlom, aki a Java-s linket ide betette. Röviden: c++ versus Java tesztben a Java marginális sebességi előnyéért 14-szeres (!) memóriazabálással fizetsz.

Végre...
Állandóan ezt mondom hasonló vitákban, hogy lehet, hogy a Java gyorsabb bizonyos esetkeben de zabálja a memoriát. Ezt az érvet persze sose hitték el, vagy félresöpörték, de most végre teszt is van róla... :)

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

teljesen mindegy, mert én akármikor belefutok egy javas programba, azzal mindig szopás van, ez egyik az egyik javaval megy, a másik a másikkal, de sok egyikkel sem :/

Köszi a linket!

Jó kis oldal :-) Szerintem én ezt kerestem!

Üdv.
Ránéztem arra a 14x-re.. tele van olyan megoldásokkal amik Java-ban nincsennek kihegyezve:
double[] u = new double[n];
- for (int i = 0; i < n; i++) u[i] = 1;

+ Arrays.fill(u, 1);

double[] v = new double[n];
- for (int i = 0; i < n; i++) v[i] = 0;

+ Arrays.fill(u, 0);

- for (int i = 0; i < n; i++) {

+ for (int i = n; --i >= 0; ) { Ahol nem szamit a sorrend!

C kod:
for(int i = 0; i < 10; i++) {
eval_AtA_times_u(u, v);
fill(u.begin(), u.end(), 0);
eval_AtA_times_u(v, u);
}

Java kod:
for (int i = 0; i < 10; i++) {
MultiplyAtAv(n,u,v);
MultiplyAtAv(n,v,u);
}
Nem furcsa, hogy java alatt a fill-t egy másik fügvényben oldja meg,
azt is szánalmas x[i] = v modon? De több ilyen lassíto "trükk" van még benne.. szét lehetne szedni izekre.. és a 14 máris nem 14, hanem sokkal kevesebb.
Szóval a tesztről annyit, hogy előbb meg kellene tanulnia teszt készitőnek Java-ban programozni.

Fri

Igen lehet.

"Ránéztem arra a 14x-re" Mire???
De ez hogy kapcsolódik ide?
Hogy jön ide a jáva?
Nézd meg a kérdést!

Valóban rossz helyre böktem a "válasz"-kor.
Amugy erre irtam (pár sorral feljebb):
> Ez utóbbi linket annak is ajánlom, aki a Java-s linket ide betette.
> Röviden: c++ versus Java tesztben a Java marginális sebességi
> előnyéért 14-szeres (!) memóriazabálással fizetsz.

Amugy a probléma általános: nyilván nem csak a java kod van összegányolva, hanem a többi is.

Jah, 14-szeres. Szeretem látni ezt az érvet, már kifejezetten hiányzott :). Senki nem gondol bele, hogy miért 14-szeres? A C++ kód szerencsétlen tartalmazza a saját kis adatszerkezetét és kódját, mást semmit. Persze hogy kicsi. A Java VM foglalása tartalmazza a _teljes_ API-t betöltve a memóriába. Ez most olyan összehasonlítás volt, hogy hasonlítsd össze a bash és az XServer memória-foglalását. Más a céljuk. Minél nagyobb alkalmazást írsz, annál kisebb lesz a relatív különbség, hiszen ez a memória-különbség egy konstans néhány MB-nyi plussz.

Ennek kezelése nem csak hardver-beszerzést igényel, hanem fejlesztésben is más hozzáállást. Nem szabad olyan Java alkalmazást írni, ami minden egyes feldolgozási lépésben betölt egy új VM-et, ez nyilvánvaló.

"Minél nagyobb alkalmazást írsz, annál kisebb lesz a relatív különbség"

Sajnos a tapasztalat valahogy nem ezt mutatja. Mostanában elég sokat kell használjak Eclipse-et (ami ugye egy Javában írt IDE). Na ennél lassabb és memóriazabálóbb IDÉ-vel még nem találkoztam.
A többi eddig próbált java alkalmazással ugyanez a helyzet.
Szerintem ennek 2 oka lehet:
1. A Java nem bírja a gépet hatékonyan használni.
2. A Java programozók nagy része béna.
Nem tudom melyik lehet a valódi ok.
Amúgy ha egyszerre négy-öt Java alkalmazást is szeretnél egyszerre futtatni, szerintem a mai gépeken nem nagyon van esélyed, márpedig az egész grafikus felület pont erre lenne kitalálva.

- Mindenkinek a NetBeans-t szoktam javasolni az Eclipse helyett, bár nem éppen memória-problémák miatt :)

- Nagyon szép példa a MagicDraw UML szerkesztő program arra, hogy lehet gyors és szépen felépített, komplex Java-s alkalmazást írni Swingben

- A Java tud hatékony lenni. A NetBeans Platform (!= IDE), ill. pl. a JEdit két egyszerűbb példa erre. Persze mi a hatékonyság definíciója? :)

- A programozók nagy része nem elég képzett (nem béna, és nem nyelvfüggő a képzetlenségük). Egyszerűen nincs elég idő, pénz és kitartás arra, hogy minden fejlesztő megfelelően használja az adott célra leginkább célszerű eszközöket.

- Nézzük csak amit most éppen futtatok: azureus, netbeans, glassfish appserver, apache derby, squirell sql console, és meg sem érzem. Na jó, az igaz, hogy nem 512M memória van a gépemben, de mi számít mai gépnek egy fejlesztő esetében?

Ez az egész "Java lassú/sok ramot fogyaszt" dolog nekem arra hasonlít mint mikor egy assembly programozó összeveszik egy c-s társával.

Egy asm program tényleg gyorsabb tud lenni.
(kb 2-3x numerikus programok esetén x86-on, RISC-en kb 5x)
De egy c programot lényegesen egyszerűbb/gyorsabb megírni.

A furcsa csak az, hogy míg a c az asm-hez képest egy más szint, addig a java a c++-hoz képest nem.

Számomra érthetetlen, hogy miért kell megfizetnem a hátrányokat a vitatható előnyökért.

Én azt látom, hogy olyan esetekben használlják a javat ahol az előnye (a bináris hordozhatósága) abszolút nem lényeges.

Pl IDE. Miért jó nekem, hogy hordozható. Bőven elég lenne, ha a kód hordozható lenne, és le tudnám fordítani bárhol. Ez meg megoldható c++-szal, és mondjuk qt-vel, gtk+-szal, wxWidgets-szel...

Vagy szerver felhasználás, webservice. Miért jó nekem hogy hordozható?

Ellenben jó nekem, hogy zabálja a memóriát? Nem.

Hogy most miért használlja annyi ember ilyen dolgokra az egyértelmű: nagyon gazdag libek vannak hozzá. Én csak azt nem értem, hogy miért a Javahoz fejlesztettek ennyi libet, miért ebbe öltek ennyi pénzt...

Persze mostmár felesleges ezen tépelődni, mindenesetre érdekes.

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

Lehet azért, mert "a mindenhova le tudom fordítani" nem működött elég jól? (Tudom, vannak jó példák. És vannak nagyon rosszak is)

Grafikus felületen kívül én nem nagyon tudok olyan területet, ahol komoly gondok adódtak ebből.

De ha voltak is (biztos voltak), azok sem elvi problémákra vezethetők vissza, csak nem voltak jól megírva a libek, vagy a fordítóprogramok.

Elvégre ha egy rendszerre lehet egy vm-et implementálni, ami ugyanúgy futtatja az adott programot, akkor lehet fordítóprogramot is implementálni, ami ugyanúgy fordítja le.
Sőt a feladat komplexitása is hasonló...

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

Persze, a komplexitás hasonló, és igen, ha minden jól van megírva, akkor minden jól működik és hordozható. Minden csak azon múlik, hogy ki tudja először implementálni jól használható módon, és bár más nyelvek is alkalmasak lehettek volna, a Java nyerte el ebben az elsőséget. Hogy hosszú távon mi lesz, abban nehéz nyilatkozni.

Ebben igazad van, csak egészen a közelmúltik a Java kifejezetten szar volt. Persze nem a nyelv, csak a JIT compiler előttig gyakorlatilag használhatatlan volt, leszámítva az olyan eseteket, ahol nem a sebesség, hanem a hordozhatóság volt a szempont (appletek tán a legjobb példa).

Mégis ezeket a fejlesztéseket a Javahoz kezdték el, és nem mondjuk a C++-hoz, ami sokkal elterjedtebb volt.
Számomra nem teljesen világos, hogy miért.

talán azért, mert a C++ mögött nem állt egy cég, mint a Java mögött a Sun.
Vagy tán azért, mert a C++ mögött túl sok cég állt. (Lásd microsoft, és az ő csodálatos c++ implementációi.)

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

Szerintem a dolog sokkal egyszerubb... Csak az egyes divatok termeszetes eletciklusa...

1. kezdetben volt a gepi kod+assembly
2. Azutan jott a algol+fortran
3. Azutan jott a C
4. Azutan jott a strukturalt programozas divatja => pascal
5. Jott az objektum orientalt programozas divatja => c++/objc
6. Jott az VM divatja (mert hordozhato ?-)) => Java

Mikorra jott az oo, addigra a fortran mar rezervatumba kerult...
Manapsagra a pascal mar rezervatumba kerult...
... :-)

Zsiraf

p.s.: a C orok...
p.s2.: es ne veszitsuk el a remenyt, mert egy jo Fortran programozo barmilyen nyelven tud igazi (nem strukturalt) Fortran programot irni :-)

Ebben valszeg igazad van, csak én egyre inkább template buzi vagyok, tehát röghöz vagyok kötve. :)
Talán kinövöm egyszer...

Vagy talán megjelenik egy új nyelv (a Generic Java még nem az igazi), esetleg C++-hoz egy VM. (Talán a gcc-be bekerül a CLI támogatás...).

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

Játsszál Adával. Ha gyorsan akarod kinőni. :)

Már játszottam köszi. :)
Nem a generikus programozás tetszik ennyire (bár az is fincsi), hanem az expression template, meg a template metaprogramming.
Előbbi ugyan lehetséges generic javaban, utóbbi viszont csak c++-ban van.

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

C++-hoz egy VM == Java :)
Java Generics meg már létezik.

"C++-hoz egy VM == Java :)"
Azért messze nem.

"Java Generics meg már létezik."
Tudom, mint írtam nem az igazi...
Hogy pontosabb legyek mint generikus programozási nyelvi eszköz nincs vele gond (vagy legalábbis én nem tudok róla), de a template több ennél.

Már rég bebizonyították, hogy a template metaprogramming Turing teljes a C++-ban.

És persze gondolhatod, hogy marha jó, de ennek mi haszna, én erre azt mondom, hogy elég sok haszna van már most, és még rengeteg új ötlet fog megjelenni a jövőben.

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

"C++-hoz egy VM == Java :)"
Azért messze nem.

Mi kellene egy C++-os VM-be, ami nincs benne a Java-s VM-ben?

Mint említettem vala, nekem a template-ek hiányoznának.

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

Ez szintaktika, és nem VM kérdés. Ráadásul a templating feladatok igen nagy része lefedhető már meglévő megoldásokkal (pl. Groovy). De van még más is bőven:

http://java-source.net/open-source/scripting-languages

Valóban nem VM kérdés.

Csak ha ezt látod, akkor tudnám miért mondod azt, hogy C++ + VM = Java
A C++ egy nyelv nem része és nem is befoglalója a Javanak (ami egy másik nyelv).

A C++ + VM-et elnevezheted valaminek, de a Java név már foglalt.
Pl a C#,ManagedC++,stb + VM = .NET

A te szóhasználatodban a Java + VM = Java.
Ez véleményem szerint nem túl jó választás...

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

Akkor máshogyan kérdezem. Milyen (plussz) funkciók lennének meg a C++ VM-ben, ami nincs meg a Java VM-ben? És ha lenne C++ VM akkor miben lenne jobb, mint a Java VM? Ha átgondolod, akkor közel kerülsz a Java VM-hez

Nem a C++ VM-ben kellenek plussz funkciók ami nincs meg a Java VM-ben, hanem a Javaban nincsenek bizonyos funkciók ami megvan a C++-ban.

A legfontosabb, hogy a Java Generics valójában egy típusellenörzési eszköz. Mindössze arra jó, hogy nem kell Object-re és vissza castolni. Persze generikus programozáshoz ez elég.

A template meg inkább egy makro preprocessor. Ennek egy nem várt mellékhatása a metaprogramming.
A legnagyobb külömbség, hogy Javaban nem lehet specializálni a generikus osztályt. Ez viszont azért elég sokszor jól jön.

Persze mindent meg lehet oldani Javaban is, csak nem mindegy, hogy milyen áron, mennyi programozási idő vagy futásidő árán.

Én nem állítom, hogy a C++ tökéletes.
Nem állítom, hogy mindenben jobb mint a Java.

De azért örülnék, ha nem akarnád elhitetni velem ezeket a Java oldaláról.

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

Én csak annyit állítottam, hogy a Java nem olyan rossz, mint amilyennek sokan próbálják beállítani. Én sem állítom hogy tökéletes, és úgy gondolom, hogy ha nyugdíjba vonul, csak ennél fejlettebb technológia jöhet, mindenképpen olyan, ami többet tud, mint a Java.

Ezért is érdekelt az, hogy mit is értesz C++ VM alatt.

(megj: a meta* kezdetű dolgok mindig bűzlenek, lásd metamodellezés :) )

Nem én neveztem el template metaprogrammingnak. Bár nekem semmi ellenérzésem nincs az meta kezdetű dolgokkal szemben.

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

Azért az a közelmúlt olyan 5 év (1.3-as, 1.4-es Java), ami a Java 10-11 éves életciklusához mérten nem is olyan soká következett be. Persze vannak emberek, akinek még ma is lassú a dolog :)

A Java mögött pedig nem csak a Sun áll. Ott az IBM, BEA (külön virtuális géppel), Oracle, Intel, Nokia, SAP és a lista folytatható. Ahogy a C++ mögött is ott voltak ők is. Csak a Java alatt van egy _nagy_ API már a kezdetektől, és ez sokkal többet jelentett, mint az, hogy a C++ -hoz még ma is csak a STL az über :)

"STL az über"

Khm... Boost, Ace, Loki...

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

És ezek a nyelv/platform részei? :)

hála istennek nem

Nem. Még...

Bár az a kismillió C, meg Fortran lib sem a nyelv/platform része, amit nap mint nap használnak.

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

asszem veled volt régebben vitám szintén Java témakörben

csak 1 dolgot emelnék ki.
A Sun oldalán levő szöveg szerint a Java minden célra alkalmas, kivéve a "most demanding" alkalmazásokat. ja, úgy könnyű. én orvosi képfeldolgozásban és numerikus számításokban nyomulok, itt a Java memóriakezelése miatt prohibitív: nem tudod, mikor futsz bele egy olyan Nx-es memóriazabálásba, ami miatt _nem_tudod_ megoldani a feladatot.

Valóban kódfüggő, de általánosságban max 5% lassulás tapasztalható (leginkább) az exception kezelés miatt. (Még akkor is, ha változtatás nélkül fordítasz egy c kódot cpp-nek.)
Azt nem tudom, hogy az "-fno-exception" módosít-e ezen.

Ja, és minél több inline-osítható fv, és minél kevesebb virtuális fv kell, gcc nagyon szeret inline-osítani. A virtuális fv-ek pedig nagyon be tudnak lassítani, úgyhogy csak akkor használd, ha konkrétan kell...

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

Ez a sebesség különbség zavaró lehet desktop környezetben?
Konkrétan a gtk+ c++-os felülete a gtkmm (sokkal)lassabb?

En nem hinnem hogy igazabol erszre tudnad venni.

gtkmm-et eddig egyszer használtam, akkor is windowson...
Ekkor szerintem a különbség több kell legyen mint 5%, mert ugye a progi meghívja a gtkmm-es dll-eket, amik utána a gtk+-osakar. (linux alatt ugyanez, csak .so-val).
Ezek a hívások nem túl jól (értsd.: egyáltalán nem) optimalizálhatóak.

Valójában egy mai modern gépen egy ablak kirajzolása, az event-ek kezelése és hasonlók olyan kevés processzoridőt igényelnek, hogy ez elhanyagolható.

Vegyük pl a qt-t és a gtk+-t. C++ vs. C. Nem mondanám, hogy érezhető a különbség.
(A KDE vs Gnome azért már más lapra tartozik.)

Tehát, hogy a kérdésedre válaszoljak, nem észrevehető. (IMHO)

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

Az erem egyik oldala, hogy amennyiben szamitasigenyes muveleteket akarsz C++ kodra epiteni, szamolhatsz egy 5-10% vesztesegre.

A masik pedig, hogy C-ben is tudsz irni xar, lassu kodot, ha nem vagy tisztaban azzal, hogy a fordito, hogyan dolgozza fel az altalad irt kodot. Ugyanez a C++-ra is igaz.

IMHO, nem a problemat igazitjuk a nyelvhez, hanem a nyelvet a problemahoz. Ha pl egy desktop alkalmazast akarsz kesziteni harom ablakkal meg hat gombbal, hogy egy zoldhatu, keknyakkendos kertitorpe ugrandozzon benne, akkor a legnagyobb problemad nem a "sebesseg"-nel fog jelentkezni, hanem a megvalositasnal (mint altalaban mindig). De, ha egy olyan desktop alkalmazast akarsz kesziteni ahol van harom ablak meg hat gomb es mittomen tobb napos lefutasi ideju aerodinamikai szamitasok fognak benne futni, akkor erdemes elgondolkodni a "sebesseg"-en.

Tehat fogalmazhattam volna ugy is, hogy meg kell tenned egy adott tavolsagot es jarmuvet kell valasztanod hozza. Ha 10 metert kell megtenned, ott a sebesseg lesz a legaprobb probemad, azert kar lenne Ferrarira sporolni.

Szerk: Csinaltam C forditokkal anno par szintetikus benchmarkot. Tudom, hogy nem szorosan kapcsolodik, de nezd at, talan ad egy kis tampontot.

---------------------
Ригидус а бетегадьбол

:-) Köszi a hozzászólást.

Most nem olyasmit írok ahol a sebesség a legfőbb szempont de azért érdekelt, hogy körülbelül mi a helyzet ezen a téren. Mostanában C-ben programoztam, de amit most akarok írni sokkal kényelmesebb lenne C++-ban. A program gtk és gnome libeket használna és csak az érdekelt, hogy mennyivel használ több erőforrást a C++-os felület. A memória tekintetében mindenképp hátrányos, de mint a többiek írták és mint a tesztek mutatják a program nem lesz feltétlenül lassabb tőle. Még meggondolom hogy "megéri e".

C++-ra akkor erdemes alapozni, ha komplex, sok olyan muveletetet akarsz elvegezni amelyek nagyon hasonlitanak egymashoz, vagy van valamilyen osszefugges koztuk amely alapjan kis modositassal egeszen uj tulajdonsagu dolgok jonnek letre.

Pl, szeretned a kepernyot - veletlenszeru pozicioban es meretben - teglalapokkal bombazni, ahol nemely teglalap kitoltott lesz, nemely kitoltetlen, nemely lekerekitett saku, nemely szogletes sarku, de osszessegeben elmondhato mindegyikrol, hogy kozuk van egymashoz. Van negy csucsa mindegyiknek, vannak eleik, stb, ebbol mar ki lehet indulni egy absztarakt osztallyal, ahol megfogalmazod az azonossagokat, a tobbi osztalyt pedig ebbol leszarmaztatva el lehet kesziteni az apro mutaciokkal amelyekkel megjelenesukben kulonboznek.

Altalaban a termeszetben letezo barmely dolog modellezheto objektumorientaltan. A kerdes csak abban merul fel legtobbszor, hogy melyik a fontosabb, a gyors fejlesztes es karbantarthatosag, avagy a gyors lefutasi ido. :-)

---------------------
Ригидус а бетегадьбол

Viszont ha belegondolsz, akkor ez a hasonlóság dolog tulajdonképpen az összes widgetre igaz. Én mindenképpen javaslom a gtkmm-et, mivel type-safe, így már fordításkor sok olyan hibát megfog, ami sima gtk esetében csak futási időben jönne elő.

"Viszont ha belegondolsz, akkor ez a hasonlóság dolog tulajdonképpen az összes widgetre igaz."
Nem veletlenul hoztam fel peldanak. :-)

De mint mondtam is korabban nem ezen mulik. Harom ablak + hat gomb mellett nem biztos, hogy a kerdes ugy kezdodne, hogy C vagy C++. Van meg ott sok mas dolog is ami jobbra vagy balra borithatja a merleget.

---------------------
Ригидус а бетегадьбол

Da ha már itt tartunk, akkor megtehetem, hogy az ablakokat c++-ban teszem ki, a konkrét számítást meg c-ben végzem. :)

Egyébként mivel a programozó ideje sokkal drágább mint a processzoridő, és ez az 5% nem olyan gyilkosan sok (némi kézzel történő optimalizációval (cikluskigöngyölés, stb) sokkal többet lehet hozni ha kell), gyakran érdemes számolásigényes feladatokra is c++-t használni. Tény, hogy egy c++ program sokkal tömörebb, és kifejezőbb (lásd a példát egy másik hszemben).

Persze a c++-hoz sokkal jobban kell érteni, mint c-hez, hiszen lényegesen bonyolultabb, így nagyon könnyű benne lassú kódot írni...

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

"Da ha már itt tartunk, akkor megtehetem, hogy az ablakokat c++-ban teszem ki, a konkrét számítást meg c-ben végzem. :)"
Vagy assembly-ben, ha nem feltetel a "platformfuggetlenseg" es _nagyon_ raersz. :-)

---------------------
Ригидус а бетегадьбол

Igen-igen, annak lényegesen több értelme van mint az egszerű c++, c párosításnak (legalábbis sebesség szempontból).

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

nem triviális méretű problémáknál már általában jobban optimalizál egy fordítóprogram, mint egy átlagos tudású programozó.
tehát szerintem igen-igen kevés esetet kivéve legfeljebb kb 5 soros egybefüggő assembly betét a maximum, amire szükség van.

Ki beszél itt átlagos tudású programozóról?
Aki asmben kezd programozni, az a minimum, hogy tisztában legyen az adott processzor felépítésével, késleltetésekkel, stb.
Persze annyira amennyire lehetséges, de minden processzorgyártó ad ki leírást a procijáról.

Lehet, hogy most meg fogsz lepődni, de vannak, akik FFT-t, és hasonló nem 5 soros algoritmusokat írnak meg asm-ben.
Tudok olyan matematikai libről, ami RISC procin 5x, x86-on 3x gyorsabb mint a rivális (c-ben megírt) hasonló libek.

Persze nem azt kell elképzelni, hogy az egész asm-ben van írva, hanem csak a teljesítmény szempontjából fontos részek.

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

Vagy még akkor különösen hasznos a C++, ha ehelyett:

   float* t;
   vector_create(t);
   vector_add(t,a,b);
   vector_mul(a,t,c);
   vector_delete(t);

 
inkább ezt szeretnéd írni:
 

   a=(a+b)*c;

 
Mindenki döntse el, melyik libet szeretné inkább használni. :)
 

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

Jogos. Nem esett szo arrol, hogy forditoprogram is jobban felszerelt, ill. sokszor ugyanazon C kodot maskeppen hajt vegre. :-)

---------------------
Ригидус а бетегадьбол

> Ez a sebesség különbség zavaró lehet desktop környezetben?
> Konkrétan a gtk+ c++-os felülete a gtkmm (sokkal)lassabb?

Sebességkülönbség: egyáltalán nem zavaró, talán az első indítás, míg nincs bent minden a kes-ben... lehet, hogy valami régebbi gépen megérezni; ki kéne próbálni valami P100-on egy egyszerűbb próbaprogramot pár ablakkal meg widget-tel. Nálunk 1400-1800 MHz-es Celeron-okon nem volt zavaró (sőt észrevehető is alig).

A fordítás sokkal lassabb. Főleg, ha sablonokat is használsz, akkor különösen... ezt le kell nyelni. Igaz, még 3-as gcc-vel próbáltam. De szerintem ez a 4-esre is igaz lesz. Sablonokat viszont jó használni. A GTKmm is erre épül, meg az STL is, amit nagyon ajánlok megnézni. Az eseménykezelés is sablonokkal megy GTKmm-ben, és szerintem nagyon fincsi lett! :)

Amúgy kb. az előttem szólókhoz tudok csatlakozni: pl. az eszközt válasszuk a feledathoz.

Az is igaz, hogy kritikus részeket megírhatsz más nyelven, és hozzálinkelheted.

Nem kell minden feladatra az OOP-elképzelést ráhúzni, de grafikus felületre baromi jól jön. Pl.: GTKmm-ben VBox az egy Box, a HBox is egy Box.

Egyszer toltam egy munkát C-ben és GTK-ban, majd áttértem C++/GTKmm-re, mert máshogy már nem ment tovább. :) Sima adatbázisalapú alkalmazás, sok táblával, minden kiválasztható listákkal... C-ben egy idő után az ember megőrül a pointerektől. Még aki amúgy szeret buherálni, az is.

Egyik ok lehet a C++-ra, ha maga a programod olyan, hogy OOP-ben érdemes tervezni. Ez - ha nem a felhasználói felületet nézzük, csak a ,,dolgozó programrészt'' - szerintem ritkán igaz.

A másik ok az eszközkészlet. Pl. STL-lel annyi mindent lehet csinálni, amivel sima C-ben vért izzad az ember:
- lista
- verem (meglepően jól tud jönni)
- halmaz
- map (string-gel, vagy akár objektumra mutató pointerrel indexelt tömb)

map-ra példa:

napok_szama ["január"] = 31;

GTKmm-táblázat elemein végiglépkedésre:

TreeModel::Children::iterator i;
TreeModel::Children gyerek = lista_store->children();
for (i = gyerek.begin (); i != gyerek.end (); ++i)
{
TreeModel::Row sor = *i; // Az iterátor által mutatott terület maga a sor.
...
}

STL-lista ugyanilyen, csak ott még nem kell előtte ez a children()-es móka, a listának közvetlen iterátora van. Elemet hozzáadni, elvenni szintén egyszerű, és mindezt bármilyen típusra! C-ben ahány típusból akarsz listát csinálni, annyiszor kéne megírnod a láncolt listát, plusz megőrülsz a mutatóktól. Vagy nagyon rafináltan megpróbálhatsz egy általános listát, ami nyilvántartja az elemméretet, de akkor hatványozottan megőrülsz a mutatóktól.

Aztán mi van, ha egy függvénynek string-gel kell visszatérnie? Lehetőleg return-nel. Ezt a C-programozó sokkal inkább kerüli, inkább megoldja máshogy. Mert ki legyen felelős a területért? Ki foglalja le? Ki szabadítsa föl? Egyszeres vagy kétszeres mutatóval menjen át? stb. Ezek nem megoldhatatlan kérdések, de mindig el kell dönteni, és nem mindig lehet ugyanúgy csinálni, még ha van is bejáratott módszered. (Sokaknak meg az sincs.) STL-lel kicsit egyszerűbb:

String fv ()
{
String szoveg = "aaa";
...
...
return szoveg;
}

Az összes memóriakezelés, konstruktorok, destruktorok, automatikusan működnek. Ez egy keveset valóban lassít, de általános alkalmazásnál nem észlelhető, egyébként pedig ez az ára...

Amíg C-ben nyomtam, megszoktam, hogy bonyolultabb programnál egy-egy változtatásnál, pl. funkció hozzáadásánál a szintaktikai hibák kijavítása után még jönnek a futásidejű hibák. :) C++-ban ezek majdnemhogy nem léteznek. :) (Ehhez persze kell egy kis rutin is.)

Igen jó hasznát vettem a hivatalos C++-hírcsoport FAQ-jának, ajánlom bárkinek, aki OOP-ben kezd gondolkodni, megkockáztatom: más nyelvek drukkerei is elolvashatják, annyira célszerűen elmagyarázza az OOP lényegét:

http://www.parashift.com/c++-faq-lite/

pl. nem azonnal örökölni mindent mindennel, mintaállatok, mert az öröklés nem kódújrahasznosításra való... hanem felület-újrahasznosításra. Kódra az objektum tartalmazása való, mint pl. GTK-ban a view-k tartalmazzák az adat-objektumot. Én először megszívtam. Arra is rájöttem, hogy miért érdemes kerülni a többszörös öröklődést. :) (Örökölni akkor célszerű, ha az egyik osztályod az egy másik osztály is egyben; magyarul minden függvénye hívható, ami a másiknak is. Az, hogy ugyanaz-e a függvény törzse, itt lényegtelen - a felület a fontos.)

Szerintem ezek a fontos kérdések, amik még a sebesség mellett latba kerülnek, illetve legtöbb esetben annál még fontosabbak. (De ha megírod, hogy pl. valós idejű képtömörítésre kell, az más. :) )

Végül a Model-View-Controller-elképzelést tudom még a figyelmedbe ajánlani, ha nem is vagy profi a témában, de legalább annyira, hogy a programodban próbáljon meg kicsit elkülönülni 3 dolog: az adatok közvetlen kezelése, a megjelenítés, és a vezérlés (pl. eseménykezelés, milyen eseményre mi minden hívódjon meg). Ez nekem 100%-ig sose sikerült, de amikor legalább erre törekedtem, mindig könnyebben ment a dolgom.

Nagyon szép összefoglalás.

Valóban az stl elég erős eszköz tud lenni.
Persze c-hez is vannak listák, mapek és hasonlók implementálva, tehát nem feltétlenül kell mindent magunknak megírni, és persze mindenféle void*-os trükközéssel különböző típusokra is működhet, de ez nem túl biztonságos megoldás.

A c++ erősen típusos nyelv, és ez kezdetben nagyon zavaró tud lenni egy c-ről áttérő számára, de megéri, mert valóban sokkal több hibára fény derül már fordítási időben.

Nagyon kényelmes dolog c++-ban az operátor overloading (operátor túlterhelés), nagyban ennek köszönhető az stl kényelmessége.

A template-ek (sablonok) meg egyszerűen csodálatosak. Enélkül az stl csak mindenféle ősosztályok bevezetésével létezhetne (mint Javaban).

És akkor még nem is jött szóba a template-metaprogramming, meg az expression-template...

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

Jah, meg a template-ekben megírt Fibinacci-szám generátor (vagy valami hasonló, nem emlékszem már), ami ugyan sohasem fordul le, de fordítás közben generálja az adatokat. Imádnivaló nyelv :)

Hogy ne csak hülyeségeket beszéljek:
Úgy látom te otthon vagy a gtkmm-ben. Kérdésem lenne.

Van ugye a refptr osztály. Az vele a gondom, hogy nincs benne * operator.
Persze tudom én, hogy miért, a gondom csak az, hogy a legtöbb fv objektum referenciát vár, így nem tudok egy refptr-hez kapcsolt a heapben lévő objektumot átadni neki.
Fordítva is gond van, mert van fv ami meg refptr-t vár, így nem tudom meghívni olyan argumentummal amit lokálisan hoztam létre...

Én néztem el valamit, vagy jól látom a dolgot?

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

Én nem tudom, hogy miért nincs. :) De tény, hogy nincs. (Ha Te tudod, megoszthatod.)

Pont ezért mindig igyekeztem a RefPtr-eket kerülni, kivéve az olyan objektumoknál, amiket RefPtr-ként kell megetetni a view-val vagy valami mással. Pl. Gnome::Glade::Xml (libglade-et használtam), Store-ok, TreeSelection, TextBuffer, meg egy helyen az AccelGroup. Máshol nem is kellett.

Saját magamnak eszembe nem jutott; a fönt említett FAQ szerint ahol lehet, használj referenciát; és ahol kénytelen vagy, ott használj mutatót. Ez eddig bejött. Apró kellemetlenség, hogy a pontokat át kell írni nyílra (->), amikor rájövök, hogy kénytelen vagyok mutatózni. :) De nem vészes a helyzet.

> a legtöbb fv objektum referenciát vár

Milyen függvények? GTKmm-es? STL? Saját? Kicsit konkrétabban? Bár asszem nagyjából vágom...

> Fordítva is gond van, mert van fv ami meg refptr-t vár, így nem
> tudom meghívni olyan argumentummal amit lokálisan hoztam létre...

Ez teljesen világos. Mivel a RefPtr-t olyan cuccokra találták ki, amiket többen használnak, holott egy példány van belőlük. Lokálisan létrehozott objektumot (ha nem fog sokáig élni) ne adjunk olyan függvénynek, ami azt hiszi, hogy sokáig fog élni. :) Erre jó a RefPtr: amíg az utolsó használó függvény is el nem ereszti az objektumot, addig nem törlődik, de utána meg biztos.

Az első kérdésedre talán annyit tudok mondani, hogy csak akkor használj RefPtr-t, ha a GTKmm kimondottan azt várja (pl. fenti típusok, de egyértelműen látszik egy idő után, hogy melyek ezek). Vagy ha esetleg erre a számlálós módszerre van szükséged, de az ritka.

Ha nem GTK-s vonatkozású kódrészletem van (ahol is a lista általában egy ListStore vagy ilyesmi), hanem STL-listát használok, és egymásba mutatnak a listák, akkor gyakran megengedem magamnak azt a vagányságot, hogy sima mutatókat használok. Így is annyival egyszerűbb a helyzet a sima C-hez képest, hogy ennyit még simán átlát az ember.

Ha meg pont egy RefPtr-es cuccot kell átadnod ,,sima'' referenciaként, akkor szerintem másold le. Azt hiszem, sok ilyennel nem találkoztam, mert emlékeznék rá...

Nyilván azért nincs * operátor, mert akkor rá tudnál állítani egy sima mutatót is, vagy egy sima referenciát, ami nem számlálódik. Aztán egyszer csak lenne egy referenciád ami nem mutat sehova.
Tehát bolondbiztosra próbálták megcsinálni.

Konkrétan akkor futottam bele, mikor szerettem volna egy menüt csinálni. Tutorial alapján láttam, hogy az ActionGroup meg az UIManager az ami nekem kell. Mind a kettőt csak RefPtr-rel lehet használni, másképp nem.

Gondoltam rendben, ha ez a szemlélet, hát legyen, akkor minden legyen RefPtr-ben. Hbox, DrawingArea meg ami kell. Na mikor megpróbáltam berakni egy Hbox-ba a gombokat, akkor derült ki, hogy a pack_start nem fogad el RefPtr-t, csak referenciát. * operátor meg nincs.

Persze ha a HBox, meg a többi nem RefPtr-ben van, akkor nincs gond, csak nem túl konzisztens a dolog, mert az UIManager, meg az ActionGroup meg abba kell legyen.

Tehát csak ezzel volt gondom.

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

> Tehát bolondbiztosra próbálták megcsinálni.

Világos, kösz.

> ha ez a szemlélet, hát legyen, akkor minden legyen RefPtr-ben

A szemlélet az, hogy a RefPtr közös használatú objektumokra való, a pakolt objektumok élettartamáért pedig az felel, amibe bepakoltad. Tehát elég a (valahányadik) szülőnek RefPtr-esnek lenni (annak is csak ha muszáj), és az egész struktúra ,,referenciaszámolós'' lesz.

> Na mikor megpróbáltam berakni egy Hbox-ba a gombokat, akkor derült ki,

Ezek szerint már kiderült a dolog...

"a pakolt objektumok élettartamáért pedig az felel, amibe bepakoltad."
Gondolom erre gondolsz:

MyWidget::MyWidget()
{
  Gtk::Button* pButton = manage(new Gtk::Button("Test"));
  add(*pButton); //add aButton to MyWidget
}

Én végülis a saját Window leszármazott osztályom privát adattagjai közé simán beraktam a gombokat, meg mindent, tehát a felszabadítással nem volt gond.

Egyedül csak azt nem értettem, hogy az ActionGroup, meg az UIManager miért kellett, hogy RefPtr-es legyen.

Most sem egészen világos, mert nekem egyik sem tűnik "közös használatú objektum"-nak. De mindegy ezzel még együtt tudok élni...

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

Használtam már gtk+-t és gtkmm-et is úgyhogy tudom miről beszélsz. Nem most kezdem el tanulni a C++-t sem. Tudom hogy egyszerűbb használni valamivel mint a sima gtk+-t. Tudom és ismerem a C++ előnyeit. Én most a hátrányairól illetve a gcc-s megvalósításának hátrányiról kérdezősködtem. Régebben sokkal rosszabb volt a gcc C++ fordítója (g++) ezért sem szerették, de ez mára megváltozott.

Szerk: Egyébként szerint C-ben is kényelmesen lehet programozni bár nem annyira mint C++ ban. Engem nem szoktak zavarni a pointerek. Igen az STL tényleg nagy találmány :-) .

> Régebben sokkal rosszabb volt a gcc C++ fordítója

Úgy '99 tájékán én is hallottam ilyenről... akkor még nem használtam. 2-3 évvel később nekem már semmi bajom nem volt vele.

> Engem nem szoktak zavarni a pointerek.

Kérdés, mekkora és milyen komplex programot írsz.

Persze láttam már olyan embert, aki jó nagy proggit csinált, karban is tartja régóta - C, GTK. Mindenki maga tudja.

És kérdés, hogy hogyan dokumentálod :)

A rosszabb fordítót a 2 szériára és a 3-as elejére (3.0 és 3.1) értettem. Azok még bugosak voltak és nem generáltak túl hatékony kódokat.

Csak azt nem tudom, hogy miért alakult ki ebből az "egyszerű" kérdésből egy Java vs C++ flame.

Lásd az első hozzászólást... (;

Miért ölik egymást állandóan a C++ és a Java programozók? Valaki fizet érte?

Szerintem rendezni kéne egy ketrecharcot :-D

Engem nem az zavar, hogy ölik/öljük egymást, hanem az, hogy mindezt nem a megfelelő topic-ban teszik/tesszük. Itt most volt egy C/C++-os kérdés. Miért kellett a java-t belekeverni?