Je C++ dobrá volba na větší projekt?

[Ivan]

C++ vyzaduje hodne discipliny a je narocny dodrzet stejnou metodologii v celym tymu. Vsechen komercni sw v C++ kterej jsem videl, byl prasacky Ccko se tridama - s opravdovym C++ to nemelo nic spolecnyho. Asi to bylo tim, ze ten kod byl hodne starej, ze dneska moc novych projektu nevznika.

Navic samotny C++ zadnou rychlost negarantuje. Staci jedno nechteny predavani promenne hodnotou (misto reference) a cely kod muze byt pomalejsi nez v Jave. Pred rokem jsem neco fixoval v generatoru parseru ANTLR (neco jako bison). Predhodi se tomu gramatika jazyka a ono to vygeneruje zdrojaky parseru v Jave, C++, Pythonu, ... Zajimavy bylo, ze parser v Java byl cca 2x rychlejsi nez ten v C++. Pritom vygenerovany zdrojaky byly na prvni pohled naprosto identicky. Stejny tridy, metody, podminky, switche. Trvalo mi to dost dlouho nez jsem to srovnal a ted je C++ target 2x rychlejsi nez Java. Problem byl v memory managementu, od verze 1.7 umi Java opravdu rychle alokovat a uvolnovat objekty ktere ziji jen kratce. Samozrejme, ze C++ RAII je jeste rychlejsi, ale musi se to spravne pouzit. Dalsi problem byl v poradi vyhodnocovani jedne podminky - misto "if ( a() = true && b() = true)" to bylo obracene a "b()" bylo velice narocne na vyhodnoceni.

Takze pokud te bavi programovani a ches mit vsechno pod kontrolou, tak pouzij C++. Pokud chces nadelat velky prachy tak pouzij Javu.

[Reklama]

[Jann]

V jedné staré knize o softwarovém inženýrství byl jako jeden z podstatných kroků při úvahách o novém projektu uveden bod nazvaný „volba vhodného programovacího jazyka”. Lidem ještě v těch dobách bylo jasné, že každý jazyk se hodí na trochu něco jiného.

A za mě – od té doby, co vymysleli Javu, je C++ úplně k ničemu a u nových projektů bych ho v žádném případě nezvažoval. V dnešní době má cenu zvažovat C u low-level projektů, má cenu zvažovat Fortran pro náročné výpočty, ale C++ bych se raději vyhnul, protože nepřináší nic, co by nenabízely i jiné jazyky mnohem pohodlnější formou. C++ je něco jako MS–DOS – tedy takový evoluční omyl, beznadějně zastaralý a překonaný už v době svého vzniku, který znepříjemňoval lidem život ještě dalších 15 let.

[backup]

V jedné staré knize o softwarovém inženýrství byl jako jeden z podstatných kroků při úvahách o novém projektu uveden bod nazvaný „volba vhodného programovacího jazyka”. Lidem ještě v těch dobách bylo jasné, že každý jazyk se hodí na trochu něco jiného.

Bjarne Stroustrup odpovida na otazku, zda delat projekty v C++: mas li projektovy tym lidi, kteri ovladaji Cobol, delej ten projekt v Cobolu

ale C++ bych se raději vyhnul, protože nepřináší nic, co by nenabízely i jiné jazyky mnohem pohodlnější formou...

napr. v GUI oblasti existuji frameworky, ktere jsou napsany v C++ a zde je pak skutecne tezke, se rozhodnout proti C++. Pak uz zbyva jen implementace takoveho frameworku (toolkitu) do nejakeho interpretru, coz je spojeno vzdy s mensimi i vetsimi problemy.

A kdyz uz jste vzpomenul ty stare casy, tak Kernighan vzdy rikal, ze C nebyla vyvinuta, aby se v ni delaly velke projekty, nybrz na tvorbu domenovych nastroju, kterymi se ty velke projekty pak delaji.

[J. Ghibulo]

A proč neudělat kritický části v C/C++ a celý to pak slepit třeba Pythonem? V čem by bylo tohle řešení obecně méně výhodné, než Java? Java mi přijde nejvýhodnější jenom na serveru.

[mc]

Což je užitečné pouze v případě, kdy je životnost zdroje vázána na scope.

Ve kterém případě není životnost zdroje vázána na některý scope?

Často je vázána na nějakou událost. Například soubor / databázi můžete chtít zavřít, když všichni (nebo někteří) klienti uzavřou spojení. Nebo píšete asynchronní výpočet pomocí callbacků. Pokud netrváte přímo na zdrojích, tak dalším příkladem jsou různé dokazovače, které odvozují formule v logice - když například odvodíte, že musí platit formule (A nebo B), a poté odvodíte, že musí platit A, tak formuli (A nebo B) můžete odstranit - tj. životnost (A nebo B) končí v okamžiku, kdy jste odvodil A.

Kdyz klient uzavre spojeni, tak se zdestruuje, a protoze drzi shared pointer na databazi, tak s poslednim klientem se zavre i databaze, ze

[Reklama]

[Mirek Prýmek]

A proč neudělat kritický části v C/C++ a celý to pak slepit třeba Pythonem? V čem by bylo tohle řešení obecně méně výhodné, než Java?

V tom, ze Python ma GIL a zjevne se s tim nic moc delat nebude. Coz je v 21. stoleti ponekud trapne

[Radek Miček]

Což je užitečné pouze v případě, kdy je životnost zdroje vázána na scope.

Ve kterém případě není životnost zdroje vázána na některý scope?

Často je vázána na nějakou událost. Například soubor / databázi můžete chtít zavřít, když všichni (nebo někteří) klienti uzavřou spojení. Nebo píšete asynchronní výpočet pomocí callbacků. Pokud netrváte přímo na zdrojích, tak dalším příkladem jsou různé dokazovače, které odvozují formule v logice - když například odvodíte, že musí platit formule (A nebo B), a poté odvodíte, že musí platit A, tak formuli (A nebo B) můžete odstranit - tj. životnost (A nebo B) končí v okamžiku, kdy jste odvodil A.

Kdyz klient uzavre spojeni, tak se zdestruuje, a protoze drzi shared pointer na databazi, tak s poslednim klientem se zavre i databaze, ze

Ano, ale to už životnost zdroje není vázána na obor platnosti nějaké proměnné. Navíc to funguje dobře pouze pro jednoduché situace - např. můžeme přidat pravidlo, že zdroj se má uvolnit, po odpojení posledního klienta, pokud se po dobu 30 sekund nikdo nepřipojí.

Kromě toho shared_ptr, tj. naivní počítání referencí, je z hlediska výkonu často mnohem horší než třeba Mark & Sweep (například, když k tomu zdroji budete velmi často přistupovat). Navíc si musíte hlídat cykly.

[Daniel Kozak]

Nemám zrovna velkou zkušenost s C++ co se týče nějakých větších projektů (jazyk jako takový ovládám myslím celkem solidně).
Pokaždé když jsem ale něco většího dělal, tak jsem poměrně dost částu trávil tím, že jsem přemýšlel, jestli mám vracet hodnotou nebo ukazatel, kdo pak uvolní pameť atd.. V podstatě to vždycky vede na použití shared pointrů, které čítají reference a objekt uvolní, když už na něj žádná reference neexistuje. Nevýhodou shared pointrů je, že se pro to čítání referencí používají atomické instrukce (compare and swap) a ty jsou přece jenom o něco ménně efektivní.
No co tím chcí říct, jestli má cenu vůbec používat C++, pokud tedy nejde o projekt, který opravdu vysloveně potřebuje ze železa vyždímat úplné maximum.
Dlé mého názoru je daleko lepší použití Javy, protože JVM se posouvá dál a dál a čím dál tím víc se výkonnost blíží jazykům, které se překládají přímo do nativních instrukcí procesoru. Samozřejmě ať každý používá co umí a v čem se mu dělá lépa, ale objektivně kdy má cenu volit C++?

C++ ma cenu v pripade ze potrebujes pouzivat nejake dalsi subsystemy ci knihovny ktere maji jen c++ rozhrani. Jinak pokud je potreba vykon tak je idealni pouzit jazyk D. Ten je idealni kombinaci jak javy (GC, velmi podobny OOP model) tak C++ (vykon).

[JSH]

Kromě toho shared_ptr, tj. naivní počítání referencí, je z hlediska výkonu často mnohem horší než třeba Mark & Sweep (například, když k tomu zdroji budete velmi často přistupovat). Navíc si musíte hlídat cykly.

Přístupy nevadí. Vadí kopírování toho smart pointeru, což je spíš předávání vlastnictví toho zdroje. Zamyslet se nad vlastnictvím objektů je v C++ dost kritické.

V tom odkazovaném testu vidím zádadní zádrhele. Hned v prvních komentářích mu tam vytýkají že je to strukturované nějak divně a autor přiznává že vyšel z automaticky generovaného kódu. Pokud se kód navrhne stejně jako v jazycích s GC, kde je předávání silných ukazatelů prakticky zadarmo, tak to samozřejmě dopadne špatně.

Jo, chytré ukazatele mají svoje zádrhele, ale tenhle test bych zobecňoval hodně opatrně.

[J. Ghibulo]

V tom, ze Python ma GIL a zjevne se s tim nic moc delat nebude. Coz je v 21. stoleti ponekud trapne
[/quote]
Trapný to je, ale když to člověk vezme pragmaticky -
- python jako glue (formuláříky, okýnka, odstartovávání nativních rutin...) - k tomu přeci není třeba usilovat o využití všech jader na plný plyn
- na spuštěnou C++ nativní rutinu si už žádný GIL nepřijde

... takže ve výsledku  můžu mít aplikaci, kdy do pythonovskýho formuláříku klepu vstupní data a na pozadí mi X céčkových subrutin roztáčí větrák na plný plyn, nebo mi něco uniká?

[Mirek Prýmek]

Trapný to je, ale když to člověk vezme pragmaticky -
- python jako glue (formuláříky, okýnka, odstartovávání nativních rutin...) - k tomu přeci není třeba usilovat o využití všech jader na plný plyn

Prave naopak - v GUI aplikacich dobry multithreading vyuzijes paradne, protoze kdyz na neco kliknes a ono se tam neco prepocitava, tak nechces, aby ti GUI zamrzlo. U by-design unithreadovych jazyku to pak musis ruzne obchazet, coz je zbytecna namaha. Z hlediska programatora to muze byt neviditelne schovany nekde v hloubce nejakych knihoven, ale opruz to je a dusledky to ma i tak, i kdyby jenom v tom, ze je vyvoj knihoven pomalejsi a nekompatibilni zmeny API castejsi.

- na spuštěnou C++ nativní rutinu si už žádný GIL nepřijde

Pokud se GIL spravne releasuje, tak ne, ale zase: musi se na to myslet, je to uplne zbytecnej opruz.

Treba ted je desne cool pouzivat Python pro zpracovani dat (pandas atd.) a kazdou chvilku nekdo prijde s tim, ze nejakou CAST nejakeho vypoctu udelal s releasnutym GILem a vypocet se zrychlil o stovky procent. No to je parada, ale dela se to ad hoc, misto aby se to nemuselo resit vubec, nebo aspon nejak inteligentnejc.

... takže ve výsledku  můžu mít aplikaci, kdy do pythonovskýho formuláříku klepu vstupní data a na pozadí mi X céčkových subrutin roztáčí větrák na plný plyn, nebo mi něco uniká?

Ano, pokud na to myslis, patricne knihovny to podporuji a jsou prelozene s patricnymi optionami, udelal jsi kolem serveru kridou pentagram a obetoval panenskeho holuba

[Radek Miček]

Kromě toho shared_ptr, tj. naivní počítání referencí, je z hlediska výkonu často mnohem horší než třeba Mark & Sweep (například, když k tomu zdroji budete velmi často přistupovat). Navíc si musíte hlídat cykly.

Přístupy nevadí. Vadí kopírování toho smart pointeru

To je pravda.

V tom odkazovaném testu vidím zádadní zádrhele. Hned v prvních komentářích mu tam vytýkají že je to strukturované nějak divně a autor přiznává že vyšel z automaticky generovaného kódu.

Na druhou stranu to v těch komentářích zkoušelo několik lidí vylepšit a výsledný kód byl stále 4x pomalejší než v OCamlu.

Já nepochybuji, že v C++ napíšete minimálně stejně rychlý kód jako v C# nebo v Javě - koneckonců VM těchto jazyků také bývají implementována v C++ - otázkou spíše je, jaké úsilí pro to musíte vyvinout. Například psát asynchronní kód ve standardním C++ je IMO dnes těžší než v C# (jak například uvolnit paměť, když asynchronní výpočet nikdy nedoběhne - v C# tohle řešíte pouze pro zdroje, ostatní paměť uvolní GC), podobně napsat soft real-time systém v C++ nemusí být vůbec jednoduché a GC v Erlangu, Go nebo některých implementacích Javy to může usnadnit. Stejně tak, jaké jsou například garance, že se v C++ vykoná destruktor (například když není pro jeho vykonání dost místa na zásobníku)? V C# můžete finalizaci garantovat pomocí CriticalFinalizerObject.

[JSH]

Na druhou stranu to v těch komentářích zkoušelo několik lidí vylepšit a výsledný kód byl stále 4x pomalejší než v OCamlu.

Tak to holt dopadá, když je blbě už návrh. Linked list pomocí smart pointrů je fakt blbý nápad, ale aby se ho zbavili, tak by to museli komplet přepsat.

jak například uvolnit paměť, když asynchronní výpočet nikdy nedoběhne - v C# tohle řešíte pouze pro zdroje, ostatní paměť uvolní GC

Tohle je přesně důvod, proč nemám rád GC. Paměť je jen jeden ze zdrojů. GC tak řeší jen jeden aspekt úklidu a všechno ostatní mi zůstane na krku. Smart pointery řeší všechno úplně stejně jako paměť. Akorát jsou tam samozřejmě jiné mouchy.
Nevím, jak dobře se pracuje s asynchronním kódem v C#, ale s ASIO je to v C++ celkem pohoda. I bez lambda funkcí se ke callbackům dá všechno potřebné přibalit pomocí std::bind. Úklid pak řeší destruktor toho callbacku.

Jinak fakt nechci zabíhat do diskuzí o tom, který jazyk je rychlejší. Vím jak to dopadá. Chtěl jsem jen upozornit na to, že ten benchmark neměřil pomalost C++ ale špatně použitých smart pointerů a datové struktury která se do C++ moc nehodí.

[J. Ghibulo]

Prave naopak - v GUI aplikacich dobry multithreading vyuzijes paradne, protoze kdyz na neco kliknes a ono se tam neco prepocitava, tak nechces, aby ti GUI zamrzlo. U by-design unithreadovych jazyku to pak musis ruzne obchazet, coz je zbytecna namaha....

Souhlasím, že v GUI aplikacích to využiju parádně, moje vyjádřená pochybnost (Python jako lepidlo) se však týkala jen grafické vrstvy GUI aplikace. Proto nekliknu a nepřepočítává... po kliknutí se spustí nativní aplikace, jejíž procesorový čas řídí OS a ne Python. Zatímco já si povídám skrz guiksicht s Pythonem, nativní aplikace vyřeší multiprocesorově problém a výsledek přichystá Pythonu na podnose, kde si ho příležitostně vyzvedne a použije v komunikaci se mnou.

Pokud se GIL spravne releasuje, tak ne, ale zase: musi se na to myslet, je to uplne zbytecnej opruz.

Buď si nerozumíme, nebo to blbě chápu... domnívám se, že té nativní aplikaci je GIL úplně ukradený, protože ta si hraje na svém písečku - jako bych třeba z Pythonu pustil wget na nějakej pornoserver :-)

[Radek Miček]

Smart pointery řeší všechno úplně stejně jako paměť. Akorát jsou tam samozřejmě jiné mouchy.

Ano, třeba zvýšené nároky na paměť, pokles výkonu, záseky programu při uvolňování, občasné úniky paměti a zdrojů (při cyklech).

Tohle je přesně důvod, proč nemám rád GC. Paměť je jen jeden ze zdrojů.

GC uvolní i jiné zdroje - nebude to však okamžitě, což může být problém. Naopak, když se smart pointery uděláte cyklus, tak se zdroj nemusí uvolnit nikdy, což je ještě horší.

Linked list pomocí smart pointrů je fakt blbý nápad

Takže doporučujete ruční správu paměti?

Chtěl jsem jen upozornit na to, že ten benchmark neměřil pomalost C++ ale špatně použitých smart pointerů a datové struktury která se do C++ moc nehodí.

Cílem nebylo měřit rychlost nějaké implementace C++, ale rychlost naivního počítání referencí.