GCC 4.6.0

Címkék

A GNU projekt és a GCC fejlesztők bejelentették a GNU Compiler Collection 4.6.0-s kiadását. Ez a kiadás "major" kiadás, benne számos új funkció található meg a 4.5.x verziókhoz képest. Pontos részletek a változások dokumentumban. A bejelentés itt olvasható.

Hozzászólások

Hozzáértő kiemelné az érdekesebb fejlesztéseket? Pl. gyorsabb lett valami, vagy hasonló.

C-nél -fplan9-extensions kapcsoló. Anoním struktúrák, meg unionok. erre jó: http://pastebin.com/yQ0F3yAN
Hasznos tud lenni. Nem tudom miért kellett rá több, mint 10 év.

---------------------------------------------------------------------------------------
Unix is simple. It just takes a genius to understand its simplicity. — Dennis Ritchie

Anon struct-ot is. Egy korai syslog-ng 3.0.x verzio kapcsan szivtam jokat... A kodot meg a meglehetosen antik gcc 3.2 is gond nelkul leforditotta, a sun studio 12 miatt viszont be kellett irni kamu strukturaneveket ide-oda, makrokat fuggvenyesiteni (mert sajat valtozokat deklaraltak lasd C99) es ezt aztan vegkepp nem szerette a sun studio.

itt nem arról van szó, hogy

struct{
int x,y;
}point;

hanem hogy

struct{
int x,y;
};

tehát ennyire anoním

---------------------------------------------------------------------------------------
Unix is simple. It just takes a genius to understand its simplicity. — Dennis Ritchie

Azért, mert az Apple LLVM-et ajánlja/szállítja, miért ne használhatnám a gcc-t ha működik? Pl ha gyorsabb kódot generál (jelenleg ugyanis ez előfordul, még ha nem is hatalmas a különbség). Vagy egy meglévő, mindenhol máshol gcc-vel fordított project portjáról van szó.

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

Legjobb dolog ami GNU cimkével kijött :)
Még több 0x featúra támogatás, juhéj.

Kéne egy felmérést végezni, hogy produktív környezetben átlagosan hány verzióval vannak elmaradva a cégek a használt fordítóval, érdekes lenne.
----
Hülye pelikán

Egy forditonal nyilvan azt hasznaljak, ami bevalt, ez nem azt jelenti hogy orokke igy fog maradni. Attol meg hogy nagyobb az elterjedeshez szukseges ido nem jelenti azt, hogy ertelmetlen a fejlesztes, szerintem.

-------------------------------
"A gorog katolikus noknek 8 dioptria alatt nem kotelezo a bajusz!" avagy "Nozni csak muholddal lehet..." | http://lazly.hu

Valoban, nem mindig van ido egy uj compiler bevezetesere, annak a bugjainak a kitapasztalasara, plane egy nagyobb projectnel. Pl. kedvenc sztorim a gyarban, h egy projectet kotelezoen -O0-lal kell forditani gcc40-tol kezdve gcc45-ig bezarolag, mert ellenkezo esetben rossz kodot fordit es mar egy szimpla htons() is hibazik. Erdekes csillagallast sikerult talalni, de legalabb konzekvens. :)

---
pontscho / fresh!mindworkz

Nem hasznalunk kereskedelmi forditot, mert barmilyen problema is akad gcc-vel, meg mindig ez tamogatja a legtobb platformot. Bar azota a clang+llvm masszivan jon fel, foleg CSA miatt.

Nem lett reportolva, mert nem volt ido eldonteni, h ez most gcc, linux+glibc hiba, esetleg mind a ketto egyszerre, plusz milyen egyuttallas kell a triggerelesehez, de gyanunk szerint az a kodhalmaz szukseges hozza ami meg mar uzleti titok kategoriaban van jelenleg. Majd ha kicsit lazul az utemterv utana fogok nezni, mert ezen jot rohogtem akkor es ott, valamint kivancsiva is tett.

---
pontscho / fresh!mindworkz

Érdemes utánanézni.
Velem is volt már ilyen, hosszas szívás után mondjuk kiderült, hogy én vagyok a hülye, hiányzott egy kezdeti értékadás vagy mi, -O0-val meg úgy esett, hogy 0-ra inicializálódott...

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

Egy glibc headerben levo makro kifejtessel van valami gebasz, egy uninitialized variable bug eleg hamar lebukna errefele. Foleg mert alapelv, h mindent inicializalunk, ha valoban szukseges ha nem, pont az ilyen es egyeb hibaellenorzesi problemak kikuszobolesere. A determinisztikus mukodes fontosabb, mint a sebesseg.

---
pontscho / fresh!mindworkz

hiányzott egy kezdeti értékadás vagy mi,
ja, azokat a -Wuninitialized ertekkel elo lehet hozni. vicces, hogy az -O1 vagy -O2 (ill efeletti) optimalizalasok ezt automatikusan bekapcsoljak. ebben, marmint a nem-initializalt valtozok felismereseben a gcc verziorol verziora jobb. tobbtizezer soros programok ujraforditasanal mindig elojon egy-ket ilyen, amihez mar ugye egyre alaposabb atragas kell hogy szemmel is eszrevegyuk hogy pontosan miert.

szoval hosszutavon ez hasznos, az biztos.

Nem tudom mennyire stabil, de a win-es verzió mindig együtt jön ki az egyéb verziókkal már elég régóta.

Eddig ugye gcc frontendet használt, most clang-ot, ami elvileg már tud C++-t (Qt Boost elvileg fordul), de azért ezzel még lehetnek vele gondok.

Szerk.:
Most látom, hogy 2.8-ban nincs fent a LLVM Binaries for Mingw32/x86, csak a gcc frontend (ami így useless). Fura...

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

Nem próbáltam semmit mondani, nem értem miért védekezel a gcc helyett is :) Csak látom, hogy nálunk mi van, és kíváncsi vagyok máshol mi a helyzet. Tudom, hogy egy nagy rendszernél nem adott nyelven íródik a kód, hanem adott fordítóra, és emiatt nehézkes az átállás, ezzel nincs is gond.
----
Hülye pelikán

Bekerült a Go a támogatott nyelvek közé.
Go Go, Go!