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

 ( trey | 2010. május 31., hétfő - 18:10 )

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.

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

C++ is sweet!

De nem a gcc-ben velemenyem szerint.

Mi lehet a hátránya?

Programozzunk C-ben, mert C fordító minden őskövületgépen van.

Nem pont ez lenne a cel.. :)

(Bar gcc-t remelem minnel elobb elhagyjak. Masreszrol nem csak gcc hibas mert a programok kodjai is annyi hibaval fordulnak hogy a compile 90%-at az tolti ki hogy kihanyja. Jo tudom.. "De mukodik"..es? Attol fuggetlen lehetne normalis kodja.)

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.

Lassabb...
OMG2

Legalabbis lassabban fog fordulni.
--

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

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

"a szabvány elbaszta a template koncepciót"

Mondanám, hogy ezt fejtsd ki, de ez ebből egy csúnya offtopic szál lenne itt...

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

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

Pont a using-ot próbáltam szídni. :)))

És nem a barátom.

Jah értem. De azt legalább csak egyszer kell beírni. Ellenben ha nem használod még vadabb dolgok kellenek. :)

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

Nem mondna ilyet, ha nem hallott volna rola :)
Igaza van.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

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

Kit érdekel? :)

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

[ #FreedomFlotilla ]

clang-nak még kell 1-2 release mire használható lesz C++-ban.
És akkor még nincs ada, meg fortran front-end LLVM-hez...

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

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.

Te pedig minden hozzászólása alá benyögöd ezt, függetlenül attól hogy igaza van-e. Mintha személyes küldetésednek éreznéd az ő hiteltelenné tételét.

--
Don't be an Ubuntard!

> újra munkanélküli

Ahhah, erről ő is tud? ;)

> Küldetéstudata pedig gabucinonak van.

Akár így van akár nem, az üzenetet szemlátomást teljesen félreértelmezted ;)

[ #FreedomFlotilla ]

A hup.hu profilt váltott és politikai portál lett?
Mi keresnivalója van a FreedomFlotilla-nak informatikai portálon?

(off)

Ez a Gábor Bérczi az a Bérczi Gábor, aki R4s néven, még a PC-X magazinban OOP programozási mellékletett vezetett?

hat ez nem tul valoszinu :)
marmint hogy gabucino meg oop :)

A'rpi

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%20nyelv%FB%20programoz%E1s%20alapjai/
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.

> Te pedig minden hozzászólása alá benyögöd ezt

Kérlek nézd el neki, hermafroditaként mindig is nehezen illeszkedett be a társadalomba.

[ #FreedomFlotilla ]

Próbáljatok meg ontopikok lenni, mert ha nem, akkor a kis kompánia hamarosan odakinn játszódik tovább.

--
trey @ gépház

Nyilvánvalóan nem tudom garantálni, hogy ő nem kommentel többé alám ;)

[ #FreedomFlotilla ]

Es persze az univerzum azonnal szingularitasba omlana ossze ha egyszer nem a tied lenne az utolso szo.

http://gpsforum.hu - Navigációról szájkosár nélkül

Szerencsére most a tied lett, elvégre neked úgy tűnik ez számít.

oh wait

[ #FreedomFlotilla ]

És akkor jön a főtroll, és nickjének épségét kockáztatva övé az utolsó szó :-).

Hogy kicsoda? :)

+1
Szerintem meg pont hogy jevgenyij az elmebeteg troll.

> 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 ]

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

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

+1

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

+1
kar erte. remelem az llvm mielobb levaltja...

A'rpi

Azt már régóta C++-ban írják.

Szvsz arról lehet szó, hogy nem túl egészséges dolog sima C kódba C++-t vegyíteni, mert egyszerűen nem objektum-orientáltan lett a program megtervezve.

--
Don't be an Ubuntard!

C++-ban vannak azért olyan feature-ök is, amik mindennemű objektumorientálás nélkül is hasznosak.

peldaul?

a barhol lehet valtozot dejkralalni akar for() kzoepen is nem er, ezt mar az ujabb sima C is tudja (C99 talan).

A'rpi

Így utólag nekem ezek jutottak eszembe:

  1. inline függvény
  2. const
  3. referencia
  4. struktúra mint típus
  5. template
  6. function overloading (Ez hogy van szépen magyarul? :))

--
Don't be an Ubuntard!

function overloading: A Stroustrup féle könyv függvény túlterhelésnek nevezi. Ilyenkor mindig megjelenik a lelki szemeim előtt egy, a megerőltetéstől erősen izzadó függvény. :-)

-----
Innen most töltsünk tiszta vizet a nyílt kártyákba: ...

Igen, valami hasonló rémlett, mert előadáson magyarul emlegették, de szerencsére nem így jegyeztem meg. :)

--
Don't be an Ubuntard!

+1 :D

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?

Lentebb BaT megadta a másik megoldást (alapértelmezett paraméterek). :-) Bár C-ben az sem működik.

-----
Innen most töltsünk tiszta vizet a nyílt kártyákba: ...

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.

hat C konyvtarakban 0/NULL parametert szokas defaultnak tekinteni, ha ilyen kell

--
NetBSD - Simplicity is prerequisite for reliability

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

"template - tobb ervet lattam ellene mint mellette igy hanyagolandonak minositve :)"

uramisten...
csak sajnálni tudom, akinek STL és az ő template-jei nélkül kell nagyobb rencert összerakni...

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

+namespace-ek

Azt én már oop alá vettem. Nem kéne?

--
Don't be an Ubuntard!

+1. Forkolni kellene a még el nem rontott mai gcc-t.

megint? :D

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.

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!


Andrei Alexandrescu meg nyilván egy román.

Made my day :]]

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

Idézet:
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 ;)