Megkezdődhet a C++ használata a GCC fejlesztésében

Szerszám

A GCC levelezési listáján Mark Mitchell tegnap bejelentette, hogy a GCC projekt felügyeletét ellátó GCC Steering Committee és az FSF áldását adta a C++ GCC-n belüli felhasználására. Természetesen nem az a célja a fejlesztőknek, hogy mostantól mindenáron C++ kódot nyomjanak a GCC-be, sokkal inkább az a cél, hogy jobb fordítót adhassanak át a felhasználóknak.

Mielőtt megkezdenék a C++ használatát a GCC-n belül, meg kell állapodniuk abban, hogy a fejlesztők milyen C++ szolgáltatásokat használhatnak akkor, amikor kóddal járulnak hozzá a fordítóprogram gyűjtemény fejlesztéséhez. Mark úgy gondolja, hogy első körben elég szűken kell tartani a felhasználható C++ feature-ök körét, részben azért, hogy a C++-ban kevésbé járatos fejlesztőket ne érje váratlanul nagy változás.

Feltehetően ezért első körben a C++98 lesz az a szabvány amit engedélyeznek a GCC kódbázisához hozzájárulni kívánó fejlesztőknek.

A részletek a bejelentésben.

( 4fonya | 2010. 05. 31., h – 21:17 )

Pompás! :-( Még C-ben sem tudták normálisan megcsinálni, akkor most mit remélnek ettől? Most legalább nagyobb lesz, lassabb és még több nehezen kinyomozható hibát fog hordozni magában.

( uid_17784 | 2010. 05. 31., h – 21:21 )

"Using multiple inheritance, templates (other than when using the C++ standard library, e.g. std::list), or exceptions also seems overly aggressive to me."

OMG.
A szerencsétlen a template metaprogrammingról még nem hallott.

Biztosíthatlak, hallott róla, csak nem látta értelmét külön megemlíteni.

Using [...] templates (other than when using the C++ standard library, e.g. std::list) [...] seems overly aggressive to me.

A template-eket alapértelmezésben elutasítja, beleértve a template metaprogramming-ot is; az STL-lel kivételt tesz, mert az STL-t lehet a template-ek felületes ismeretével is használni. Saját template-eket tervezni/implementálni, illetve egy jól megtervezett, jól megvalósított template lib-et használni nagyon nem ugyanaz.

Vagy éppen az, hogy túl sokat hallott róla.

Tudod, pár éve tolom a template témát C++-ban.

És maximálisan úgy gondolom, hogy igaza van. Ha csak lehet, kerülni kell a C++ template-eket. Könnyen bloated kódhoz vezetnek, és általában nem úszod meg a specializációt. Ezenkívül a szabvány elbaszta a template koncepciót, a különböző fordítók pedig nem ragaszkodnak 100%-osan az (amúgy elbaszott) szabványhoz. Ezért aztán hordozható kódot írni template-ekkel halál.

Túl sok vele a probléma. Ugyanez igaz az exception-ökre is.

Jaja. :-)))

Alapvetően kár belemenni.

Ez ilyen lett, ezt kell szeretni.

Tudom, mindennek megvan az oka. Másképp nem lehetett, csak így korrekt, blabla...

De sajnos nagyon csúnya kódokat kell írni, hogy kézenfekvő dolgokat használjunk. (Pl. próbálj meg template class-ból leszármazni egy másik template class-t, és aztán az ősosztály egy protected memberére hivatkozni a leszármazott osztály egy metódusában. De ezen kívül az eszembe van még kapásból három dolog, ami szerintem csökkenti a nyelv olvashatóságát.)

Annyira bonyolult, hogy évekig egy C++ compiler sem tudta maradéktalanul megvalósítani...

Nem feladatom, hogy jobbat javasoljak helyette, de igen körülményes használni, ha az ember átlátható és hordozható kódot akar csinálni. Szvsz.

Hogy konkrét legyek mégis: Megkockáztatom, jobb lett volna, ha az msvc koncepcióját írják elő, mely szerint a template igazából egy "intelligens define", és nem is parse-olódik be, amíg konkrétan nem példányosítják.

A szintaxis néha nem a legjobb, illetve van pár ritka helyzet mikor kifejezetten erőltetett, de ezek elég ritka esetek. Még mindig a legerősebb feature az összes hasonló közül ami más nyelvekben van (talán a D-t leszámítva).

(A konkrét példádra reagálva: using a te barátod.)

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

( mapee v | 2010. 05. 31., h – 22:10 )

Véletlenül se legyen opensource világban bármiben is konszenzus, így C fordító is kell x+1, amiből persze x+1 bugos/keveset tud/lassú. \O/

Apple MacBook C2D 2.2Ghz 2x2G Intel X3100

( cannibal | 2010. 05. 31., h – 22:13 )

Kit érdekel? :)

A gcc a hozzá utolsóként ragaszkodó linuxszal fog eltűnni a süllyesztőben, megérdemelten. clang is here.

[ #FreedomFlotilla ]

Az általam mostanság használt C++ fordítók közül (gcc, msvc, és az Analog Devices + a TI cuccai) a gcc a legkorrektebb.

Mutass még egy fordítót, ami annyi platformra fordít, mint a gcc!

Néha a többi gyorsabb kódot fordít adott hardverre, de összességében ebbe tudok a legkevésbé belekötni. Az msvc se rossz, de túl megengedő, ezért nehéz vele hordozható kódot írni.

Amiért szeretem, hogy jól és szigorúan implementálja a szabványt a többiekhez képest. Vagy azt a dolgot, amit én szabványnak hiszek. :-)))
Elég jók a warning-jai. Jól paraméterezhető. Széleskörben támogatott.
Sokan használják.

A clang-ot nem ismerem. Jól jönne a gcc-nek egy versenytárs, de nem hiszek benne, hogy manapság ez reális lenne.

A hozzászólás kérésre törölve.

Tehát a következő kommentek mihamarabbi törlését kérem, tisztelettel:

http://hup.hu/cikkek/20100615/frissult_a_mac_mini_alu_haz_hdmi_sd_karty…
http://hup.hu/cikkek/20100615/frissult_a_mac_mini_alu_haz_hdmi_sd_karty…
http://hup.hu/cikkek/20100611/dell_az_ubuntu_biztonsagosabb_mint_a_micr…
http://hup.hu/cikkek/20100531/megkezdodhet_a_cpluszplusz_hasznalata_a_g…
http://hup.hu/cikkek/20100531/megkezdodhet_a_cpluszplusz_hasznalata_a_g…
http://hup.hu/cikkek/20100527/gpl_ervenyre_juttatas_az_apple_app_store-…
http://hup.hu/node/87930#comment-1036257
http://hup.hu/cikkek/20100514/nemet_birosag_birsagot_szabott_ki_mert_az…

A hozzászólás kérésre törölve.

Tehát a következő kommentek mihamarabbi törlését kérem, tisztelettel:

http://hup.hu/cikkek/20100615/frissult_a_mac_mini_alu_haz_hdmi_sd_karty…
http://hup.hu/cikkek/20100615/frissult_a_mac_mini_alu_haz_hdmi_sd_karty…
http://hup.hu/cikkek/20100611/dell_az_ubuntu_biztonsagosabb_mint_a_micr…
http://hup.hu/cikkek/20100531/megkezdodhet_a_cpluszplusz_hasznalata_a_g…
http://hup.hu/cikkek/20100531/megkezdodhet_a_cpluszplusz_hasznalata_a_g…
http://hup.hu/cikkek/20100527/gpl_ervenyre_juttatas_az_apple_app_store-…
http://hup.hu/node/87930#comment-1036257
http://hup.hu/cikkek/20100514/nemet_birosag_birsagot_szabott_ki_mert_az…

Közben rákerestem, rosszul emlékeztem, az az R4s nickjű fickó, akire hondoltam, az Bérczi László, nem Gábor. :(
Itt van pár régi ASM cikkje, én nagyon szerettem a cikkjeit: http://people.inf.elte.hu/kitty_/assembly/kitti_ass/Az%20assembly%20nye…
Volt C, C++, Pascal, ObjectPascal cikksorozata is, nagyon sokat tanultam régen ezekből. :)

Az a baj, hogy vele egyutt te is folyamatosan alulmulod onmagad. Ez az uldozes mar szanalmas. Hidd el, mindenki tudja, hogy Gabu milyen, es hogy hogy kell banni vele. Aki nem tudja, azt majd Gabu lerendezi maganak, ne akarj mindenkit kiokositani. Ez a szakma amugy is arrol szol, hogy a sajat karodon tanulsz meg egy csomo mindent. Eggyel tobb vagy kevesebb nem szamit.
-- 


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

> Elég jók a warning-jai.
> A clang-ot nem ismerem.

Igen, ebből jól látszik. :)

> Mutass még egy fordítót, ami annyi platformra fordít, mint a gcc!

Aki vaxra forgat, az tőlem használhat gcc-t, clang meg forgat x86, arm, alpha, ppc, és még egy rakás másik platformra is. Több mint elég.

> Jól jönne a gcc-nek egy versenytárs

Mivel nem ismered, elmondom hogy a clang/llvm már túl van a "potenciális versenytárs" kategórián. Az egyetlen kérdés maximum az lehetne, hogy a gcc utóléri-e a főbb feature-jeiben valaha, de a válasz egyértelmű nem. gcc is over

[ #FreedomFlotilla ]

( tr3w v | 2010. 05. 31., h – 22:32 )

Ahogy nézem a kialakult beszélgetést (nem itt, ott), elég konstruktívan de közben konzervatívan állnak a kérdéshez. Bár az is kiderült, hogy a bejelentés érik már egy ideje...

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

( gd | 2010. 05. 31., h – 23:25 )

Mennyivel jobban ért itt mindenki compiler fejlesztőknél a programozási nyelvekhez. :)

( Pontscho | 2010. 05. 31., h – 23:46 )

Ez a veg kezdete.

---
pontscho / fresh!mindworkz

+1

A reddit-en is fut egy beszélgetés a témában. Engem különösen a bootstrap-et feszegető felvetés ragadott meg (mivel korábban nekem is eszembe jutott), meg az a rövid szál, amelyben Paolo Bonzini nagyjából arra utal, hogy innentől egy ideig a gcc karbantartói nyelvi problémákkal fognak küszködni (ahelyett, hogy a fordítóra koncentrálnának).

inline függvény - pipa
const - pipa
referencia - nincs, de megoldhato
struktúra mint típus - pipa
template - tobb ervet lattam ellene mint mellette igy hanyagolandonak minositve :)
function overloading - nincs, de ez az a dolog, h le is tornem a kezet annak aki alam tartozo projektben hasznalja. Tessek szepen es okosan gondolkodni es szep okos kodot gyartani es nem taknyolni.

---
pontscho / fresh!mindworkz

"function overloading - nincs, de ez az a dolog, h le is tornem a kezet annak aki alam tartozo projektben hasznalja. Tessek szepen es okosan gondolkodni es szep okos kodot gyartani es nem taknyolni."

hmmmm...

pl. 


int initconnection(taddr address, int port, int sendsize, int recvsize, int type, tfunc callback) {
    ...
    ...
}

int initconnection(taddr address, int port, int sendsize, int recvsize) {

    return initconnection(address,port,sendsize,recvsize,CONN_TYPE_TCP,NULL);

}

int initconnection(taddr address, int port) {

    return initconnection(address,port,CONN_DEFAULT_SENDSIZE,CONN_DEFAULT_RECVSIZE);

}

Na most ezért miért kell kezet letörni, és hogy oldanád meg okosabban, szebben, logikusabban?

Na és mi van akkor, ha szükséges egy ilyen is?
Meg ezernyi más esetben hasznos a dolog. 


int initconnection(tconndata conndata) {
    return initconnection(conndata.address,conndata.port);
}

vagy

int bonyolult_kalkulacio(int a,b,c) {
    ...
}

int bonyolult_kalkulacio(float a,b,c) {
    ...
}

stb.

"function overloading - nincs, de ez az a dolog, h le is tornem a kezet annak aki alam tartozo projektben hasznalja. Tessek szepen es okosan gondolkodni es szep okos kodot gyartani es nem taknyolni."

Miért? Olyan helyeken is láttam alkalmazva, mint pl. Visual Studio math.h.

Egyébként még valami eszembe jutott: függvényparaméter default érték.

--
Don't be an Ubuntard!

Köszi, a hosszú listát :), én csak a function overloadingra (ami határozottan jó dolog), default paraméterekre és referenciára (igazira, nem olyanra, ami "megoldható") gondoltam első körben. Meg esetleg még template-ekre, bár attól sokan sikítófrászt kapnak, elfelejtve, hogy nem kell a template-ek minden csínját-bínját megérteni ahhoz, hogy valaki pl. az stl-lel elboldoguljon.

"referencia - nincs, de megoldhato" - ugye nem pointer magiara gondolsz? Mert az nem lesz referencia a budos eletbe soha.
function overloading - en annak tornem le a kezet, aki minden eltero parameteru fuggvenyhez uj fuggvenynevet talal ki. Foleg a func(), func2(), func3(), func4() a kedvenceim (jusson eszunkbe a popen3 fuggveny).
-- 


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

( turul16 v | 2010. 06. 01., k – 08:02 )

Remelem ezek utan is megoldhato lesz, hogy ne keljen C++ fordito a target arhitectura gcc libjeinek eloallitasahoz cross compile eseten. Az kurva nagy szivas lenne.
Ti. uj archra 2-4 honap, mig lesz C forgato + binutis. Ezutan libc portolgatas, majd ujabb 2-4 honap mig lesz C++. Ha ennek egyszerre kell megjelennie es mukodnie az elegge megnehezitene a fejleszto dolgat.

Ezzel lepessel elojon az a problema hogy, csak az lehet host/build architectura amihez van C++ target.(build-kor host) Ez nem tul jelentos problema, tekintve szinte minden erosebb arch-ra van.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( uid_17784 | 2010. 06. 01., k – 23:28 )

Bjarne Stroustup nyilván egy barom.
Herb Sutter nyilván egy paraszt.
Scott Meyers nyilván egy beképzelt tirpák.
Daveed Vandevoorde nyilván egy kis pöcs,
az EDG meg nyilván faszkalapok gyülekezete.
Andrew Koenig nyilván egy majom.
Nikolai Josuttis nyilván nem ért semmihez,
Andrei Alexandrescu meg nyilván egy román.

Kihagytam valakit? Nem számít, nyilván az is egy tehetségtelen.

Na most komolyan, balfékek!
Ennyi tehetségtelen név és egy "gyülekezet" láttán, lehet dondolkodni, hogy kell-e a C++ a C helyett...

Adjak linkeket is?
Lószart, kapirgáljatok a szemétdombon, rátok fér!

Na most komolyan, balfékek!
Ennyi tehetségtelen név és egy "gyülekezet" láttán, lehet dondolkodni, hogy kell-e a C++ a C helyett

Ilyet csak az ir, akinek fogalma sincs a ket nyelv nyujtotta lehetosegekrol, az elonyokrol ill. a hatranyokrol. Tovabba fogalma sincs arrol, hogy ez a hir mirol is szol ;)