Vyplatí se učit C++?

[borekz]

Sice to není úplné RAII, ale při použití rozhraní Autocloseable v Javě zrovna u toho SQL dosáhneš podobného výsledku.

Přiznám se, že o tomto jsem nevěděl. Většina projektů v naší firmě zamrzla na JDK 1.6. Taky je dobrý switch se stringy.

[Reklama]

[Pavel Tišnovský]

Sice to není úplné RAII, ale při použití rozhraní Autocloseable v Javě zrovna u toho SQL dosáhneš podobného výsledku.

Přiznám se, že o tomto jsem nevěděl. Většina projektů v naší firmě zamrzla na JDK 1.6. Taky je dobrý switch se stringy.

To je škoda, protože Java se docela vyvíjí (i když já osobně za nejlepší na Javě považuju JVM, ne ten jazyk :-). Na druhou stranu znám projekty, které z různých důvodů používají pořád 1.4.2 (a pořád se na nich něco upravuje).

[Pavel Tišnovský]

Sice to není úplné RAII, ale při použití rozhraní Autocloseable v Javě zrovna u toho SQL dosáhneš podobného výsledku.

Přiznám se, že o tomto jsem nevěděl. Většina projektů v naší firmě zamrzla na JDK 1.6. Taky je dobrý switch se stringy.

Jinak když se podíváš na docku (http://docs.oracle.com/javase/8/docs/api/java/lang/AutoCloseable.html), tak ve std. knihovně se to používá kdekoli je možné. A samozřejmě to nebrání využití ve vlastních třídách, dokonce se ani nemusí jednat o žádné skutečné "resources", ale cokoli, kde je zapotřebí mít přesně specifikovaný okamžik volání metody pro uvolnění prostředku.

[zboj]

Sice to není úplné RAII, ale při použití rozhraní Autocloseable v Javě zrovna u toho SQL dosáhneš podobného výsledku.

Přiznám se, že o tomto jsem nevěděl. Většina projektů v naší firmě zamrzla na JDK 1.6. Taky je dobrý switch se stringy.

To je škoda, protože Java se docela vyvíjí (i když já osobně za nejlepší na Javě považuju JVM, ne ten jazyk :-). Na druhou stranu znám projekty, které z různých důvodů používají pořád 1.4.2 (a pořád se na nich něco upravuje).

Tak ono to je něco jako using v C#. Na správu všeho kromě paměti by to mělo být povinné (v code guidelines).

[hu]

Tak ono to je něco jako using v C#. Na správu všeho kromě paměti by to mělo být povinné (v code guidelines).

Otazka je, proc rozlisovat mezi spravou pameti a libovolneho jineho prostredku. Podle me GC akorat u patlalu vytvari dojem, ze se o spravu zdroju neni treba starat.

[Reklama]

[Kit]

Podle me GC akorat u patlalu vytvari dojem, ze se o spravu zdroju neni treba starat.

Podle mne absence GC v C++ vytváří u profesionálů dojem, že o správu zdrojů je nutné se starat.

[L.]

Otazka je, proc rozlisovat mezi spravou pameti a libovolneho jineho prostredku. Podle me GC akorat u patlalu vytvari dojem, ze se o spravu zdroju neni treba starat.

Protože paměť používáš (vytváříš nové objekty) typicky řádově častěji, než otevíráš/zavíráš jakékoli jiné prostředky. A také je mnohem častěji předáváš mezi scope.

Já se tedy mnohem raději věnuji podstatě problému, než řeším technikálie okolo prostředků, které si počítač (VM) může dostatečně dobře ošetřit i sám.

[zboj]

Tak ono to je něco jako using v C#. Na správu všeho kromě paměti by to mělo být povinné (v code guidelines).

Otazka je, proc rozlisovat mezi spravou pameti a libovolneho jineho prostredku. Podle me GC akorat u patlalu vytvari dojem, ze se o spravu zdroju neni treba starat.

Psal jsem v kontextu Javy. Tracing GC jinak samozřejmě své nevýhody má, je ale třeba hodnotit každou implementaci zvlášť. Například v Androidu je úplně debilní, kdežto v Go (od verze 1.5) hodně kvalitní a bez problémů použitelná i pro velké aplikace. Obecně je nejlepší správa paměti na zásobníku (jako v C++/Go/Swift) a když už musí být objekt alokován na haldě, tak nějaká forma sledování referencí (k tomu existuje množství benchmarků a akademických článků). To ale není téma pro patlaly

[zboj]

Otazka je, proc rozlisovat mezi spravou pameti a libovolneho jineho prostredku. Podle me GC akorat u patlalu vytvari dojem, ze se o spravu zdroju neni treba starat.

Protože paměť používáš (vytváříš nové objekty) typicky řádově častěji, než otevíráš/zavíráš jakékoli jiné prostředky. A také je mnohem častěji předáváš mezi scope.

Já se tedy mnohem raději věnuji podstatě problému, než řeším technikálie okolo prostředků, které si počítač (VM) může dostatečně dobře ošetřit i sám.

Otázka je, co znamená "dostatečně dobře". Pro každou konkrétní aplikaci asi něco trochu jiného.

[Sten]

Jinak když se podíváš na docku (http://docs.oracle.com/javase/8/docs/api/java/lang/AutoCloseable.html), tak ve std. knihovně se to používá kdekoli je možné. A samozřejmě to nebrání využití ve vlastních třídách, dokonce se ani nemusí jednat o žádné skutečné "resources", ale cokoli, kde je zapotřebí mít přesně specifikovaný okamžik volání metody pro uvolnění prostředku.

Škoda, že to Oracle udělal nekompatibilní s Javou 7, takže třeba na Androidu to půjde použít až tak za pět let. Na druhou stranu existuje Project Lombok.

[hu]

Protože paměť používáš (vytváříš nové objekty) typicky řádově častěji, než otevíráš/zavíráš jakékoli jiné prostředky. A také je mnohem častěji předáváš mezi scope.

Já se tedy mnohem raději věnuji podstatě problému, než řeším technikálie okolo prostředků, které si počítač (VM) může dostatečně dobře ošetřit i sám.

Jo, od toho jsou v C++ genericky RAII wrappery jako shared_ptr. Nema cenu se tady nejak extra dohadovat, ja proste nemam Javu rad, a to neni nic moc racionalniho :-) (i kdyz par relevantnich argumentu bych asi z klobouku vytahl).

[andy]

Kde v předchozím příspěvku tvrdím, že jsem odborník ? Ani pořádně neovládám virtuální desktruktory při vícenásobné dědičnosti nebo novinky v C++14.

To som reagoval na toto:
(sry nemal som cas moc)

Mně zase fascinuje to kvantum odborníků, kteří vědí, že C++ je lowlevel

Nikde som nepisal, ze to je low level, ale ze ked ta zaujimaju take veci, tak je to dobre vediet (cize opacne). Pre mna je dobre vediet c++ na takej urovni, aby som si mohol precitat zdrojaky napr v8, ale ked idem robit nejaku formularovu web aplikaciu, tak o c++ neuvazujem. C++ je celkom univerzalne, ale ma svoje muchy a stale plati, ze cas su peniaze. Mimochodom preco si mozilla navrhla vlastny jazyk, ked c++ je take uzastne? Este aj google zvolil taky postup.

Jo, od toho jsou v C++ genericky RAII wrappery jako shared_ptr. Nema cenu se tady nejak extra dohadovat, ja proste nemam Javu rad, a to neni nic moc racionalniho :-) (i kdyz par relevantnich argumentu bych asi z klobouku vytahl).

Ja mam napr velmi rad to co dokaze jvm, ale ze by som mal rad co to znamena v praxi (napr pamatova nenazranost) to sa neda povedat .

[hu]

Psal jsem v kontextu Javy. Tracing GC jinak samozřejmě své nevýhody má, je ale třeba hodnotit každou implementaci zvlášť. Například v Androidu je úplně debilní, kdežto v Go (od verze 1.5) hodně kvalitní a bez problémů použitelná i pro velké aplikace. Obecně je nejlepší správa paměti na zásobníku (jako v C++/Go/Swift) a když už musí být objekt alokován na haldě, tak nějaká forma sledování referencí (k tomu existuje množství benchmarků a akademických článků). To ale není téma pro patlaly

Ted nevim, jestli jsem vztahovacnej, nebo z textu citim implicitni zarazeni me osoby do mnoziny patlalu :-) S tebou uvedenym souhlasim, a ackoliv to nemam podlozeno benchmarky a clanky, z intuitivniho hlediska mi prijde GC jako kanon na vrabce. Takova dalsi vrtstva izolace mezi vyvojarem a hw uz imho presahuje mezni uzitek z abstraktniho pristupu k programovani, protoze umoznuje se nestarat o jiz prilis podstatnou soucast programu - pamet.

[zboj]

Protože paměť používáš (vytváříš nové objekty) typicky řádově častěji, než otevíráš/zavíráš jakékoli jiné prostředky. A také je mnohem častěji předáváš mezi scope.

Já se tedy mnohem raději věnuji podstatě problému, než řeším technikálie okolo prostředků, které si počítač (VM) může dostatečně dobře ošetřit i sám.

Jo, od toho jsou v C++ genericky RAII wrappery jako shared_ptr. Nema cenu se tady nejak extra dohadovat, ja proste nemam Javu rad, a to neni nic moc racionalniho :-) (i kdyz par relevantnich argumentu bych asi z klobouku vytahl).

Tak RAII je asi nejlepší způsob správy zdrojů (případně defer, což je to samé v bledě modrém třeba v Go). Navíc plně transparentní. Na druhou stranu chápu lopaty zastávající se GC. Jedem das Seine

[zboj]

Psal jsem v kontextu Javy. Tracing GC jinak samozřejmě své nevýhody má, je ale třeba hodnotit každou implementaci zvlášť. Například v Androidu je úplně debilní, kdežto v Go (od verze 1.5) hodně kvalitní a bez problémů použitelná i pro velké aplikace. Obecně je nejlepší správa paměti na zásobníku (jako v C++/Go/Swift) a když už musí být objekt alokován na haldě, tak nějaká forma sledování referencí (k tomu existuje množství benchmarků a akademických článků). To ale není téma pro patlaly

Ted nevim, jestli jsem vztahovacnej, nebo z textu citim implicitni zarazeni me osoby do mnoziny patlalu :-) S tebou uvedenym souhlasim, a ackoliv to nemam podlozeno benchmarky a clanky, z intuitivniho hlediska mi prijde GC jako kanon na vrabce. Takova dalsi vrtstva izolace mezi vyvojarem a hw uz imho presahuje mezni uzitek z abstraktniho pristupu k programovani, protoze umoznuje se nestarat o jiz prilis podstatnou soucast programu - pamet.

Naopak, byli myšlení patlalové z citovaného příspěvku.