Vyplatí se učit C++?

[petron]

neexistuje hlupa otazka, ale len hlupa odpoved

[Reklama]

[tomaszav]

mna by zaujimalo, teda smerujem otazku na tych co mi odporucili FP, ze ako sa to da uplatnit v beznom zivote, v praci a ci sa to da sklbit aj s normalnymi jazykmi, na :-\pr F# so C#.

Moderni aplikace pro browser uz se jinak ani nedelaji. Viz redux

Clojure se pouziva i v enterprise. Viz stranky cognitectu. Klasicky blog o wallmartu kde popisuji jak jim to pomohlo s black friday.

Ostatni se taky bezne pouziva.

Vetsinou FP pomaha pochopit, ze je potreba mit jednoduchy (idealne zadny stav a ostrazitosti k jinym zbytecnym slozitostem.
Hezky o tom mluvi Rich Hickey v te prednasce co jsem postnul vyse. Simple made easy

[Kit]

neexistuje hlupa otazka, ale len hlupa odpoved

A co říkáš na tu knihu Code Complete?

[Inkvizitor]

Viacerí to vidíte príliš čierno-bielo. Ja by som nepovedal, že tuple je jediné správne riešenie. Práve tuple je dobrý možno len na nejaké špeciality, teda skoro nikdy Aj keď teraz možno preháňam, lebo sa nepohybujem v oblastiach, kde je naozaj užitožný a prehľadný zároveň.
S tuple je to ešte neprehľadnejšie, lebo výstupné premenné majú aspoň nejaký názov, podľa ktorého je jasné, o čo ide, tuple nemá nič, len poradové číslo. Navyše ak chcem volať nejakú metódu, kde tie parametre nie sú čisto výstupné, ale sa použije aj ich aktuálna hodnota (napr. pričítavanie) tak by musl byť tuple na vstupe aj na výstupe a hodnoty by sa museli kopírovať.

V c# je to pekne vyriešené, že v deklarácii funkcie, aj pri jej volaní treba explicitne písať, keď je nejaký parameter výstupný, alebo vstupný aj výstupný.

Především "výstupní parametr" v pravém slova neexistuje (jakkoliv se v tomto významu to slovo používá). Parametr funkce, metody, programu říká, jak nebo z čeho má probíhat výpočet. K výstupu z funkce je určena návratová hodnota. Na jednu stranu rozumím argumentu, že ty výstupní hodnoty v tuple nejsou pojmenované, ale to přece platí i pro funkci, která vrací jednu hodnotu. Jaký má výstupní hodnota význam, je popsáno v dokumentaci, případně to vyplývá z názvu. Příkladem dobrého použití dvou návratových hodnot je třeba funkce divmod() v Pythonu. Je obecně dobrý nápad mít vícero výstupních hodnot? Podle mě moc ne, ale když se to nepřežene, problém v tom nevidím. Docela dobře to má řešeno Go, tam se výstupní hodnoty v deklaraci funkce dají pojmenovat. Přesto se domnívám, že podstatně lepší je použít něco jako Either (Haskell a spol.). Neomezené míchání "vstupních a výstupních parametrů" považuju ovšem za vůbec nejhorší řešení, jakkoliv je bez diskuse nejflexibilnější. Pak je ovšem otázka, proč se nezbavit návratové hodnoty úplně, protože ta se pak stává poněkud nadbytečnou.

[Inkvizitor]

neexistuje hlupa otazka, ale len hlupa odpoved

Je tučňák lepší než vidlička?

[Reklama]

[hu]

neexistuje hlupa otazka, ale len hlupa odpoved

Je tučňák lepší než vidlička?

Tučňáka bez vidličky nesežereš. A žabinec bez brčka neusmažíš!

[petron]

A co říkáš na tu knihu Code Complete?

ta sa mi tiez pozdava, len je to knizka z roku 2004 myslim, a neviem, ci by nebolo lepsie nejaku novsiu.

[petron]

neexistuje hlupa otazka, ale len hlupa odpoved

A co říkáš na tu knihu Code Complete?

[Ondřej Novák]

Především "výstupní parametr" v pravém slova neexistuje (jakkoliv se v tomto významu to slovo používá).

No, návratová hodnota je převzata z matematiky kdy funkce vrací jednu hodnotu, nebo vektor nebo matici. Ale já tvrdím že návratová hodnota neexistuje. Místo toho mám radši, když součástí argumentů je reference na místo, kam se má výsledek uložit. Umožňuje to mít funkci která má víc návratových hodnot ... když už může mít víc vstupních parametrů.

PS: Je to lehce silvestrovský příspěvek abych pošťouchnul zdejši evangelisty, nicméně třeba C++ takto návratovou hodnotu implementuje pro typy větší než integer. Podobný koncept používám u future/promise. Při otázce, zda je lepší, když funkce vrací future, nebo když ji předám promise volím spíš druhou možnost.

[JS]

mna by zaujimalo, teda smerujem otazku na tych co mi odporucili FP, ze ako sa to da uplatnit v beznom zivote, v praci a ci sa to da sklbit aj s normalnymi jazykmi, napr F# so C#.

Samozrejme, ze se FP da v praxi uplatnit, ale jako koncept spis nez v konkretnim FP jazyce. FP uci dobremu navrhu, protoze stavi programovani na mnohem pevnejsi matematicke zaklady. Napriklad vezmi si LINQ v C# - to ma dobre API proto, ze se za nim skryvaji monady. Dobre to ukazuje treba knizka https://www.manning.com/books/functional-programming-in-scala.

[JS]

No, návratová hodnota je převzata z matematiky kdy funkce vrací jednu hodnotu, nebo vektor nebo matici. Ale já tvrdím že návratová hodnota neexistuje. Místo toho mám radši, když součástí argumentů je reference na místo, kam se má výsledek uložit. Umožňuje to mít funkci která má víc návratových hodnot ... když už může mít víc vstupních parametrů.

Hloupost.. V matematice funkce zobrazuje z jedne hodnoty do jine, a formalne funkce s vice parametry prijimaji n-tici (tuple), a stejne tak mohou n-tici vratit (alternativne se da oboji - vice vstupnich i vice vystupnich parametru - resit pres currying, tedy vraceni funkci).

Klasicky priklad funkce kde je uzitecne vratit vic argumentu je celociselne deleni. V matematice je to jedno, ale v pocitacich chceme delit jenom jednou, ne dvakrat.

PS: Je to lehce silvestrovský příspěvek abych pošťouchnul zdejši evangelisty, nicméně třeba C++ takto návratovou hodnotu implementuje pro typy větší než integer. Podobný koncept používám u future/promise. Při otázce, zda je lepší, když funkce vrací future, nebo když ji předám promise volím spíš druhou možnost.

To jak to ktery jazyk implementuje je irelevantni, u jazyka je asi podstatnejsi pohodli programatora. Stejne jako u vraceni tuplu vs predavani parametru odkazem, future jsou spis funkcionalni, kdezto promises jsou imperativni konstrukt.

[nativist]

Já tedy programuju v C++ a nemám pocit, že bych něco dělal dlouho jen proto, že si někdo myslí, že v C++ se to musí programovat dlouho a je to složité. Taky si nepíšu nic v ASM, proč bych to dělal? Používám C++ spíš jako ... Javu. Používám vektory, mapy, stringy, streamy, iterátory atd, pokud už něco někde alokuju, tak na to používám chytré ukazatele, počítání referencí - já vím, že má problémy s cykly a není tedy plnhodnotnou náhradou GC, ale ... 95% problémů to nemusím řešit a GC je vlastně takový kanón na vrabce. Tam kde to musím řešit, tam se vždycky najde nějaké jiné řešení, třeba pomocí jednoduchého GC který řeší konkrétní případ (registrace a odregistrace uzlů do kontejneru stojícího mimo dynamickou strukturu, atd)

Když srovnám Javu a C++ z hlediska pohodlnosti vývoje, tak

• 80% kódu v Javě se dá zapsat stejně v C++ a jeho vývoj bude trvat stejně dlouho
• Java zvládá dobře správu paměti která způsobuje, že nad spoustou věcí nemusím přemýšlel, třeba právě u nějakých hodně propojených struktur, kde hrozí cykly
• naopak C++ má RAII, který mi umožňuje nemyslet na uvolňování jiných resourců (síťová spojení, např., ale třeba různé věci okolo zámků a podobně. Dále samozřejmě různé buildery, které v destruktoru provedou vlastní sestavení výsledku a předání patřičnému příjemci
• V C++ je výhodou generika, v Javě je to spíš hack a výsměnch
• Java pro změnu má obrovské množství knihoven na všechno. Nemusím tak vymýšlet algoritmy, které již někdo vymyslel. Nevýhodou je, že ne všechny ty algoritmy jsou implementovány chytře a vyhovují mým potřebam. V C++ jsem si většinu knihovní báze musel napsat sám
• V C++ lépe řeší různé binární formáty
• V C++ zvládá lépe dědičnost, vícenásobnou dědičnost, virtuální dědičnost - jo, taky to často potřebuju. Java naopak je pochopitelnější pro méně zdatné jedince, protože tohle nemá
• C++ má větší možnosti v definování vlastních operátorů, což otevírá možnosti k většímu přizpůsobení jazyka a přehlednějšímu kódu, přímočařejším zápisům, což ale u méně zdatných jedinců vede k prasení kódu a je kontraproduktivní. Java nic takového nemá, proto prasení kódu redukuje

Tento výčet popisoval zbývajících 20% rozdílů. Pokud někdo programuje rychleji v Javě, než v C++, bude to tím, že se naučil Javu a nenaučil se C++. U mě je to například obráceně.

Buďme rádi, že Java existuje, výběh pro patlaly se hodí. Noční můrou by bylo, kdyby se tato sorta lidí pokoušela psát aplikace v C nebo C++. Člověku, co zná jen Javu (a tudíž ji fanaticky hájí a vynáší do nebes, jako noef), se nedá vysvětlit, že C++ je stejně high level jazyk. Prase se taky těžko přesvědčuje, aby se neválelo ve vlastních ho..ech.

[Petr Novák]

V některých případech kompilátor C++ (aspoň GCC 4. může vysypat rychlejší strojový kód se strukturou v návratové hodnotě než s voláním odkazem. Např. právě u toho dělení a modula. Samožná definice struktury v C++ je "zadarmo" narozdíl od Javy (žádný bytecode, konstruktor, alokace, je to jen informace pro kompilátor). Při vrácení struktury se kdysi vytvořila struktura na zásobníku před voláním funkce a do funkce se poslal odkaz, takže to bylo stejné, jako by se totéž udělalo ručně s jednotlivými položkami struktury. Voláním odkazem se tedy téměř nic nezískalo. Moderní kompilátor ale dokáže víc: pokud se funkce inlinuje, což bude případ dělení / modulo, pak může výsledek v registrech rax/rdx rovnou použít v dalším výrazu a bude zhruba stejně efektivní, jako by dělění a modulo byly součásti většího výrazu a přitom se provede pouze jedna operace dělení. Tedy získáme něco, co dřívě šlo získat pouze naprogramováním celého výrazu v assembleru.

Obecně se v C++ vyplatí napsat kód nejprve bez zbytečných prasáren, nechat si vyjet assembler (gcc -s) a teprve při nespokojenosti optimalizovat prasárnami. GCC 4.8 optimalizuje jak ďábel a řekl bych že lépe než Visual C++.

[JS]

V některých případech kompilátor C++ (aspoň GCC 4. může vysypat rychlejší strojový kód se strukturou v návratové hodnotě než s voláním odkazem.

To je vynikajici poznamka! Jeste markantnejsi je to v jazycich s GC, napriklad Common Lisp ma moznost vraceni vice navratovych hodnot prave z toho duvodu, ze by sice bylo pomerne snadne vratit seznam, akorat seznam by znamenal alokaci na halde, kdezto vice navratovych hodnot se ulozi na zasobnik.

[noef]

<trolling>Buďme rádi, že Java existuje, výběh pro patlaly se hodí. Noční můrou by bylo, kdyby se tato sorta lidí pokoušela psát aplikace v C nebo C++.</trolling>

Člověku, co zná jen Javu (a tudíž ji fanaticky hájí a vynáší do nebes, jako noef), se nedá vysvětlit, že C++ je stejně high level jazyk.

<trolling>Prase se taky těžko přesvědčuje, aby se neválelo ve vlastních ho..ech.</trolling>

Opravdu? Vidim tu snahu o trolling, protoze vas prispevek nejen, ze je jak od lopaty, navic je nepravdivy. (Coz nabizi otazku, zda opravdu neni od lopaty, ze...) Rozhodne neznam jen Javu, nejnovejsi verzi jsem dokonce snad ani nepouzil. Usekl jste si pekny trapas, vzdyt primo v tomto vlaknu propaguji Scalu a alternativni pristupy nekolikatou stranu (zminl jsem napr. i Haskell, Frege a F#).

A ze bych Javu vychvaloval, nebo dokonce "vynasel do nebes", to myslite opravdu vazne? Protoze asi nejste prilis bystry, tak mi nezbyva, nez se citovat:

... Nevim, jestli se citite urazen vyrokem, ze C++ je spatlanina (pejsek a kocicka), ale je to bohuzel pravda. A rozhodne to nerikam proto, abych "vyhral" diskuzi. Podobny nazor mam i na JavaScript, ve kterem nyni prevazne pracuji. A prestoze Java mi prijde o trochu lepsi, tak ma take hodne much (nejvetsi asi generika, ve srovnani s C# je to slabota, a to .NET moc nemusim). ...

Ja nepopiram high-level aspekt C++, jen jsem rikal, ze pokud pouzivate tento high-level pristup, tak je jedno, jestli delate v C++ nebo v Jave, dosahnete vykonostne stejneho vysledku (dokonce tu nekdo zminoval nejakou studii od Googlu). Pokud se pujde vice "low-level", tak velkym rozdilem bude cas a narocnost vyvoje vymenou za lepsi vykon. Tzn. napsat projekt v C++ vyjde zadavatele v kazdem pripade draz, nez v Jave. Vysledny produkt u high-level pristupu, pominu-li pametovou narocnost, bude davat stejne rychle stejne vysledky a tudiz je rozdilem pouze cena prace. Vzhledem k tomu, ze Java je navrzena tak, aby v ni mohl zacit delat skoro kdokoliv (az se nabizi ono drazdive slovo "opice"), se neni cemu divit, ze hodinova sazba zacinajiciho Javisty a CPPisty se asi budou pomerne dost lisit. No a u "low-level" pristupu s rucnim tunenim pristupu k pameti a opravdovymi zisky na vykonu to vyjde zakaznika velmi draho, protoze hodinova cena C++ profika je velmi vysoka. A tak se deje, ze vsichni, pokud neni opravdu zbyti (hry*, embeded), voli variantu malinko pomalejsi aplikaci + vice pameti (ktera je nyni smesne levna) a mene programovani (ktere je stale velmi drahe).

Predchozi tvzreni podporuje i Tiobe index. Nevim tedy, jak moc je realne vypovidajici, ale C++ vykazuje celkem patrny trend - dlouhodoby postupny pokles.

*: U indie her se davno pouzivaji "pomale" jazyky jako C# a Java. Co je zajimave, ze uz i do AAA her zacinaji prorazet, prestoze spise jen pro skriptovani a UI, jazyky a technologie jako Adobe Air (v podstate Flash, UI v MMORPG, napr. Tera), Lua (napr. addony ve WoW) nebo JavaScript (skriptovani v Unity Enginu).

PS: Patlat a bastlit se da v jakemkoliv jazyku, to ze delate v C++ z vas lepsiho programatora nutne nedela .