Vyplatí se učit C++?

[zboj]

a keby som sa chcel posunut dalej vo vyvoji napr. v .NET/C#, co by ste odporucali? Alebo vseobecne v software development. To C++ je mozno trosku fakt z cesty sa ucit, chcel som len ze na svoj osobny rozvoj, ale nema to zmysel. radsej nieco ine.
btw. uvazujem nad kupou knizky z nejakych tychto:

http://www.amazon.com/gp/product/0735667454/ref=s9_simh_hd_bw_p14_d0_i2?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=merchandised-search-11&pf_rd_r=0WKK52JFVGPGZKSQYP19&pf_rd_t=101&pf_rd_p=5d93ad61-3c6e-574d-b199-b95bffe7d849&pf_rd_i=4011

http://www.amazon.com/Writing-High-Performance-NET-Code-Watson/dp/0990583430/ref=sr_1_46?s=books&ie=UTF8&qid=1451342246&sr=1-46

http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=pd_sim_14_6?ie=UTF8&dpID=515iO%2B-PRUL&dpSrc=sims&preST=_AC_UL160_SR131%2C160_&refRID=0A3HQWJGWQ2BXN1TJTC2

C++/CLI, to je .NET a občas se hodí. Případně C++/CX, to přímo komunikuje s .NET přes metadata. Jinak existuje také Swift pro .NET (lepší je ten pro Linux, ale kdyz není zbytí...).

[Reklama]

[zboj]

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é.

<pošťuchování>Sekretářka co sčítá čísla z buňek v Excelu na kalkulačce, protože jí nikdo neupozornil, že to Excel umí sám, taky nemá pocit, že něco dělá zbytečně dlouho Stejně tak C++ programátor co právě strávil dva dny hledáním ošklivé paměťové chyby v programu taky bude tvrdit, že je nesmysl, že v C++ se programuje pomalu </pošťuchování>

No a teď vážně:

V tom tvém výčtu dost postrádám vlastnost Javy, kterou osobně pokládám za killer feature: Anotace. Pokud vím, nic podobného C++ (a asi žádný jiný jazyk?) nemá a přitom je to naprosto geniální věc.

Pak jsou tu aspecty. Skvělá věc, i když, ve špatných rukou, řekl bych, až smrtelně nebezpečná

A reflexe. Člověk ji použije jednou / dvakrát za rok max (pokud víckrát, je prase), ale když, tak vytrhne trn z paty. Ta se v C++ dá do určité míry nahradit přes templaty, ale jen do určité míry. A naopak, co v Javě neumí generika se dá částečně obejít reflexí.

Naopak, s generiky žádný velký problém nemám (a za hack považuju spíš C++ generika, ale to je spíš filozofická otázka). Respektive jediný vážnější/nepříjemný problém, na který jsem za svoji praxi narazil je, že nejde napsat T.class.

Podobně vícenásobná dědičnost. Naprosto mi dostačuje možnost implementovat víc interfaces - ani se nepamatuji, kdy naposled mi to nestačilo. A přinejhorším se to dá obejít přes skládání.

Co mě naopak na Javě štve a uvedené není je neexistence výstupních proměnných.

V moderním C++ se paměťová chyba vyrábí dost těžko.

[Kit]

Co mě naopak na Javě štve a uvedené není je neexistence výstupních proměnných.

Výstupní proměnné považují za velké zlo, které mi v Javě vůbec nechybí a v PHP je nepoužívám. Na to je určen return. Také ti nic nebrání použít jako parametr metody objekt, který poslouží stejně dobře jako reference v C++. V tom případě by ta metoda měla být void.

Ostatně pokud máme k dispozici objekty, je dobré je používat.

[L.]

Výstupní proměnné považují za velké zlo, které mi v Javě vůbec nechybí a v PHP je nepoužívám. Na to je určen return. Také ti nic nebrání použít jako parametr metody objekt, který poslouží stejně dobře jako reference v C++.

V čem je to zlo? Třeba mám metodu a potřebuju z ní dostat třeba dva inty, počet a součet. Return, pokud jsi to ještě nezjistil, umí vrátit pouze jednu hodnotu / objekt. Takže buď na ně musím vytvořit extra třídu (opruz, naprosto zbytečné řádky v kódu a bajty v permgenu).

Nebo někteří experti nadefinují metodu s parametrem typu int[] a předpokládají, že to bude pole o dvou položkách. Strašná prasečina.

Udělat metodu

void zpracuj(int[] vstup, int &pocet, int &soucet);

by bylo naprosto nejelegantnější a nejjednodušší řešení, kdyby to šlo

[Ivan Nový]

Jinak trochu odbočení, budoucí programovací jazyky strojů budou docela zajímavé v tom, že například vystačí s jedním datovým typem - integer, případně float a nebudou používat znakové identifikátory proměnných.

To všechno už tu dávno bylo, jeden datový typ má zapomenutý BCPL, a zásobník (třeba ve Forthu) nepotřebuje žádný identifikátor. Jsi s tou budoucností pěkných pár desítek let pozadu

Ano samozřejmě, ale program nebude generovat člověk, ale stroj, to bude to nové. Programy se nebudou upravovat, stroj je vygeneruje znovu podle změněných parametrů, paramery určí rovněž stroj :-) Jinak to bylo zamyšlení nad tím, jaké jazyky budou k programování používat stroje místo lidí. Vzhledem k tomu, že zpočátku nebudou pracovat s mentálním modelem problému, ale k nalezení programu využívat nějakých evolučních algoritmů, nebudou potřebovat většinu vlastností programovacího jazyka, které využije člověk. Zřejmě dojde i k úpravě instrukčního souboru procesorů, nebo architektury , aby více podporoval evoluční algoritmy.

[Reklama]

[Inkvizitor]

Výstupní proměnné považují za velké zlo, které mi v Javě vůbec nechybí a v PHP je nepoužívám. Na to je určen return. Také ti nic nebrání použít jako parametr metody objekt, který poslouží stejně dobře jako reference v C++.

V čem je to zlo? Třeba mám metodu a potřebuju z ní dostat třeba dva inty, počet a součet. Return, pokud jsi to ještě nezjistil, umí vrátit pouze jednu hodnotu / objekt. Takže buď na ně musím vytvořit extra třídu (opruz, naprosto zbytečné řádky v kódu a bajty v permgenu).

Nebo někteří experti nadefinují metodu s parametrem typu int[] a předpokládají, že to bude pole o dvou položkách. Strašná prasečina.

Udělat metodu

void zpracuj(int[] vstup, int &pocet, int &soucet);

by bylo naprosto nejelegantnější a nejjednodušší řešení, kdyby to šlo

Zlo je v tom, že se obchází špatný návrh jazyka. Prostě tam chybí tuple a rozumný způsob jeho rozbalení při přiřazení výstupu z funkce. Tento mechanismus je známý už spoustu let a to, že to nikdo neuměl při návrhu Javy, není omluva. Co navrhuješ, není elegantní, je to jenom jednoduché - a při znalosti současného stavu vývoje programovacích jazyků - prostě hloupé. Bez urážky.

[Daniel Kozak]

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é.

<pošťuchování>Sekretářka co sčítá čísla z buňek v Excelu na kalkulačce, protože jí nikdo neupozornil, že to Excel umí sám, taky nemá pocit, že něco dělá zbytečně dlouho Stejně tak C++ programátor co právě strávil dva dny hledáním ošklivé paměťové chyby v programu taky bude tvrdit, že je nesmysl, že v C++ se programuje pomalu </pošťuchování>

No jenze mu nekdo tu Javu ukazal a ocekavam ze ji zna(umi scitat v Excelu).

No a teď vážně:

V tom tvém výčtu dost postrádám vlastnost Javy, kterou osobně pokládám za killer feature: Anotace. Pokud vím, nic podobného C++ (a asi žádný jiný jazyk?) nemá a přitom je to naprosto geniální věc.

Tak anotace ma pokud vim i C#, PHP (sice trochu zvlastne ale da se to nazvat anotacemi) i treba jazyk D

[Daniel Kozak]

Zlo je v tom, že se obchází špatný návrh jazyka. Prostě tam chybí tuple a rozumný způsob jeho rozbalení při přiřazení výstupu z funkce. Tento mechanismus je známý už spoustu let a to, že to nikdo neuměl při návrhu Javy, není omluva. Co navrhuješ, není elegantní, je to jenom jednoduché - a při znalosti současného stavu vývoje programovacích jazyků - prostě hloupé. Bez urážky.

Presne tak, tuple je jedine spravne reseni).

[Kit]

Výstupní proměnné považují za velké zlo, které mi v Javě vůbec nechybí a v PHP je nepoužívám. Na to je určen return. Také ti nic nebrání použít jako parametr metody objekt, který poslouží stejně dobře jako reference v C++.

V čem je to zlo? Třeba mám metodu a potřebuju z ní dostat třeba dva inty, počet a součet. Return, pokud jsi to ještě nezjistil, umí vrátit pouze jednu hodnotu / objekt. Takže buď na ně musím vytvořit extra třídu (opruz, naprosto zbytečné řádky v kódu a bajty v permgenu).

Obvykle se k tomu použijí dva gettery (i když je, jak známo, sám nepoužívám) nebo použiješ jeden messenger. Také můžeš požadovanou operaci udělat uvnitř objektu a žádné dvě hodnoty ven nebudeš muset vytahovat.

Nebo někteří experti nadefinují metodu s parametrem typu int[] a předpokládají, že to bude pole o dvou položkách. Strašná prasečina.

Pokud je výsledkem vektor [x, y], tak to prasečina být nemusí. Prasečinou je požadovat po jedné metodě výstup dvou nesouvisejících hodnot.

Udělat metodu
void zpracuj(int[] vstup, int &pocet, int &soucet);
by bylo naprosto nejelegantnější a nejjednodušší řešení, kdyby to šlo

Tak tohle je prasečina. Je to převzato z C/C++, kde to jinak nejde. Uvědom si, že to jsou procedurální jazyky, zatímco Java a C# jsou objektové. Jsou to různá paradigmata.

Velmi snadno to však můžeš udělat i v Javě. Stačí místo int použít Integer.

[zboj]

Výstupní proměnné považují za velké zlo, které mi v Javě vůbec nechybí a v PHP je nepoužívám. Na to je určen return. Také ti nic nebrání použít jako parametr metody objekt, který poslouží stejně dobře jako reference v C++.

V čem je to zlo? Třeba mám metodu a potřebuju z ní dostat třeba dva inty, počet a součet. Return, pokud jsi to ještě nezjistil, umí vrátit pouze jednu hodnotu / objekt. Takže buď na ně musím vytvořit extra třídu (opruz, naprosto zbytečné řádky v kódu a bajty v permgenu).

Nebo někteří experti nadefinují metodu s parametrem typu int[] a předpokládají, že to bude pole o dvou položkách. Strašná prasečina.

Udělat metodu

void zpracuj(int[] vstup, int &pocet, int &soucet);

by bylo naprosto nejelegantnější a nejjednodušší řešení, kdyby to šlo

Rozumné jazyky (včetně C++ od verze C++11) mají tuples.

[Ondřej Novák]

No a teď vážně:

V tom tvém výčtu dost postrádám vlastnost Javy, kterou osobně pokládám za killer feature: Anotace. Pokud vím, nic podobného C++ (a asi žádný jiný jazyk?) nemá a přitom je to naprosto geniální věc.

Pak jsou tu aspecty. Skvělá věc, i když, ve špatných rukou, řekl bych, až smrtelně nebezpečná

A reflexe. Člověk ji použije jednou / dvakrát za rok max (pokud víckrát, je prase), ale když, tak vytrhne trn z paty. Ta se v C++ dá do určité míry nahradit přes templaty, ale jen do určité míry. A naopak, co v Javě neumí generika se dá částečně obejít reflexí.

No já jsem takový trochu staromódní. Přijde mi cokoliv co v runtime saha dynamicky na definice tříd jako prasečina. Anotace tam patří, byť je to nástroj a asi se někdy hodí. Trochu mě vadí jejich dvojkolejnost. Jsou v tom jak "jakési atributy" - deprecated, override, atd, ty najdeme i v C++ ať už přímo v normě, nebo  v nějakých implementacích přes #pragma (dá se to řešit před #define), a pak jsou tam runtime, které mají povahu spíš třídní konstanty...?

V C++ jsem schopen přetrpět RTTI, které umožňuje zeptat se objektu, zda náhodou neumí ještě nějaké jiné rozhraní (osobně na to mám vlastní systém, který ale v defaultu pro moji lenost nakonec zpravidla sáhne po RTTI - dynamic_cast ).

Vím že reflexe jsou super třeba na serializaci. I tak se mi častokrát vyplatilo mít oddělený formát od vnitřní reprezentace, což samozřejmě vedlo k nutnosti implementovat si vlastní serializaci - měl jsem speciální tabulku zvanou SerializeTypeInfo - přiřazovalo se k třídám identifikátory a uměl z objektu vytvořit identifikátor + zavolat serializaci a z identifikátoru vytvořit objekt a deserializovat ho. Hlavní výhodou bylo, že jsem mohl mít vícero tabulek a vícero identifikátorů pro případ, že bych generoval vícero formátů, kde každý objekt se dle typu formátu identifikoval jinak.

Reflexi a anotace a cokoliv kolem .class beru trochu jako pornografii. Program odhaluje svůj vnitřek až moc a vede to pak na limitace budoucích změn. Asi jako že taky nepřistupujeme k proměnným přímo ale používáme getry a nikdo nepřemýšlí proč je to dobrý nápad.

[Ondřej Novák]

Rozumné jazyky (včetně C++ od verze C++11) mají tuples.

Já si zpravidla definuju třídu nebo strukturu (třídu public). Třeba jen kvůli názvům proměnných i z nějakého dokumentačního důvodu.

Jinak zrovna pro dva argumenty šlo použit

Kód: [Vybrat]

std::pair<int,int>
 make_pair(a,b)
pro tři se omezeně dalo použít

Kód: [Vybrat]

std::pair<std::pair<int, int>, int >
 make_pair(make_pair(a,b),c)


pro čtyři pak ještě

Kód: [Vybrat]

std::pair<std::pair<int, int>, std::pair<int, int>>
make_pair(make_pair(a,b),make_pair(c,d))

Ono se pak blbě zjišťuje, co je první, druhý, třetí argument, takže jaký je problém s?

Kód: [Vybrat]

struct vysledek {
 int soucet;
 int pocet;
};
vysledek zpracuj(int[] vstup);


vypadá to hned čitelněji, hlavně pak při zpracování výsledku

A ono to je lepší používat i pro vstupní proměnné, třeba taková funkce co má 20 argumentů, to je fakt šílenost. Je lepší to narvat do struktury a taky si je mohu pojmenovat a vím co je co.

Oproti Jave je vysledek stále jen v C++ lokální proměnná, není třeba ji alokovat pomoci new

[Rado2]

Zlo je v tom, že se obchází špatný návrh jazyka. Prostě tam chybí tuple a rozumný způsob jeho rozbalení při přiřazení výstupu z funkce. Tento mechanismus je známý už spoustu let a to, že to nikdo neuměl při návrhu Javy, není omluva. Co navrhuješ, není elegantní, je to jenom jednoduché - a při znalosti současného stavu vývoje programovacích jazyků - prostě hloupé. Bez urážky.

Presne tak, tuple je jedine spravne reseni).

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ý.

[L.]

Obvykle se k tomu použijí dva gettery (i když je, jak známo, sám nepoužívám) nebo použiješ jeden messenger. Také můžeš požadovanou operaci udělat uvnitř objektu a žádné dvě hodnoty ven nebudeš muset vytahovat.

Dva gettery mohu použít, pokud je to nějaká relativně jednoduchá operace. Ale často má člověk složitý processing, jehož výsledkem je víc hodnot a psát a volat ho x-krát by znamenalo duplikaci kódu i zbytečně strávený procesorový čas.

O messengeru jsem psal. Vede zbytečnému kódu navíc => méně přehledný program => prasárna.

Tuples by byly dobré, _pokud_ by v Javě měly rozumnou podporu na úrovni jazyka a nemuselo se to z nich tahat ručně. Ale psát program stylem "vím, že na nultém indexu je součet a na prvním počet" je ultra prasárna, to mi nikdo nevymluví.

Uvnitř objektu: To je použitelné opět jen v hodně malém množství příkladů.

Pokud je výsledkem vektor [x, y], tak to prasečina být nemusí. Prasečinou je požadovat po jedné metodě výstup dvou nesouvisejících hodnot.

Speciálně proto jsem psal ten příklad s výstupem "počet" a "součet", aby bylo jasné, že se mi nejedná o tenhle případ s vektorem. Ale počet a součet jsou související hodnoty. Viz výše - typicky to potřebuješ pokud máš nějaký netriviální processing a rozepisovat to do víc metod by bylo nevhodné.

Tak tohle je prasečina. Je to převzato z C/C++, kde to jinak nejde. Uvědom si, že to jsou procedurální jazyky, zatímco Java a C# jsou objektové. Jsou to různá paradigmata.

Velmi snadno to však můžeš udělat i v Javě. Stačí místo int použít Integer.

Takže žádný reálný argument (vyžaduje více kódu, je nepřehledné, vede k chybám, ...), jen kecy. Když tam místo int napíšu Integer, tak to sice bude "objektové" (takže OK?), ale nijak si nepomůžu, protože přiřazením do parametru se ta proměnná ve volající funkci nezmění.

[Kit]

Reflexi a anotace a cokoliv kolem .class beru trochu jako pornografii. Program odhaluje svůj vnitřek až moc a vede to pak na limitace budoucích změn. Asi jako že taky nepřistupujeme k proměnným přímo ale používáme getry a nikdo nepřemýšlí proč je to dobrý nápad.

Jako s alkoholem: V malých dávkách neškodí v jakémkoli množství. Pokud se však program skládá z propletených reflexí a anotací, ztrácí čitelnost. O to hůř se do něj zasahuje při modifikaci.

O tom, že gettery/settery jsou stejně špatný nápad, jako přímý přístup k proměnným, jsem už psal mnohokrát a není důvod to dále rozebírat.