Z čeho se učit C/C++

[frca]

[if.then]

Dnes podle mě není žádný problém v nedostupnosti C++ apod., přičemž v překladači C++ jde zkompilovat skoro každý program v C (případně s malými změnami). Mně se zdá, že OOP je na tvorbu her ideální (samostatné objekty v herním světě), čímž ale nepopírám, že ukazatele jsou také velmi VELMI důležité.
Eosie> Stačí někde prohodit číslo a hned zapisuješ kam nemáš... Když vidíš segmentation fault, tak je jasné, čím to je
_________________
For guns and glory, go to www.ceske-hry.cz.
For work and worry, execute VC++.

[Marek]

Segfault je ještě hodně v pohodě, to se dá vychytat brzo. Memory leaky jsou taky v pohodě, ty se dají vychytat a opravit ještě rychleji a snadněji než segfault. Horší jsou chyby, které způsobí, že algoritmus není korektní. Na tohle už žádný jazyk nepomůže.
_________________
AMD Open Source Graphics Driver Developer

[if.then]

Už umístění tohoto tématu mluví za vše Nevím, proč by měla být Java kvůli garbage collectoru tak opěvovaná. Já tedy rozhodně radši jazyk, kde vím, že jsem chybu způsobil já špatným užíváním, než nevědět nic a bláhově se spoléhat na collector.
_________________
For guns and glory, go to www.ceske-hry.cz.
For work and worry, execute VC++.

[OndraSej]

if.then: pokud jde o umístění, tak souhlas. ještě chvíli a přesunu to aspoň z části do popelnice.

Pokud jde o Javu, tak tam (stejně jako v jiných jazycích) chybu způsobíš pouze špatným užíváním a pokud nějakou způsobíš, tak to zcela jistě poznáš.
_________________
http://trionteam.net

[Augi]

No ale kvůli jisté nedeterminističnosti tu chybu poznáš v té nejméně vhodné chvíli
Jinak volbu GC vs. neGC, resp. managed vs. nativní kód, vidím v požadavcích na efektivitu a časovou náročnost programování. Pokud něco musí být efektivně nebo na to mám hafo času, tak využiji nativní kód.

[OndraSej]

Augi: no ale jaké nedeterminističnosti? Memory leaky (které jdou udělat i s GC) poznáš po podobné době jako bez něj. Chyby spočívající v přístupu ke špatnému kusu paměti neexistují (až na NullPointerException, kterou poznáš okamžitě). A ostatní chyby se GC netýkají, takže se projeví asi tak stejně rychle jako bez něj.
Ale jinak souhlas s tím, že když něco programuju, tak chci se chci soustředit na řešený problém a ne hlídat paměť.
Jinak pokud jde o správu paměti, tak současné GC (přinejmenším ten v Javě) jsou hodně efektivní, včetně toho, že aktuální Java detekuje, jestli objekty může nechat na stacku, takže při rozumném stylu programování spousta dat přes GC vůbec neprojde).
_________________
http://trionteam.net

[Marek]

[Augi]

[Quiark]

Ani nemusíš mít ošklivé cykly, stačí, když ti někde zůstane pointer na celý strom obektů třeba z minulého levelu a je to v pytli

Jinak Eo možná mluvil o této přednášce Tima Sweeneyho (architekt Unreal Engine), kde dependent typy prosazuje. Mimo jiné ale taky říká, že GC by mělo být i pro hry jedinou volbou. Můj názor je ten, že pokud nejste v sektoru AAA, nebo na nějaké pamětí omezené konzoli (to se týká tak 99% lidí tady , tak s GC hru klidně uděláte, stejně jako ji zvládnete udělat bez GC.
_________________
Mám strach

[OndraSej]

Augi: pokud mluvime o GC a ne o pseudoGC (jako pocitani referenci), tak cykly nehraji roli. Hraje ji napriklad kolekce "neaktivnich" objektu, ktera je dostupne odnekud ze stacku a nikdo ji nevyprazdnuje.
_________________
http://trionteam.net

[Augi]

Jojo, to měl bejt jen takovej příklad. Chtěl jsem tím jen říct, že GC neřeší vše - pořád je třeba používat mozek...

[frca]

Slyšeli jste někdy o valgrindu?
_________________
www.FRANTICWARE.com

[Marek]

Myslíš ten debugovací software, co řeší všechny problémy s pamětí v C/C++ ve vlastním virtuálním stroji? Kdo by ho neznal.
_________________
AMD Open Source Graphics Driver Developer

[nou]

no myslim ze vvelmi vela ludi. kedze je linux only. len ma jednu pre mna neprijemnu vlastnost. vypisuje tony memory leakov z cudzich kniznic. neviete ako to odfiltrovat?
_________________
Najjednoduchšie chyby sa najtažšie hľadajú.