Bude za pár let kvalitní, zaměstnatelný programátor nedostatkové zboží?

[zboj]

Skoro - použití GC je (velmi často, ne vždy) zbytečnost, ale má svůj super use case - neprogramátoři, prototypování, v některých případech i v produkci.
Nevidím problém v tom si paměť uvolnit sám, přesně v moment, kdy má být uvolněna. Typicky v Cčku na malloc pohlížím jako na blok - když napíšu malloc, hned pod něj píšu free a kód strčím mezi. Při dodržení single exit point je to velmi spolehlivé.
...
Ano, uvnitř bloku se může stát ledacos špatného, ale buď je to správně ošetřeno, nebo to není tak kritické a blok dojede včetně free, nebo to třeba segfaultne a paměť se mi uvolní tak nějak přirozeně , nebo je to ve stavu, ve kterém to nikdy nemělo být a musí se to vyřešit. Tohle ani GC nezachrání.

Jasně, takže....:

Kód: [Vybrat]

v1 = priprav_objekt();
v2 = pripav_objekt_2(v1);
if (v2 == null) {
   free(v1);
   return;
}
v3 = priprav_objekt_3(v1, v2);
if (v3 == null) {
   free(v2);
   free(v1);
}

Jasně, dá se to trošku vylepšit těma "goto" a la linux kernel, případně nějakým jedním místem, kde uvolním všechno, co není null... nedejbože, aby na ten objekt ukazovalo něco od někud jinud, že....

Hodně debilní kód, není divu, že software vypadá, jak vypadá. Na tomto příkladu je vidět, jak by javista psal v C, kdyby ho k tomu pustili. Zůstaňte fakt radši u bicyklu s postranními kolečky, přechod na Porsche opravdu nedopadne dobře.

Tak co udelas misto toho? Slozis to ze trech volani v matrjosce, ze kterych nebude jasne, o co jde, ze kod znamena

Kód: [Vybrat]

v1 = priprav1()
v2 = priprav2()
c2 = priprav3()

a zbytek je omacka?

Ne. Ze všeho nejdřív bych se podíval, jestli jde předávat objekty na zásobníku. Pokud ne, tak použiju nějakou formu správy paměti (jako v GCD). A pokud to z nějakého důvodu není v žádném případě žádoucí, tak použiju makro, které mi zajistí úklid ve všech větvích kódu, na unixech by bylo například udělané pomocí __attribute__(cleanup). Existují i jiné způsoby, ale ne tak univerzální, např. jen pro kód běžící v rámci nějaké smyčky událostí, ale to už moc odbočuju.

A co tím získáte, když funkci GC simulujete pomocí makra.

Muze tvrdit, ze nepouziva GC a neni loser.

Jestli v tom nevidíš rozdíl, tak je jakákoliv diskuse bezpředmětná.

[Reklama]

[Ondra Satai Nekola]

Ono hlavne pro tohle vubec nemusis kod zaplacavat nejakymi makry...

[andy]

Právě jsi porušil ten single exit, čímž jsi to dokonale zprasil.
Jestli je podle tebe normální na každý pár alokace a free napsat 4 řádky kódu, který s tím pracuje, pak ano, třetina kódu bude memory management a v takovém případě zůstaň u něčeho s GC, stejně to tím nevytrhneš.

Vždyť jsem odkazoval na Linux:

Kód: [Vybrat]

v1 = priprav_v1();
if (v1 == null) 
  goto exit_v1;
v2 = priprav_v2();
if (V2 == null)
  goto exit_v2;
v3 = priprav_v3();
if (v3 == null)
  goto exit_v3;
return v3;
exit_v3:
  free(v2);
exit_v2:
  free(v1);
exit_v1:
 return NULL;

Takhle vypadá kód Linuxu, IMO to moc líp nejde. Máš lepší nápad? Sem s tím.

na unixech by bylo například udělané pomocí __attribute__(cleanup).

Nebo v C++ SmartPointry aka reference counting, který pak třeba zvládnou i to, když v té alokaci pošlu ten objekt někam jinam. Což už je vlastně primitivní GC, které akorát neumí cykly.

Hmm....

Jestli v tom nevidíš rozdíl, tak je jakákoliv diskuse bezpředmětná.

Pokud nepíšu real-time systémy, tak v tom fakt rozdíl není, kromě toho, že to ty cykly neumí....

[zboj]

Právě jsi porušil ten single exit, čímž jsi to dokonale zprasil.
Jestli je podle tebe normální na každý pár alokace a free napsat 4 řádky kódu, který s tím pracuje, pak ano, třetina kódu bude memory management a v takovém případě zůstaň u něčeho s GC, stejně to tím nevytrhneš.

Vždyť jsem odkazoval na Linux:

Kód: [Vybrat]

v1 = priprav_v1();
if (v1 == null) 
  goto exit_v1;
v2 = priprav_v2();
if (V2 == null)
  goto exit_v2;
v3 = priprav_v3();
if (v3 == null)
  goto exit_v3;
return v3;
exit_v3:
  free(v2);
exit_v2:
  free(v1);
exit_v1:
 return NULL;

Takhle vypadá kód Linuxu, IMO to moc líp nejde. Máš lepší nápad? Sem s tím.

na unixech by bylo například udělané pomocí __attribute__(cleanup).

Nebo v C++ SmartPointry aka reference counting, který pak třeba zvládnou i to, když v té alokaci pošlu ten objekt někam jinam. Což už je vlastně primitivní GC, které akorát neumí cykly.

Hmm....

Jestli v tom nevidíš rozdíl, tak je jakákoliv diskuse bezpředmětná.

Pokud nepíšu real-time systémy, tak v tom fakt rozdíl není, kromě toho, že to ty cykly neumí....

1. Doporučuji podívat se na kód Grand Central Dispatch.
2. Zrovna pro real-time systémy se RC moc nehodí, ale to je úplně jiný kontext, ve kterém diskuse o GC moc nedává smysl.

[v]

Takhle vypadá kód Linuxu, IMO to moc líp nejde. Máš lepší nápad? Sem s tím.

"...if free(ptr) has already been called before, undefined behavior occurs. If ptr is NULL, no operation is performed. "
někteří pak preferují do { if (...) break; } while(0) místo skoků

[Reklama]

[zboj]

Právě jsi porušil ten single exit, čímž jsi to dokonale zprasil.
Jestli je podle tebe normální na každý pár alokace a free napsat 4 řádky kódu, který s tím pracuje, pak ano, třetina kódu bude memory management a v takovém případě zůstaň u něčeho s GC, stejně to tím nevytrhneš.

Vždyť jsem odkazoval na Linux:

Kód: [Vybrat]

v1 = priprav_v1();
if (v1 == null) 
  goto exit_v1;
v2 = priprav_v2();
if (V2 == null)
  goto exit_v2;
v3 = priprav_v3();
if (v3 == null)
  goto exit_v3;
return v3;
exit_v3:
  free(v2);
exit_v2:
  free(v1);
exit_v1:
 return NULL;

Takhle vypadá kód Linuxu, IMO to moc líp nejde. Máš lepší nápad? Sem s tím.

na unixech by bylo například udělané pomocí __attribute__(cleanup).

Nebo v C++ SmartPointry aka reference counting, který pak třeba zvládnou i to, když v té alokaci pošlu ten objekt někam jinam. Což už je vlastně primitivní GC, které akorát neumí cykly.

Hmm....

Jestli v tom nevidíš rozdíl, tak je jakákoliv diskuse bezpředmětná.

Pokud nepíšu real-time systémy, tak v tom fakt rozdíl není, kromě toho, že to ty cykly neumí....

BTW stačilo by jedno návěstí. Fakt super, když někdo chce kódem v jazyce, jejž neovládá, podpořit nějaké své tvrzení...

[v]

2. Zrovna pro real-time systémy se RC moc nehodí, ale to je úplně jiný kontext, ve kterém diskuse o GC moc nedává smysl.

můžete to rozvést?

[javaman ()]

Jen ho pořádně nakrmte On nic rozvádět nebude, protože si sem přišel pro ego boost přes nějaké nesmysly. Vlastně to není poprvé, co? Jen pak zbytečně zapadnou příspěvky od lidí, kteří nejsou tak hloupí jako on.

[zboj]

2. Zrovna pro real-time systémy se RC moc nehodí, ale to je úplně jiný kontext, ve kterém diskuse o GC moc nedává smysl.

můžete to rozvést?

RC typicky používá běžné malloc/free, jež jsou nedeterministické. Nic jiného jsem tím nemyslel. Fungovalo by to s deterministickým alokátorem, nicméně při uvolnění taky člověk obecně neví, kolik objektů se lavinově uvolní. Proto real-time software paměť moc dynamicky nealokuje, leda tak na začátku nebo v nějaké neomezené pauze.

[andy]

BTW stačilo by jedno návěstí.

Jo, stačilo, pravda. Pokud bych nedělal nějakou další alokaci zdrojů, případně pokud by nebylo nutné volat destruktory, protože ty objekty třeba ukazují na něco jiného.... což ve složitějším projektu opravdu dělat nebudeme, že...

Fakt super, když někdo chce kódem v jazyce, jejž neovládá, podpořit nějaké své tvrzení...

No, fascinuje mě, jak na takovémhle případu zjistíš, že C neovládám....

[v]

2. Zrovna pro real-time systémy se RC moc nehodí, ale to je úplně jiný kontext, ve kterém diskuse o GC moc nedává smysl.

můžete to rozvést?

RC typicky používá běžné malloc/free, jež jsou nedeterministické. Nic jiného jsem tím nemyslel. Fungovalo by to s deterministickým alokátorem, nicméně při uvolnění taky člověk obecně neví, kolik objektů se lavinově uvolní. Proto real-time software paměť moc dynamicky nealokuje, leda tak na začátku nebo v nějaké neomezené pauze.

RC je obecný koncept, nezávislý na jazyku, spojovat to s malloc/free je tedy poněkud nevhodné a říct, že malloc/free jsou nedeterministické taky není dobře, většinou jistě ano, ale můžete si vytvořit vlastní implementaci (někdy aplikaci stačí i jenom malloc)

[zboj]

BTW stačilo by jedno návěstí.

Jo, stačilo, pravda. Pokud bych nedělal nějakou další alokaci zdrojů, případně pokud by nebylo nutné volat destruktory, protože ty objekty třeba ukazují na něco jiného.... což ve složitějším projektu opravdu dělat nebudeme, že...

O desturktorech viz předchozí stránka.

[zboj]

2. Zrovna pro real-time systémy se RC moc nehodí, ale to je úplně jiný kontext, ve kterém diskuse o GC moc nedává smysl.

můžete to rozvést?

RC typicky používá běžné malloc/free, jež jsou nedeterministické. Nic jiného jsem tím nemyslel. Fungovalo by to s deterministickým alokátorem, nicméně při uvolnění taky člověk obecně neví, kolik objektů se lavinově uvolní. Proto real-time software paměť moc dynamicky nealokuje, leda tak na začátku nebo v nějaké neomezené pauze.

RC je obecný koncept, nezávislý na jazyku, spojovat to s malloc/free je tedy poněkud nevhodné a říct, že malloc/free jsou nedeterministické taky není dobře, většinou jistě ano, ale můžete si vytvořit vlastní implementaci (někdy aplikaci stačí i jenom malloc)

Však to píšu, že existuje i deterministický alokátor. U real-time softwaru je prostě problém jakýkoliv vyšší koncept, nejen RC nebo GC, neboť když nevím, jak přesně se něco chová, nemůžu garantovat, že mi to nerozhodí běh programu.

[daemon]

ale proč by měli všichni psát tak, aby to po nich ta opice dokázala přečíst?

Počkej počkej, doufám, že tím nechceš říct, že spagetti kód je v pořádku a "opravdový programátor" (!opice) se v něm přece vyzná?

[Tuxik]

No jestli tu někdo tvrdí, že něco umí a pak to udělá nejhorším možným způsobem, tak to buď neumí, nebo... nebo nevím co, v každým jazyce a s jakoukoliv technologií se dá napsat škaredej kód. To nic nedokazuje.
Jinak k věci...

Kód: [Vybrat]

a = blbost(30);
b = kravina(a);
c = volovina(b);

pak stačí otestovat, jestli je c null, protože kontroly vstupů jsou přesně tam, kde mají být a to na začátku blbosti, kraviny a voloviny.