Vyplatí se učit C++?

[zboj]

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

Stačí vzít std::tuple. Nebo tu strukturu kvůli pojmenování. Jinak třeba Swift umožňuje pojmenovat prvky tuplu.

[Reklama]

[noef]

Neumi anotace i nejaky novy JavaScript (prisahal bych, ze jsem to nekde cetl)? V anotacich nevidim problem, pokud jsou vhodne pouzity - napr. knihovnami - tak mohou byt velmi uzitecne. To stejne reflexe nebo generovani/upravovani bytekodu za behu - muze to velmi zprijemnit pouzivani knihovny.

Typ tuple se casto povazuje za prasecinu, zvlaste kdyz to vraci nejake API, je to jako mit nepojmenovane vystupni promenne. Ve Scale se to doporucuje resit pres case class - immutable trida, kterou lze pohodlne definovat na jednom radku. Nebylo neco takoveho planovane i pro Javu?

Nekdo tu psal, ze v C++ nepouziva nic low-level ani ASM. Ja ale nikde nepsal, ze se to bezne pouziva, pouze, ze pokud se to neuzije, tak moc velke (zedne?) vyhody oproti Jave/C# nebudou. Pametova narocnost bude urcite vyssi, ale jak je videt, tak se vyplati.

K nevyhodam Javy - lepsi generika (ne na urovni C#, ale rozhodne pouzitelnejsi, lze napr. instancovat gen. typ), vicenasobnou dedicnost (traity) i vlastni operatory Scala podporuje (z dalsich vlastnosti umi napr. makra pro prekladac, patern matching nebo implicitni parametry). Jak jsem zminil vyse, nekdy je oznacovana jako nastupce Javy, ikdyz tomu moc neverim. Ale rozhodne je hezke videt, jak Scala a dalsi jazyky tlaci vyvoj Javy kupredu .

[L.]

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

Aha, takže vůbec netušíš, k čemu se anotace dají použít. No, to se pak nedivím, že ti přijde Java vlastně jako C++

Tak z hlavy různá šikovná využití:

- specifikace ORM na objektu (co ne, co ano, do jakého sloupečku, jak, vazby mezi entitami, ...)

- deklarativní validace na objektu

- deklarativní mapování controllerů, metod, parametrů, ... v MVC (Spring)

- (spolu aspecty) deklarativní security, deklarativní transakce, ...

- atd.

Výhoda je, že anotacemi se toho moc sprasit nedá, teda asi by se dalo, ale člověk by se musel moc snažit. Všechna použití co jsem zatím potkal byla spíš ku prospěchu věci.

[petron]

kam sa zas zvrtla ta diskusia???

[Ondřej Novák]

kam sa zas zvrtla ta diskusia???

Tím bych to uzavřel

[Reklama]

[v]

kam sa zas zvrtla ta diskusia???

tak jak vždycky už jste se podíval na ten F# ?

[Kit]

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.

Jenže uvedená ukázka je typická pro procedurální programování. Když budeš psát objektově, tak takovou funkci ani nebudeš potřebovat. K čemu potřebuješ současně součet i počet? Z objektu mi obvykle stačí jen jedna hodnota. Výsledek.

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

Protože nepracuješ s objektem, ale s polem. Když budeš psát objektově, ...

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

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

Nepoužívám to a chování jsem odhadl. Teď jsem si na to napsal test, který mi dokázal, že to tak nefunguje. V tomhle máš tedy pravdu. Stále je tu však možnost napsat si messenger nebo to napsat pořádně a místo pole udělat standardní objekt.

Stále se motáme kolem toho, že procedurální kód se v Javě píše docela blbě. Zcela určitě to byl záměr.

[yep@email.cz]

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

Neco takoveho jsem chtel napsat. Take pouzivam C++ defakto jako Javu. Ti C++ hejtri videli C++ jen z rychliku nekdy pred 20 lety.

[yep]

Jinak co se tyce te reflexe a anotaci, tak pokud to nekdo opravdu potrebuje si muze udelat vlastni preprocesor a vygenerovat dodatecne zdrojaky.
Pro anotace by to pak chtelo i nejaky support v IDEcku, aby to moc nebylo do oka. Ono hodne lidi si mysli, ze tyhle preprocesory je spatny napad, ze uz to neni C++, ale podle me to je naopak chytrost programatora.

[petron]

co si myslite o tych knizkach co som postol?

[Daniel Kozak]

Stačí vzít std::tuple. Nebo tu strukturu kvůli pojmenování. Jinak třeba Swift umožňuje pojmenovat prvky tuplu.

Jj pojmenovani tuple si swift propujcil z jazyka D. Celkem pekny jazyk ten swift, zda se ze okopirovali jen to nejlepsi z vetsiny jazyku (mysleno pozitivne).

[zboj]

Stačí vzít std::tuple. Nebo tu strukturu kvůli pojmenování. Jinak třeba Swift umožňuje pojmenovat prvky tuplu.

Jj pojmenovani tuple si swift propujcil z jazyka D. Celkem pekny jazyk ten swift, zda se ze okopirovali jen to nejlepsi z vetsiny jazyku (mysleno pozitivne).

Přesně tak, a autoři se tím ani nijak netají. Žádný jiný jazyk nenabízí to, co Swift, na jednom místě. Navíc se překládá do LLVM IR a má pekelně rychlou standardní knihovnu. Hodně se inspiroval jazykem Go od Google.

[noef]

... zda se ze okopirovali jen to nejlepsi z vetsiny jazyku (mysleno pozitivne).

Bez kopirovani by snad nebyl pokrok, mely bychom jen hodne sisatych kol, ale zadna auta . Nektere firmy v tom vynikaji - treba Blizzard, proste vyberou dobre vlastnosti stavajicich her, krasne to nalesti a uspech je na svete (take to neminim negativne).

[petron]

dakujem za "konstruktivnu" debatu, ktora zas ako vzdy viedla k niecomu uplne inemu, ako to byva na roote. Vacsinou prispevky k nicomu. Su tu ale aj prispevky, ktore sa naozaj tykaju temy, co som rad a dakujem za rady.

[v]

co si myslite o tych knizkach co som postol?

nepůsobí na mě dojmem, že by vám mohly otevřít úplně nové obzory