A GCC a Go támogatás beolvasztását tervezi

Programozás

David Edelsohn a napokban bejelentette, hogy a GCC Steering Committee áldását adta a gccgo front-end és a Go nyelvhez a gcc-specifikus runtime hozzájárulások elfogadására. A kijelölt karbantartó Ian Taylor lett. A GCC kiadását koordináló GCC Release Manager-ek döntenek majd a beolvasztás időzítéséről és a GCC 4.5-be, vagy a későbbi kiadásba való beépítésről. A bejelentés itt olvasható.

( emberk | 2010. 01. 28., cs – 10:49 )

Ez sosem baj. Csak annyi a probléma, hogy a gcc, már így is akkora, hogy........

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Amíg máshonnan nem von el erőforrásokat, engem nem zavar, de szerintem a Go még nem bizonyította, hogy megérdemli a belefektetett munkát...
Még a készítők szerint is experimental, akkor meg hova a sietség. (Dolgozzanak inkább a c++0x támogatáson. :) )

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

( lzrd | 2010. 01. 28., cs – 11:10 )

Még mindig nem érkezett fikázás, hogy előbb a Cé fordító részét csinálnák meg jól és a többi. Egy részt lehet, hogy púp a hátunkra, mert még egy dolgot meg kell tanulni, de az is lehet, hogy piacképes tudást jelent pár év múlva, ha tudunk góul.
--
unix -- több, mint kód. filozófia.
Life is feudal

Nem hiszem. Megnézegettem, szerintem jön majd egy felfutás, a csapból is ez fog folyni, aztán lecseng gyorsan, kb, mint a clipper. Imho.
Elég nehézkes a logikája ahhoz, hogy éles környezetben megbíznék a benne írt kódomban... Legalábbis első megtekintésre ez a véleményem.

egyesíti a java és a c++ jó tulajdonságait, engem meggyőzött h talán leválthatja a java-t. nekem nagy hiányom volt benne a külön is deffiniálható függvények (vagy csak nem jöttem rá), a c++-ból meg a garbage collector. nem azt mondom h hiányzott, inkább h ha már benne lenne akkor kevesebb az esélye h elfelejtem a destruktort. persze tudom h mind a kettő másra van, de akkor is tetszik nekem. El tudom képzelni h nem sokár a go nyelv eléri talán a java szintjét, és ha jól látom nem lesz olyan nehéz megtanulni ha egyszeer az ember megtanulta a jaa-t vagy a c++-t, esetleg mindkettőt.

"Javaban sem uszod meg a destruktorokat sok esetben."
mondanál egy konkrét példát arra a sok esetre?

"Ha pedig szamit a memoriafoglalas, akkor meg aztan plane"
mondanál egy konkrét példát ahol a destruktor csökkenti a memória használatot, de nélküle is normálisan működik csak több memóriát felhasználva?

Szandekosan nem valaszoltam azonnal, kivancsi voltam a tippekre es a hozzaszolasokra. Bocs. :~)

Egy pelda (ez speciel azert is jo, mert NagyZ is ebbol okitott ki az elobb):
http://java.sun.com/j2se/1.5.0/docs/api/java/awt/Graphics.html#dispose()

Sok masik eset is lehetseges, amikor olyan eroforrast akarsz felszabaditani, ami szamit, akkor nem feltetlenul jo otlet a GC-ra bizni *mindent*. Esete valogatja, de esznel kell lenni. Az, hogy vmi a nyelv resze, nem feltetlenul jelent optimalis mukodest a *te* alkalmazasod szamara. Meg akkor sem, ha a Sunnal (oh pardon, Oracle-nel) varazslo magusok ulnek es mindent runtime hozzad igazit.

valóban, de azért a Graphics.dispose() egy elég különleges eset, ezzel még nem támasztottad alá, hogy "Javaban sem uszod meg a destruktorokat sok esetben.". hát ez egy eset volt, és ez egy bonyolult swinges progiban saját LnF-el se fordul elő olyan gyakran.

azért ezt felesleges hasonlítani a c++ minden változóra oda kell figyelni poklára.

Hat ha neked a Graphics objektum kulonleges... :~) Es akkor meg hangot nem is adott a programod, csak rajzolt... :-)

Ez az a pelda volt, ami a mindennapi programokban is elofordul, ennel sokkal specibb helyzetek is vannak, amikor sajat objektum poolokkal kell bibelodni, vagy kezben kell tartani mikor mi mihez ferhet hozza.

[Szerk:]
Plusz, ha ezek a jelensegek eleg melyen jelentkeznek a programban, akkor esetleg ehhez felsobb retegek tamogatasa is kelleni fog, azaz a jelenseg eppenseggel meg fog jelenni mashol is, nem csupan a Graphicsban.
[Szerk vege]

A GC elsosorban kenyelmesseget jelent, nem pedig hatekonysagot. Ahol hatekonysagrol van szo, ott altalaban nem hagyod figyelmen kivul azt, hogy mi hogyan mukodik alattad. Es ez nem pusztan a legkihegyezettebb programokat jelenti, mert minden cegnek az az erdeke, hogy jobb legyen a masiknal, marpedig ha csak azt hasznalod amit ok is, akkor nem leszel az.

Szerintem a dispose nem destruktor.

Szerk:

Nem akarok azzal a trivialitással jönni, hogy Jávában nincs destruktor. A dispose konkrétan azért nem destruktor, mert pl. egy window.dispose után a window objektum _megmarad_, és akár újra meg is lehet jeleníteni.

Amúgy igazad van, hogy néha Jávában is kell tisztogatni (a szemétgyűjtés mellett), és ez némileg hasonlít a C++ destruktorra.
--
CCC3

"a c++ minden változóra oda kell figyelni poklára"

Azért nem kell odafigyelni minden változóra. A stackváltozókra a rendszer automatikusan meghívja a delete-t. Erre lehet alapozni egy egyszerű referenciaszámlálást. Olyan objektumokat csinálsz, amik automatikusan számolják a saját magukra mutató referenciákat, és megszüntetik magukat, amikor kell. Nem túl bonyolult.
--
CCC3

jahajajajh, imadom ezt a terelest!!
altalanos destruktorhoz hasonlitani egy rendszerosszetevo metodusat.. OMG :)

en is irhatnek az osztalyaimnak "ezt hivd meg legyszi es bezarok mindent" metodust, de attol ez meg nem lesz destruktor. es nem lesz a nyelvben destruktor.
szoval jo troll probalkozas, de legkozelebb legyszi tanuld meg a nyelvet mielott random apikat hozol

mar nemazert, de ha "destruktor"on (sic!) a finalizet erted, akkor tevedesben elsz. a legnagyobb tevedes (es ezzel nem vagy egyedul), hogy mig c++ban a destruktor _mindig_ meghivodik delete hatasara, addig javaba na GC _nem koteles egyaltalan_ lefuttatni azt. vagy lefut, vagy nem, zsakbamacska.

sosem szabad _semmit_ a finalize() -ra bizni [ritka kivetelek azert akadnak, de az nem a beginner szint]

En arra tippelek, hogy a try-finally blokkra gondolt, amit bizonyos esetekben talan lehet hasznalni "destruktorkent", de talan meredek annak nevezni. Egyebkent mas mar megkerdezte tole, de nem valaszolt, csak terelt, talan o se tudja mire gondolt. :-P

---
"A legjobb dolgok az életben nem dolgok."

Amit irtal, abbol az jon le, mintha a GC onkenyesen dontene, hogy melyik objektumra futtatja le a finalize-t es melyikre nem. Amit most irsz, abbol is ez jon le.

Ezzel szemben a szabvany megkoveteli a GC algoritmustol: Ha fut a GC, es egy objektumra nincs referencia, akkor arra az objektumra le kell futtatni a finalize-t. Erre vonatkozo linket adtam meg egy korabbi postban.

Ha a mondatodbol kihagynad a "GC algoritmusatol fuggoen" reszt, akkor helyes volna. (Mivel nem biztos, hogy a GC egyaltalan barmikor is lefut.) Talan csak a fogalmazassal van problemad.

Sehol sem allitottam, hogy hasznos dolog a finalize-t hasznalni.

Mas lehetoseg is van, hogy az eroforrasok lezaratlanok maradjanak. Pl. megirod szepen a finally agban a tisztogatast, de KILL-t kap a program.

Ha a program befejezodese miatt nem fut le a finalize, az nem feltetlenul baj. Pl. ha csak egy fájl close volna a finalize-ben, az erdektelen, mert a kilepett program fajljai ugyis lezarodnak.

--
CCC3

Szerk.

Talan arra gondolsz, hogy vannak generacios GC algoritmusok, amik a regebbi objektumok kozott ritkabban keresnek. Lehet, hogy egy ilyen regebbi objektumot a GC egyaltalan nem nez, es azert fel sem szabaditja.

nem keverek semmilyen generacios GCt, meg semmit, eleg jol simerem mind a JLSt, mind magat a VM spect.

An object is in the finalized state if it is still unreachable after its finalize method, if any, has been run. A finalized object is awaiting deallocation. Note that the VM implementation controls when the finalizer is run. The only thing that can be said for certain is that adding a finalizer will extend the lifetime of an object.

C++-ban garbage collector után sírni pontosan azt jelenti, hogy nem érted a nyelvet, vagy a cégnél kényszerítenek a rossz eszköz alkalmazására. Nemmellesleg van hozzá (nem egy és nem kettő), csak nem az std névtérben. Persze olyan, amilyet a nyelv enged.
----
Hülye pelikán

"C++-ban garbage collector után sírni pontosan azt jelenti, hogy nem érted a nyelvet, vagy a cégnél kényszerítenek a rossz eszköz alkalmazására."

vs

"Nemmellesleg van hozzá (nem egy és nem kettő), csak nem az std névtérben. Persze olyan, amilyet a nyelv enged."

Az ember nem azert sir GC utan, mert az milyen szep a nyelvben, vagy hogy a javat majmolja, hanem mert kell neki egy projektre. Mivel nem is egy libes formaban megirt letezik, plusz tipikusan ahol ez szamit, ott maguknak megirjak, nem latom az osszefuggest a hozzaszolasodban. Akkor sem, ha tudom mi a c++. :-)

Nagyon kilóghatok a hupos sorból, engem egyszer sem vágtak meg szövegértés (hiánya) miatt irodalomból még középiskolában.

"egyesíti a java és a c++ jó tulajdonságait, engem meggyőzött h talán leválthatja a java-t. nekem nagy hiányom volt benne a külön is deffiniálható függvények (vagy csak nem jöttem rá), a c++-ból meg a garbage collector."

Szerintem ez a szöveg azt mondja, hogy a C++-ból hiányzik a gc. Én meg azt mondom, hogy a kötelezően meglévő gc nem illik a c++-ba, akinek ez hiányzik, az nem érti a nyelvet.
Viszont. A C++ egyik fő célja a könnyű könyvtározhatóság, ebben benne van az is, hogy LEHET hozzá akármit írni (GUIzás sincs benne, oszt mégis), például gc keretet is.
Ergo: a felvetett probléma (már hogy a egyesíteni kéne a két nyelv jó tulajdonságait) ebben a viszonylatban nem létezik: a C++-ban alap, hogy nincs gc, mert semmi sem kötelező, viszont lehetséges bele gc, mert mindent lehet. Akkor mit is kell egyesíteni?

----
Hülye pelikán

( Replaced | 2010. 01. 28., cs – 12:18 )

google milyen vastag boritekot csusztatott vajon?

--
NetBSD - Simplicity is prerequisite for reliability

( mrev | 2010. 01. 28., cs – 13:51 )

20 éve azt mondták, hogy az objektumorientált programozás meg fogja váltani a világot. H. Schildt pl. ezt úgy értette, hogy egy programozó sokkal nagyobb mennyiségű kódot fog tudni uralni, mint oo nélkül. Az oo alapjának (legfontosabb elemének) a többszörös öröklődést gondolták.

Az oo nyelvek hihetetlenül elbonyolódtak. Ezért a Jáva, C#, stb. korlátozták magukat egyszeres öröklődésre. Meglepődve olvastam a C# 2008 (Trey Nash) könyvben, hogy a szerző szerint az egyszeres öröklődés is túl bonyolult, amit nem tanácsos programozók kezébe adni. Ezért az ezer oldalas könyvének minden fejezetében említi, hogy öröklés helyett használjunk inkább beágyazást.

És tessék, most itt a Go, amiben egyáltalán nincs öröklődés.

Megjegyzés: Már nem gondolják fontosnak, hogy egy programozó nagy mennyiségű kódot tudjon uralni. Fordítva, a multik érdeke inkább az, hogy a _programozók_ legyenek csereszabatosak, értsd: ha valakit kirúgnak, azt könnyen lehessen _olcsó_ programozóval pótolni.

Egy FAQ-ban Kernighanék szépen elmagyarázzák, hogy miért nincs a Go-ban kivételkezelés. Szerintük ez egyszerűen csak egy bonyolult vezérlési struktúra, ami túlságosan terheli a rendszert, viszont leszoktatja a programozót a "rendes" hibakezelésről. Szerintem viszont rosszul gondolják.

A Go-nak két változata van. Egy GCC frontend (amiről itt szó van) és egy natív compiler/linker, amit kidolgozottabbnak mondanak. Nem értem minek bajlódni architektúrafüggő compilerekkel. A C-re fordítás egyből hordozhatóvá teszi a dolgot.

Melengeti a szívemet, hogy említés esett a CCC-ről. Néhány szó róla: Régi számlázó programok portolására nem alkalmas, viszont az új projektjeinket is ezen írjuk. Tehát él a Clipper! Többszörös öröklődés van benne. Kivételkezelés van benne. C-re fordít. Doksi róla.
--
CCC3

csak egy gondolat a beagyazas vs oroklodes temakorbol: az open-closed principle ertelmeben extendelni konnyen lehessen osztalyokat, es ez elegge egybecseng inkabb az embeddinggel.

viszont ha van egy kontenered, es ugy csinalsz belole read-onlyt, hogy a gyerekosztalyban overrideolod az allapotteret modosito tagokat... szoval az ugy gany, na.

composite objects > inherited objects :)

Érdekes, ahogy változik a szemlélet. 20-30 éve a programozó még egy különleges tudású, tisztelettel övezett ritka emberfajta volt. Mint pl. maga Kernighan. Ma a programozó bajkeverő tömegmunkaerőnek számít. Ez tükröződik a programnyelvek változásában. Nem a programozó produktivitása fontos, hanem a hibák kiszűrése. Mindenesetre a C# szempontjából ez a hajó elment: Benne van az öröklődés -> a programozók keverik a bajt.
--
CCC3

"Meglepődve olvastam a C# 2008 (Trey Nash) könyvben, hogy a szerző szerint az egyszeres öröklődés is túl bonyolult, amit nem tanácsos programozók kezébe adni."

Vagy inkább neki kellene állni *programozókat* képezni ÉS helyretenni a dolgokat a megrendelők fejében.

----------------
Lvl86 Troll