Je C++ použitelný i pro malé projekty?

4.1.2016 02:24 | Přečteno: 2783× | Programování | poslední úprava: 4.1.2016 02:24

Zamyšlení/úvaha nad rozmanitostí C++, jednoduchostí a čitelností kódu, novými verzemi C++, lidskými vlastnostmi a zkušenostmi, ... a vůbec o tom, jak je těžké se dohodnout na tom, který kus dortu je dobré jíst a co je lepší nechat na stole.

Jednodušše složité začátky

Programování je jako umění - začínáme pár čmouhami na papíře a končíme u různých stylů - někdo směřuje k fotorealismu, jiný kreslí komixy, jiná zase přidává čmouhy a nazve to "abstraktním uměním", ... no a pak je tu Picasso. Stejně tak někdo má raději vysoce přehledný, co nejjednodušší kód (Python), někdo jiný se zase vyžívá v abstrakci (Java), někomu je to jedno (hlavně, když to jede rychle), někdo má speciální úchylky (raději bez příkladu ), apod.
Tím se snažím naznačit, že - bohužel či bohudík - jsou mezi námi programovací jazyky, kde je vše dovoleno a je pouze na vůli programátora, které prvky použije. Jazyky, kde jeden program může vypadat jako obraz od Moneta a druhý jako kubistická kompozice od Picassa, oba 100% v mezích stejného jazyka. Jazyky jako C++.

Já osobně vždy spadal do zastánců KISS principu - malé krátké jednoduché programy (či funkce), tedy Bash, Python, místy Perl, C, a vyhýbal se jazykům jako C++ či (hlavně) Java. I já si prošel akademickým egoismem a snažil se svůj názor vnutit ostatním, ale pak jsem zmoudřel a uznal, že i těch 9 úrovní abstrakce namespaců a templaty templatů (nenáviďte mě ), používaných v některých větších C++ projektech, má svůj smysl. A taky jsem se pořádně začetl do C standardu a zjistil, že neznám všechny případy nedefinovaného chování, začal pochybovat o tom, že někdy budu umět C, a k C++ se prakticky nevrátil - ne proto, že by to byl jazyk složitý na použití, ale protože je to kuchařka ve stylu "vytvoř si svůj jazyk" a bez výběru konkrétního receptu může snadno vzniknout nechutná splácanina.

Minimalismus či svět možností?

Takový Python má jako součást PEP20 (PEP = Python Enhancement Proposal) i následující prohlášení:

There should be one-- and preferably only one --obvious way to do it.

Přičemž zároveň existuje proslavený PEP8, "Style Guide for Python Code", poskytujíc doporučené (nikoli však vynucené) zásady psaní kódu. Oboje samozřejmě může být na škodu (dle individuálních názorů) - např. neexistence switch statementu v Pythonu, "protože můžete přece použít if-else". Také lze tvrdit, že tvůrci jazyka by se neměli "míchat" do jeho používání a že centrální autorita na to, co je syntakticky a sémanticky dobré/špatné, je na škodu. Obecně je ale daleko jednodušší mít jen jeden způsob "jak to dělat", protože ten může být objektivně správný - bez dohadů o tom, zda způsob A je umělecky lepší, než způsob B. Jenomže existují situace, kdy použití A je tak nechutně ohavné, že se všichni rozhodnou pro B, .. ale když ono B v tomto jazyce neexistuje.

Volně tím narážím na rčení typu "použít nejvhodnější nástroj pro daný úkol" a jak naopak složitý a rozmanitý jazyk, kde lze jednu věc vyjádřit více způsoby, může být neuvěřitelně osvobozující. Pěkně to znázorňuje jistý xkcd.com komiks - méně není vždy lépe a nazývat věci pravými přesnými jmény není daleko od přehledné specifikace datových typů v hashmapě á la C++ (unordered_map <string,int>), v porovnání s jednoduššími, univerzálnějšími, avšak méně přehlednými void pointery á la C.
Protiargumentem budiž ona přehlednost a determinismus - v C je velmi snadné určit, co i++ dělá, v C++ to může být přetíženo na system("rm -rf /*") - nemůžeme tak samotnému jazyku věřit "nos mezi očima" - musíme spoléhat na to, že ho nikdo neuřízl nebo že ho nahradil něčím, co se chová jako nos. Jak jen to je .. "s velkou silou přichází velká zodpovědnost"? Proč mi to jen připomíná komplexní složitý vim v porovnání s jednoduchým a jednoúčelným nano?

V rámci rozuzlení se asi můžeme shodnout, že KISS do extrému není nejlepší řešení - jistá míra komplexity a redundance přidává pomyslné nástroje do virtuální brašny, ale možná přehršel nástrojů s nástroji, které opravují další nástroje (auto jako lék na dlouhé typy iterátorů?) už je příliš a do brašny se nevleze. Jenomže co když má jazyk přehršel nástrojů, jeden se pokazí a vy nemáte ve své brašně ten správný fixion? Je řešením koupit si větší brašnu, omezit množství nástrojů v projektu, nebo zvolit jiný jazyk?

Každý to rád jinak

Podobné problémy jsme tady měli vždy i v C - psát závorky u return? sizeof? Co mezeru za jménem funkce? Před operátorem? Limit 80 znaků / řádek? Jak zalamovat { }? Typedef pro struct nebo ne? ... Nicméně tyto se jeví naprosto banálně v porovnání s některými vlastnostmi C++ a zda je použít či ne - např. zmíněné auto - existuje milión a jeden názor, od použití všude (a přidání decltype(auto) jako návrat z každé funkce / C++14), až po kompletní zákaz. "Pravda" asi bude někde uprostřed, .. ale kde? Opravdu - jako např. skalní zastánce explicitního typování - odmítnete patch, který implementuje 90% funkcionality pomocí generických auto funkcí, mumlajíc něco o skrývání bugů při změně datového typu a špatné debuggovatelnosti? Co napsat do směrnic stylu kódu ("style guide")? Podobně třeba s iterací, budete akceptovat pouze for (int &i : v) a tvrdě odmítat "staré" ::iteratory? Nebo obráceně? Co třeba chytré pointery? Budete vynucovat make_unique namísto new? Nebo naopak "staré" *pointery? Od jakého bodu je ten kód příliš odlišný od vaší představy? Od jakého bodu je "prasácký"?

Zde přesně leží můj problém a podstata tohoto zápisku - nemám problém přispívat do cizích projektů (přizpůsobím se stylu daného projektu), ale mám strach vést svoje projekty jako maintainer, obzvláště menší projekty, kde se cení pomoc každého dobrovolníka. Protože dříve nebo později se najde nějaký Franta, který rozdělí velké číslo apostrofy, a já nebudu mít dobrou výmluvu, proč tomu říkám "prasárna", protože nebudu mít žádné směrnice stylu kódu, protože pro ~10 kLOC projekt se mi nevyplatí je sepisovat. Chybí mi PEP8 pro C++.

Je více způsobů, jak z toho ven, ale žádný není ideální. Limitace na C++03 by mi zabránila použít C++11 způsob iterace (který mi osobně přijde daleko přehlednější), nehledě na spoustu dalších užitečných věcí. Taky k tomu lze přistupovat jako v C, kde se podobné věci vyskytly s příchodem C99 (a C11), např. for (int i = 0; i < x; i++) a já je víceméně ignoroval - v porovnání jsou ale nové vlastnosti i staré možnosti C++ výrazně dalekosáhlejší.
Velkými problémy paradoxně zůstanou i staré věci - patche nahrazující i++ za ++i (kde i je int) "protože je to rychlejší", správné použití size_t namísto int pro iteraci cyklem a podobné věci, kde není "dobré" a "špatné" řešení, pouze zvyk a moje odpověď "ono se vždy psalo i++" stojící za houby. Velmi podobně i to, na co narážel Linus - C++ je prvním jazykem spousty programátorů, kteří tak "sežrali všechen rozum" a nedají si vymluvit, že zpětné lomítko v #include není dobrý nápad, přestože C++11 jej definuje "with implementation-defined semantics" namísto "the behavior is undefined" (C++03) a v MSVS jim to přece funguje.

Summa summarum, po dlouhých rozvahách a mnohahodinovém přemýšlení o tom, kolik "šedých oblastí" by C++ přineslo, se rozhodnu pro C a spolknu těch pár řádků vlastní implementace linked listu. Nebo skočím do Pythonu a zapláču nad výkonem. Před pár dny se to opakovalo asi po čtvrté a já si řekl, že přece musí existovat cesta ven z tohoto začarovaného kruhu - tak prosím poraďte. Jak použít C++ v malém projektu více lidí a neztratit při tom nervy? Mám 100 chutí udělat směrnici ve stylu "C + těchto pár C++ vlastností", ale s tou by mě všichni poslali do temných míst.

Díky.

       

Komentáře

[kapr]

patche nahrazující i++ za ++i (kde i je int) "protože je to rychlejší"

To někdo dělá? Čekal bych, že tohle zrovna může krásně ošetřit kompilátor bez zásahu programátora a takový patch bych ignoroval. Stejně jako patche odporující stanovenému stylu, snad mám jako maintainer nějaké koule, ne?

[Michal Kubeček]

Především není absolutně žádný důvod, proč by jedno mělo být rychlejší než druhé. Buď se hodnota nepoužije a je to z definice totéž, nebo se použije a každé znamená něco jiného.

[Sten]

Prefixový je rychlejší pro objekty, kde ten operátor není inline, protože u postfixového se vytváří kopie, která se pak zahodí. U inline operátorů (což jsou mj. všechny primitivních typů) tu kopii kompilátor eliduje a tak tam rozdíl není.

Ale místo nahrazování postfixového zápisu prefixovým bych zavedl jednoduché pravidlo: všechny operátory musí být inline. Ať si to pořeší kompilátor sám.

[Kvakor]

Taky si myslím, že u dnešních překladačů je to hloupost, mimo toho je možné, že takový patch může nadělat výc škody než užitku, protože v kódu mohou být konstrukce, ve kterých se předpokládá, že se prvně použije původní hodnota jako index do pole/ukazatel a teprve pak se proměnná inkrementuje a pokud by to bylo provedeno naopak, tak se vrátí nesprávná hodnota, respektive hodnotya o jednu pozici dál. Osobně jsem častokrát podobné konstrukce použil v případech, kdy se prochází nějaké pole nebo řetězec po nestejnoměrných krocích (takže nejde použít cyklus) a kdyby tam někdo přepsal všechny index++ za ++index, tak se zaprvé přeskočí první položka či znak, zadruhé se v posledním kroku sáhne za hranici řetězce/pole, což by minimálně u řetězce mohlo mít kastastrofické následky (protože se přeskočí ukončovací '\0').

PS: Podobný názor jsem viděl kdysi u konstrkuce do {...} while(x) versus while(x) {...}, kdy se dotyčným ten první nelíbil (nejspíš kvůli osaměléímu while na konci) a navrhovali jeho zavržení

[dfsdf]

btw mensia poznamka, ak sa jedna o jednoduche typy(int, long...) tak je posfixova verzia rychlejsia, ale zas tam kde sa to da sa to zoptimalizuje.

[Jiří J.]

Ano, dělá. Je to samozřejmě blbost (pokud se to nepoužije jako rvalue), protože ve většině asm jazyků (které znám) je nějaká obdoba "inc" (a příslušná instrukce), takže i neoptimalizující překladač oboje přeloží stejně (pro int). Může to mít smysl pro netriviální datové typy (iterátor v C++), ale právě tohle použití "infikuje" () mozkové buňky některých jedinců, kteří pak ++i používají všude nehledě na datový typ a hádají se za to.

[jarin]

Problém je pokud jseš na platformě s nevyvíjeným historickým kompilátorem, který to neoptimalizuje. Pak ti nezbyde nic jiného než podobné mikrooptimalizace dělat a skousnout to, že je to kravina a nemá to cenu v roce 2016 řešit. Navíc ono je to nakonec celkem jedno jestli napíšeš to či ono.

[Sten]

AFAIK jsou všechny přetížené operátory v STL inline, takže i u iterátorů tu kopii kompilátor eliminuje.

[Jendа]

Taky můžeš použít nějakou knihovnu, třeba libucw, která obsahuje těch pár funkcí a maker, bez kterých se vůbec nedá programovat, a u kterých nechápu, že už dávno nejsou v C standardně.

[gsnak]

To vypada pekne, ja som trochu viac zacal pouzivat glib

[pavlix]

Na některé věci je glib zajímavý, ale i ty nejzákladnější datové struktury tam jsou tak nějak zpackané, hlavně interface ke spojákům je úplně špatně.

[pavlix]

Asi by bylo bývalo fér rovnou napsat v čem. Vývojáři, kteří programují s pomocí glib si notoricky pletou pole a spojový seznam. Například pro seznam prvků pevné velikosti vytvoří spojový seznam (samozřejmě speciální jednosměrný, aby ušetřili pointer na prvek) a následně k němu přistupují výhradně pomocí indexování. A není to jen chyba programátora, to rozhraní není navržené kolem akcí, pro které je daná datová struktura výhodná.

[kralyk z abclinuxu]

Taky můžeš použít nějakou knihovnu, třeba libucw, která obsahuje těch pár funkcí a maker, bez kterých se vůbec nedá programovat, a u kterých nechápu, že už dávno nejsou v C standardně.

Je to asi fajn knihovna, ale v téhle podobě by do C standardu IMHO nemohla. Jednak je zjevně orientovaná na UNIX a jednak mi to přijde jako taková všehochuť, co se zrovna hodilo. Algoritmy a datový struktury - super, to by klidně v stdlib mohlo být. Hashing imho patří spíše do crypto knihovny. A build systém a generování dokumentace bych tam vůbec nemusel, na to imho už existují dobré nástroje...

[Josef Kufner]

Ono třeba unistd.h je taky docela unixově orientovaná záležitost. Ale zrovna na C je příjemná ta jednoduchost a standardní knohovnu bych moc nenafukoval. V dnešní době je místo pro C hlavně v embeded aplikacích bez operačního systému, kde velká standardní knihovna by byla spíš na obtíž.

[Jirka]

třeba libucw

velka nevyhoda je to silene mnozstvi prikladu, jak tu knihovnu pouzivat. V tom se normalni clovek proste ztraci....

[Jiří J.]

Díky za tip, ale nevidím to ani v repozitáři Debianu, ani na RHELu, nevidím, že by to mělo nějakou větší popularitu, ... to už rovnou můžu použít CCAN a mít výhodu modularity.

Zkoušel jsem se jednu dobu ponořit do glibu, ale zamotal se do toho jejich C pre-preprocessoru (už nevím, jak se jmenoval), který "zjednoduššoval" kód tak, že vůbec byl čitelný. Protože bez něj to bylo jako psát kód s permanentně zapnutým capslockem. Divil bych se, kdyby už jenom výčet "základních" typů neodradil polovinu populace.

[Roman Došek]

Jen tak pro představu, které to jsou ty věci bez kterých se vůbec nedá programovat?

Je potřeba si uvědomit, že C se používá na kopě různých platforem (včetně embedded) a jakékoliv nafukování std. knihovny je tak spíš na škodu. A jak již říkali jiní, ta knihovna je ve stylu "Jak pejsek a kočička vařili general purpose C knihovnu". Na jedné straně jsou tam datové struktury, k tomu přihozené hashovací algoritmy, funkce na práci s threadama a framebufferem atd. atd., vlastní dokumentační systém a vlastní build systém? Wow

[Jendа]

Nejčastější struktury (spoják, strom, halda), nějaké buffered IO, a pak třeba funkce max().

[kralyk z abclinuxu]

Souhlasim, že tyhle věci by tam být mohly. V C++ stdlib jsou - můžeš případně psát C-like kód s použitím C++ kompilátoru a stdlib. Některé projekty to tak dělaj, takové C v C++. Imho to není špatný nápad.

Jinak C stdio je taky AFAIK buffered... Ale je pravda, že to v UCW vypadá flexibilněji...

[Roman Došek]

Jenže v C nejsou namespacy. A jakékoliv přidávání (třeba) datových struktur do standardní knihovny znamená rozbití existujících programů, protože neexistuje žádná striktní konvence v pojmenovávání standardních a nestandardních typů. A to ani neberu v potaz fakt, že ve spoustě programů psaných v C mají vlastní datové struktury význam - použití specifických alokátorů, optimalizace pro lepší využití cache apod. Tohle zpravidla v high-level jazycích není potřeba řešit a většinou ani nevadí nějaké výkonostní propady, dokud je pro správný úkol použit správný typ struktury.

Myslím že kdyby byla anketa mezi C programátory jestli chtějí datové struktury do std. knihovny, tak většina by byla zásadně proti. K tomu jazyku to tak prostě patří..

Větší zábava je když používáte víc jak jednu knihovnu a v každé z nich je zas a znova vlastní definice boolu. A to už je ve standardu roky.

[Bystroushaak]

To zní vážně příšerně.

Nikdy jsem nechápal, proč v C namespace nejsou. Přitom by to imho nemělo žádné nevýhody a naopak odstranilo celé hory retardovaných problémů.

[pavlix]

C sice namespace nemá, ale v knihovnách se z pochopitelných důvodů stejně používají, jenom pro ně holt není žádná zkratková syntax. Jenže namespace v C++ taky nejsou žádný zázrak.

[Bystroushaak]

No, to jsou „namespace“ na úrovni stringů v podstatě bez všech výhod, které běžný namespace poskytuje (možnost si ho lokálně pojmenovat, importovat z něj názvy a nemuset psát prefix pořád dokola).

[kralyk z abclinuxu]

A jakékoliv přidávání (třeba) datových struktur do standardní knihovny znamená rozbití existujících programů, protože neexistuje žádná striktní konvence v pojmenovávání standardních a nestandardních typů.

Některé věci v C11 mají pojmenování _Foobar, protože jména s podtržítkem následovaným velkým písmenem jsou vyhrazena pro implementaci.

[Jiří J.]

"Namespacy" v C jsou hlavičkové soubory - právě proto máme stdbool.h. Starší programy jej nemusí includovat a jejich definice bool zůstanou beze změny.

[pavlix]

Takhle jednoduché to není. Na úrovni linkeru se neprefixované shodné názvy symbolů tlučou. U toho boolu se to neprojeví, protože to není symbol.

[kralyk z abclinuxu]

Můžeš zkopírovat code style guidelines z nějakého jiného projektu, ne?

[Dadam]

Používáme C++ na ne úplně malý projekt (50k řádků, velmi hrubým odhadem), v týmu asi 5 vývojářů. Osobně je to můj hlavní jazyk asi 10 let a můžu říct, že C++ je složité. Myslím, že jestli chcípne, tak to bude kvůli tohoto.

V první řadě,

co i++ dělá, v C++ to může být přetíženo na system("rm -rf /*")

není problém C++. Je to jako napsat funkci increment(), která bude mazat systém. Jinak v C se tomu taky nevyhneš - pokud je i++ float, chování bude v určitých případech jiné kvůli zaokrouhlování.

Kritérium je jen jedno: kód musí být čitelný.

Opravdu - jako např. skalní zastánce explicitního typování - odmítnete patch, který implementuje 90% funkcionality pomocí generických auto funkcí, mumlajíc něco o skrývání bugů při změně datového typu a špatné debuggovatelnosti?

Tohle brutálně závisí na použití. Viděl jsem kód, který byl kvůli použití auto špatně čitelný. Viděl jsem kód (vlastně jsem ho napsal), kde auto nebylo (před zavedením C++11), misto toho byly kvůli zkrácení definované typedefy. Problém byl, že v každé třídě jinak (třídy vznikaly s časovým odstupem).

Co napsat do směrnic stylu kódu ("style guide")?

Nic, nějaké si najdi a nevymýšlej svoje. Na formátování nezáleží, jen musíte mít všichni stejné. Co se kódu týče, doporučuju první a druhý díl "Effective C++" od Scotta Meyerse.

Podobně třeba s iterací, budete akceptovat pouze for (int &i : v) a tvrdě odmítat "staré" ::iteratory? Nebo obráceně?

Ne. Podle toho, co s tím chceš dělat. Potřebuješ v cyklu zpracovávat hodnoty? První případ. Potřebuješ iterátory? Druhý případ. Pracuješ nad více poli? Indexy. Ano, v supermoderním C++ pořád někde používám indexy, protože je to čitelnější.

Co třeba chytré pointery? Budete vynucovat make_unique namísto new? Nebo naopak "staré" *pointery?

Ano, ne, ne! Vždycky se uchechtávám, když si nějaký javista stěžuje, že musí všecko uvolňovat sám. Zaprvé nemusí, zadruhé to stejně nedokáže. Proč? Pokud je v konstruktoru objektu vržená výjimka, nevolá se jeho destruktor (objekt není v definovaném stavu). Volají se jenom destruktory jednotlivých členů. Ošetřit tohle ručně je hrůza. Takže unique_ptr a shared_ptr je naprostá nutnost. Pokud bude v patchi použito delete tam, kde to není nutné, patch s vysvětlením odmítni.

make_* tu máme proto, abys mohl napsat:

auto var = std::make_unique<Type>(...)

místo

std::unique_ptr<Type> var(new Type(...))

make_shared je to samé, jen přidá mikrooptimalizaci v podobě alokace objektu a počitadla referencí dohromady.

Od jakého bodu je ten kód příliš odlišný od vaší představy? Od jakého bodu je "prasácký"?

Když se nedá číst, je to prasárna. Co se týče vynucování nějakých konvencí, dopoučuju What was the strangest coding standard rule that you were forced to follow? na StackOverflow.

[Dadam]

Pokud bych projekt zakládal já, tohle by byla má pravidla:

1. Zákaz používání using namespace X. Přísný zákaz používání using namespace X v hlavičkách.
2. Zákaz psaní delete. Na to máme chytré pointery.
3. Odkaz na definici formátování. Odsazovat namespace je prasárna.
4. Kód budete jednou psát, desetkrát upravovat, stokrát číst. Tak podle toho pište.

[Sten]

U 3 je IMO dobré odsazovat anonymní namespace (nebo nějaký hidden namespace v .h), ale ne namespace, ve kterém je vše v tom souboru.

[JSH]

make_shared je důležitý ještě z jednoho důvodu. V std::shared_ptr<Type> var(new Type(...)) může projít alokace objektu a selhat alokace kontrolního bloku pro shared_ptr. make_shared tohle hlídá a případně smaže i ten vytvořený objekt.

[Sten]

shared_ptr předaný ukazatel také smaže, pokud cokoliv v těle toho konstruktoru vyhodí výjimku.

[Dadam]

Přesně tak. A kvůli těmto drobnostem se hodí používat std. V takovém Poco si napsali vlastní SharedPtr a na tohle zapomněli...

[pavel]

50k řádku v pěti lidech? My tu máme 100+k řádků a jsme na to dva...

[pavlix]

A co z toho vyplývá?

[Bedňa]

Je platený od riadku.

[Michal Kubeček]

Asi to není jen o penězích, protože i v open source projektech člověk narazí na takovéhle úkazy:

/************************************************************

  Function: wait_for_reply

*************************************************************

  Inputs:  void (none)

  Returns:  int

  Description:
  

************************************************************/

#ifdef _NO_PROTO
int wait_for_reply()
#else
int wait_for_reply( void )
#endif
{

[Bedňa]

To sa nijak nevylučuje s tým čo som písal ;) Len zrovna prázdny "Description"?

[Michal Kubeček]

To byla pointa té ukázky: kilometrová hlavička, která ve skutečnosti nesděluje ani o bit víc informace, než samotná hlavička funkce. Tedy kromě toho, že ten, kdo ji psal, se vůbec nezamyslel nad tím, proč to dělá. Jinak by ho totiž muselo napadnout aspoň to, že místo typu (který snad dokáže odhalit každý, kdo absolvoval aspoň dvě lekce jazyka) by bylo mnohem užitečnější napsat, co ta návratová hodnota znamená.

[Bedňa]

Však aj pobavilo. Vstupné a výstupné typy by som uvádzal len pri jazykoch ktoré nemajú typovú kontrolu, hoci sám to nerobím. No popis je samozrejme vždy najviac.

Evidentne hlavičku komentára kopíruje zo šlabóny, možno na to má aj nejaký nástroj ktorý to robí sám a na to podstatné proste kašle.

[Dadam]

Tak jsem to změřil a vyšlo mi ~500 tisíc. Jsme se nějak rozrostli...

[jarin]

Co třeba chytré pointery? Budete vynucovat make_unique namísto new? Nebo naopak "staré" *pointery?

Ano, ne, ne! Vždycky se uchechtávám, když si nějaký javista stěžuje, že musí všecko uvolňovat sám. Zaprvé nemusí, zadruhé to stejně nedokáže. Proč? Pokud je v konstruktoru objektu vržená výjimka, nevolá se jeho destruktor (objekt není v definovaném stavu). Volají se jenom destruktory jednotlivých členů. Ošetřit tohle ručně je hrůza. Takže unique_ptr a shared_ptr je naprostá nutnost. Pokud bude v patchi použito delete tam, kde to není nutné, patch s vysvětlením odmítni.

Další problém s výjimkami je v tom, že např. parametry funkce můžou být vyhodnocené v jiném pořadí než jsou napsané v kódu a tak vznikají memory leaky, které ani na první pohled nejsou vidět.

např.

int a = x(will_throw(), new X()); // překladač může nejdřív zavolat new X() a pak ho nikdo neuvolní

Další problém nastane v případě asynchroního kódu, kdy ti nepomůžou ani smart pointery. Např. v callbacku z objektu si zrušíš smartpointer, takže se vyvolá destruktor. Jenže v tuhle chvíli jseš pořád v metodě objektu, který jsi právě zrušil. Tady už ti pomůže jenom redesign projektu, garbage collector nebo implementace lifetimů jako v rustu.

[Dadam]

Např. v callbacku z objektu si zrušíš smartpointer, takže se vyvolá destruktor.

To mi přijde jako docela hrůza v návrhu. Ale smart pointery ti pomoct můžou, jen si říkám, zda to není prasárna ještě větší. Ve svém kódu jsem techniku ještě nezkoušel.

1. Objekt vytvoříš a uložíš do smart pointeru
2. Smart pointer zaregistruješ do objektu (Fuj. Objekt vyžaduje nějaký způsob uložení).
3. Objekt samozřejmě neuloží smart pointer, ale příslušný weak pointer
4. Metody objektu z weak pointeru vytvoří smart pointer, kterým po dobu svého běhu drží objekt při životě.

[JSH]

Tohle jsem přesně dělal, když jsem používal asio. Potřebné objekty jsem odvodil od enable_shared_from_this, což je vlastně ten weak_ptr. A každá lambda, kterou jsem dával jako callback si nesla shared_ptr. Takže v callbacku jsem místo this->bla psal self->bla. Pokud se nedá asynchronnímu peklu vyhnout, pak mi tohle přijde jako rozumné řešení.

[biolog]

Např. v callbacku z objektu si zrušíš smartpointer, takže se vyvolá destruktor. Jenže v tuhle chvíli jseš pořád v metodě objektu, který jsi právě zrušil. Tady už ti pomůže jenom redesign projektu, garbage collector nebo implementace lifetimů jako v rustu.

Předpokládám, že ten callback vynulovává shared_ptr (v případě jiných chytrých pointerů to bude na méně řádek). V takovém případě nejprve obsah toho chytrého pointeru ulož do lokálního shared_ptr pointeru, pak vynyluj ten, který jsi chtěl vynulovat ("zrušit"), a na konci té funkce ten lokální shared_ptr vynulu... pardon, nedělej nic, nech ho zdestruovat.

[Bystroushaak]

Já jsem sám na sobě zjistil, že na C++ (a demenci v IT obecně) prostě nemám ani nervy, ani trpělivost. Ten jazyk je všechno, jen ne dobře navržený, tak proč s ním ztrácet čas?

Samozřejmě, určitým argumentem je asi komerční sféra, kde má člověk ovládající C++ široké uplatnění za dobré platy. Ale osobně bych se z toho zcvokl.

Co moc nechápu je, že C/C++ nemá žádný široce používaný komunitní package manager. pip / rubygems / luarocks / cpan / npm / dub dělají strašně moc k přispění všeobecné použitelnosti jazyka. Ano, sice jsem našel nějakou snahu o vytvoření čehosi, ale je to takové rozpačité a rozhodně ne všeobecně přijímané. Poslední rozhovor na tohle téma, který jsem vedl s C/C++ programátorem na IRC skončil v podstatě tak, že mi vysvětlil, že je to k ničemu a že by nic takového nepoužíval. Přijde mi, že tohle obecně mentalita rozšířená mezi programátory v C/C++. Znám asi tři, kteří si takhle celá leta reimplementují vlastní set modulů pro naprosto základní věci, které má každý všude jinde jako baterie z fráze „batteries included“. A nikomu z nich to nepřijde divné, naopak se ještě opřou do dalších knihoven, že se jim na nich něco nelíbí.

Když vezmu to děsivé množství času, které bylo vyplýtváno na reimplementace základních věcí, přijde mi to docela děsivé, skoro stejně děsivé, jako že to skoro nikomu nepřijde špatně.

[mirec]

Ako človek z prostredia C++ sa rôznym malým dependency bránim. Áno tiež si myslím, že balíčkovač pre C++ nemá zmysel.

Či je C++ blbo navrhnutý jazyk nemá zmysel diskutovať. Hlavný problém je v chýbajúcich konvenciách, takže raz nejaký modul používa shared pointre iný modul napríklad vracia surové pointre ktoré si treba upratať po sebe, iný zase používa surové pointre, ale upratuje si ich sám. V takom prostredí je použitie cudzieho modulu často rizikové ak nedodržiava rovnakú konvenciu ako zvyšok (treba dávať obzvlášť pozor čo sa volá, alebo celú knižnicu ak je to možné obaliť do vlastného rozhrania).

[Dadam]

Obalení každé knihovny do vlastního rozhraní jsem viděl i jako best practice pro testování - že pak mám definovaný způsob, jakým knihovnu používám, a když vyjde nová verze, tak můžu testovat.

Osobně mi to přijde jako docela overkill. V práci máme jednu hlavní knihovnu (Poco), kterou víceméně neobalujeme, a obalíme všechno ostatní. Sranda nás čeká teď, kdy Poco vydalo novou verzi, která není kompatibilní se starou, a my budeme muset přepisovat.

Tohle je podle mě hlavní síla C++ (a slabina knihoven třetích stran): zpětná kompatibilita. Až nějaký D, Rust, Python, Perl nebo PHP bude 10 let udržovat zpětnou kompatibilitu (jo, najdou se výjimky v podobě SFINAE), tak o něm popřemýšlím :)

[Bystroushaak]

Python například 10 let zpětnou kompatibilitu udržuje, spíš i déle. To že vyšla nová nekompatibilní verze ještě neznamená, že zmizela ta stará. Konkrétně python 2.7 má podporu minimálně do roku 2020 a sám je zpětně kompatibilní s verzemi řady 2.x, které jsou tu už opravdu dlouho (2.0 vyšla v roce 2000). Osobně si myslím, že ta podpora ještě bude prodloužena, protože business sféra se mi na přechod zrovna připravená nezdá.

[Dadam]

Tohle si ale nepředstavuju pod pojmem zpětná kompatibilita. To je údržba starých verzí. Já chci vzít kód, který jsem vyvinul pod moderním překladačem (interpretem) deset let zpátky a přeložit ho na moderním překladači (interpretu) teď.

[Bystroushaak]

AFAIK můžeš vzít kód z pythonu 2.0 a spustit ho na pythonu 2.7 (resp. všech verzích od 2.0 do 2.7.x), který bude podporovaný (= vychází nové verze) do roku 2020, tedy celých 20 let.

[Dadam]

My si pořád nerozumíme. Mně je jasné, že python 2.X mě přežije. Vadí mi, že nově vydaná řada 3.x není zpětně kompatibilní s řadou 2.x.

Svět je nyní rozdělen na dvě půlky, jedna používá python2, jedna python3, a ty dvě půlky si mezi sebou nemůžou vyměňovat kód.

[pavlix]

Tak Pythonisti už tuší, že se to z rozvázáním kompatibility maličko přehnalo, ale zase na druhou stranu Python 2.x obsahuje dost nepěkných failů, které stojí za to vymýtit.

[Dadam]

Python 2.x obsahuje dost nepěkných failů,

stejně tak C++, viz. třeba std::vector<bool>

které stojí za to vymýtit

Nad tímhle bych se pozastavil. Na jedné straně tady máme python, který faily vyháže za cenu ztráty zpětné kompatibility. Na druhé straně C++, které je plně zpětně kompatibilní za cenu ponechání nepěkných failů. A teď můžeme strávit zbytek času světa hádáním se o tom, který přístup je lepší

[mirec]

Alebo si napísať vlastný jazyk s vlastnými obľúbrnými failmi.

[pavlix]

Třeba přijde Python 4 s řešením, jak udělat obojí.

[Michal Kubeček]

Zachování starých failů i zavedení podstatných nekompatibilit? :-)

[pavlix]

Ano. Je to vcelku podobná situace té současné, kdy je v zásadě potřeba mít Python 2.x (se zachováním starých failů) i Python 3.x (se zavedením podstatných nekompatibilit). Bylo by fajn tuto dualitu alespoň řešit jedním softwarovým balíkem, který dokáže tyto dva přístupy kombinovat, ideálně v rámci jednoho interpretu.

[Tomáš]

A není tohle náhodou Python 2.7?

[pavlix]

Python 2.7 není nástupcem 3.x, neumí spouštět skripty napsané pro 3.x ani importovat moduly napsané pro 3.x, a hlavně tak není ani v rámci projektu prezentován. Ale jistě ukazuje alespoň část technik, které by se pro tento účel použily.

[Dadam]

Spíš to dopadne takto...

[dumblob]

A teď můžeme strávit zbytek času světa hádáním se o tom, který přístup je lepší

Ano, tohle je přesně ta nejdůležitější otázka. Mě osobně vůbec nezajímá odpověď, ale zajímá mě kdo na tuto otázku odpoví.

Pokud na ní odpoví vývojáři daného jazyka, kteří mu velice dobře rozumí (a tedy vytvoří novou zpětně nekompatibilní větev), tak uživatelé nemusí nic řešit (když uživatel zvolí novou větev, tak má garantováno, že v ní nejsou faily).

Naopak, když se tato zodpovědnost přenese na uživatele, kteří o jazyku ví houby v porovnání s autory (např. C++), tak co projektík, ba dokonce co řádek kódu, to zcela odlišný názor (prosím netahat za slovíčko, že zcela odlišný názor mohu mít na jakýkoliv řádek kódu v jakémkoliv jazyce bez ohledu na faily vyřešené ve zpětně nekompatibilní verzi).

Mně osobně přijde pro svět jednoznačně výhodnější když na tuto otázku odpoví tvůrci jazyka, než odpověď přenechat na miliónech z definice neznalých uživatelů. Ale proti gustu žádný dišputát.

[Dadam]

Když programátor ví o jazyku houby, tak mu nepomůže ani sebelepší standard.

Ona existuje ještě třetí cesta: nechat to tam, vyvolávat warningy. Tak jak to dělá gcc třeba u std::auto_ptr. Nebo aspoň zadokumentovat, že se tahle fíčura nemá používat.

[Bystroushaak]

Jo, to mi vadí taky, jen říkám, že to není až taková tragédie, jak by se mohlo zdát.

[Let_Me_Be]

Konvence existuji. Sice jsou velmi cerstve, ale jsou oficialni a budou k nim nastroje pro automaticke vynucovani.

[Dadam]

Nějaký odkaz by nebyl?

[JSH]

https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md

Pořád je to sice ve vývoji, ale vypadá to nadějně.

[kralyk z abclinuxu]

OMG, to je delší než starej zákon...

[Jiří J.]

A hlavně tak trochu prakticky nepoužitelné - vysvětluje to velmi vysokoúrovňové koncepty na neexistujících typech ("GSL", Guideline support library), odkazujíc se na možné budoucí vlastnosti jazyka. Přijde mi to jako vhodný doplněk standardu, takový "wishlist" / "rationale" některých vlastností, případně jako seznam věcí k zamyšlení se (právě pomocí vysoké úrovně), jako inspirace pro tvořitele sad pravidel, ne pro "uživatele".

[JSH]

Ty neexistující typy už mají minimálně dvě open source implementace. https://github.com/Microsoft/GSL https://github.com/martinmoene/gsl-lite

[Helb]

To tě neschopnost pochopit C++ fakt dostalo, že kvůli němu bulíš při každé příležitosti, tohle o tebe čtu asi po padesáté

[Bystroushaak]

To tě neschopnost pochopit C++ fakt dostalo, že kvůli němu bulíš při každé příležitosti,

C++ jsem pochopil, složil jsem z něho (dvě) zkoušky (za jedna), přečetl o něm několik knih, napsal několik projektů a řešil jeden komerční projekt (a nedořešil, kvůli stěhování na druhý konec republiky). Nepovažuji se v něm za nějak fluentního a těžko můžu říct, že jsem ho někdy ovládal plně. Přesto (a nebo možná právě proto) jsem dospěl k názoru, že je to velmi špatná technologie, okolo které všichni hodí jak kolem císařovo neviditelných šatů.

Potřebu uvést svůj názor pod tématicky stejné blogy cítím proto, že jednak může být špatný a pak by bylo dobře, kdyby byl vyvrácen, ale také jako varování pro lidi, kteří přemýšlejí, že s ním začnou, ale nejsou si zcela jisti.

tohle o tebe čtu asi po padesáté

To bude tím, že je to můj názor a je konzistentní napříč časem, resp. zatím se nenaskytlo nic, co by ho změnilo. Možná ti to přijde divné, ale chyba je imho v tobě, ne ve mě.

[pavlix]

Přesto (a nebo možná právě proto) jsem dospěl k názoru, že je to velmi špatná technologie, okolo které všichni hodí jak kolem císařovo neviditelných šatů.

Naprostý souhlas.

[Helb]

C++ jsem pochopil, složil jsem z něho (dvě) zkoušky (za jedna)

ROFL

[Dadam]

Jj, taky bych to asi zformuloval jinak

[Bystroushaak]

Proč? Zdá se ti jako ne-relevantní informace, že jsem tím strávil rok na VŠ?

[Helb]

Ne, všichni tě uznáváme jako experta, dokonce jsi si o tom přečetl knížku a nedodělal komerční projekt, ale samozřejmě víš, o čem mluvíš

[Bystroushaak]

Popsal jsem prostě co všechno jsem v tom dělal a nikdy jsem se nenazval expertem, dokonce jsem zdůraznil přesný opak.

Co nechápu je tahle tvoje retardovaná dětinská reakce plná smajlíků, kde se v podstatě veřejně směješ něčemu, co sis sám vymyslel, a ještě se to snažíš použít jako argument .. pro co vlastně?

[Dadam]

Ano. Já strávil rok na VŠ Javou, dostal jsem C bo kolega na projekt byl idiot, takže projekt jsem táhl sám a body se rozdělily, nicméně za svou část bych áčko dostal.

[Bystroushaak]

Tomuhle nerozumím. Moje reakce není relevantní, protože jsi rok strávil na VŠ Javou a měl jsi kolegu idiota, který může za tvojí horší známku?

[Dadam]

Ne celá reakce, ale ta část o dvou jedničkách. A ne proto, že jsem dostal horší známku, ale proto, že ačkoliv bych z Javy dostal áčko, stejně umím prd.

[Bystroushaak]

No, to je sice smutné, ale pořád mi to nepřijde jako argument, že je irelevantní uvádět školu jako příklad. To je přeci naprosto individuální.

[Dadam]

Však to sám říkáš, je to naprosto individuální. Proto když mi někdo vykládá, že měl ve škole z C++ jedničky, tak se jen usměju, protože to nedokazuje vůbec nic.

[Bystroushaak]

To bude tím, že jsem nechtěl „dokazovat“, že jsem expert na C++, ale jen ukázat, že mi nedělá problém C++ „pochopit“, jak naznačoval Helb. Tady mám prostě na papíře známku, která do určité míry garantuje, že to „chápu“, proto jsem to uváděl jako příklad. Jinak C++ jsem měl už předtím pár let na střední.

[Dadam]

Tak to rozsekněme. Tvůj názor je, že jednička ve škole dokazuje něco o schopnostech. Můj názor je, že jednička ve škole nedokazuje nic. Očividně se neshodneme, tak kašli na provokatéra a radši napiš další blog

[Bystroushaak]

Můj názor je, že záleží na škole. Já jsem ovšem nechtěl nic dokazovat jedničkou, jen ukázat, že jsem z toho nepropadal a že jsem tomu věnoval čas

[pavlix]

Prostě jsi se chytil na trolla, co si chtěl léčit mindrák. A tak se našel druhý troll. Ať už je tvá úroveň znalostí jakákoli, je to jen tvůj osobní názor, který někteří sdílí a jiní ne. A komu se to nelíbí... :)

[Helb]

To je přeci naprosto individuální.

A proto to nic neznamená

[Bystroushaak]

Nežádal jsem o obecné posouzení toho co to znamená, pouze to uváděl jako referenci. Ale nějak přestávám chápat, kam se tahle diskuze ubírá.

[Helb]

Šetří náklady - je z ní vidět, že tématu absolutne nerozumíš, nemáš zkušenosti, a akorát s ním spamuješ diskuze. Dej si do patičky, že jsi trouba a nebudeme tím muset procházet znovu, díky (smajlíky speciálně pro tebe, když jim přisuzuješ takový význam (narozdíl od tématu))

[Bystroushaak]

Slibuji, na svou čest žáka nepřihlášených dementů z internetu, že se polepším.

[kralyk z abclinuxu]

Přesto (a nebo možná právě proto) jsem dospěl k názoru, že je to velmi špatná technologie, okolo které všichni hodí jak kolem císařovo neviditelných šatů.

Otázka je, jestli je C++ špatné, protože je špatně navrženo, nebo protože je velmi náročné dobrý jazyk s tímhle zaměřením vytvořit.

IMHO to druhé. Nasvědčují tomu zkušenosti z pokusů vytvořit alternativu/náhradu C++, viz např. fiasko jménem D a podobně. Nejnovějším pokusem v tomhle směru je Rust a přes imho dobrou výchozí pozici se také potýká s velkými problémy...

[Bystroushaak]

Otázka je, jestli je C++ špatné, protože je špatně navrženo, nebo protože je velmi náročné dobrý jazyk s tímhle zaměřením vytvořit.

Imho to není binární otázka a špatně je to z obou důvodů. Ale zrovna ten první imho taky, protože historie toho jak to vznikla je více/méně omyl a původně nikdo neplánoval, že z toho bude jeden z nejpoužívanějších jazyků.

Nasvědčují tomu zkušenosti z pokusů vytvořit alternativu/náhradu C++, viz např. fiasko jménem D a podobně.

D mi přijde jako fiasko tak možná politicky, ne technicky. A zrovna poslední dobou mi přijde, že se spíš docela rozmáhá. I když už v něm nedělám, tak pořád vidím nějaké nové články v /r/programming. Kdybych hledal něco dneska, tak asi zkusím Rust, protože má lepší sociální trakci.

[kozzi]

JJ presne tak Jazyk D zdaleka neni fiasko, ano ma trochu pochmurnou historii, ale zda se ze se s toho v posledni dobe docela otrepava.

[kralyk z abclinuxu]

D mi přijde jako fiasko tak možná politicky, ne technicky.

Technicky to fiasko určitě není, v zásadě obdivuju autory, že to dokázali technicky dotáhnout tak daleko. Nicméně oni si IMHO vybrali hrozně těžkou výchozí pozici - museli zvládnout víceméně vše, co C++ a ktomu ještě přidat věci navíc, které C++ nemá a které zaujmou. No a v tomhle bodě právě úplně nevím, co to vlastně mělo být...

Kdybych hledal něco dneska, tak asi zkusím Rust, protože má lepší sociální trakci.

Hm, asi jo, ale přijde mi, že poslední dobou to trochu kleslo...

[Bystroushaak]

museli zvládnout víceméně vše, co C++ a ktomu ještě přidat věci navíc, které C++ nemá a které zaujmou. No a v tomhle bodě právě úplně nevím, co to vlastně mělo být...

Tak třeba jednoduchost, čistá syntaxe, kvalitní chybové hlášky, mixiny, jednoduchý paralelismus, poměrně široká knihovna ve stylu pythonu (batteries included). Ostatně D nezačal tvořit někdo náhodný, ale jedni z nejlepších programátorů kompilátorů C++ (Walter Bright a Andrei Alexandrescu), protože jim z toho málem hráblo. Kniha The D Programming Language mi přišla skvělá právě z důvodu, že Andrei tam často vysvětluje co se jim na C++ nelíbilo a proč to udělali v D jinak. Tahle kniha by imho o C++ napsat ani nešla, protože C++ je prostě více méně náhodné a žádná myšlenka ve stylu „proč takhle?“ za většinou featur nebyla.

[Michal Kubeček]

C++ je prostě více méně náhodné a žádná myšlenka ve stylu „proč takhle?“ za většinou featur nebyla

To, že ji tam vy nevidíte, nebo ve své averzi vidět nechcete, neznamená, že tam není.

[Josef Kufner]

Dobrým "jazykem", který bych počítal jako úspěšnou náhradu za C++, je Qt. Asi o tom těžko mluvit jako o samostatném programovacím jazyku, je to spíš podmnožina C++ (Qt nepoužívá různé ošklivé konstrukce) a rozšíření o signály a sloty (moc). A jde také o určitý styl psaní. Ve výsledku to však je dobře čitelné a přehledné.

[JS1]

Pod to bych se celkem podepsal. Kdyz dneska vidim, jak se patlaji webove aplikace - zlate Qt!

[JS1]

protože je velmi náročné dobrý jazyk s tímhle zaměřením vytvořit

A jake by vlastne C++ melo mit zamereni?

Ted si trochu hraju s Haskellem a musim dat zase po nejake dobe matematikum za pravdu. Dobra teorie je zaklad. I Lisp se da na Haskellu postavit, ale obracene, sotva.

Prijde mi, ze jeden z pozadavku je moznost vysoke urovne abstrakce (narozdil od C); jenze to funguje dobre jen pokud ten jazyk stoji na dobre teorii.

Na druhou stranu, je pozadavek na pristup k HW a menitelnost struktur, proste ma to byt imperativni jazyk. Jenze to jde dost proti sobe - mel by vubec nekdo chtit imperativni jazyk s vysokou urovni abstrakce? Leda snad, ze by se to misto lambda kalkulu postavilo na nejake zvlastni logice, napriklad. To by mozna slo, ale je to dekada vyzkumu.

[mirec]

Čo tak Rust? Výkon podobný C++ a celkom dobre definované konvencie.

[ugh]

Do toho jsem zatím spíš tak šťouchal a jakmile se mi povedlo se v tom trochu rozmluvit, dost se mi zalíbil. Alespoň ve srovnání s C++, což je legacy monstrsračka z dob minulých, jen postupně přiohýbaná, aby nestála za až tak moc velký hovno, a už to nechci v soukromém ani profesním životě vidět. Taky má hodně cool aid features.

Za hlavní nevýhodu momentálně pokládám absenci solidního IDE. Sleduju issue na doplnění solidnější podpory do YouCompleteMe (použitelné ve VIMu).

Potom možna nejistota v kompatibilitě s dalšími verzemi. Ale bude to lepší než ve Vale, kdy po několika letech jsem musel svoje projekty opatchovat, aby prolezly kompilací.

[tom]

Linked list pro C je implementovany v sys/queue.h. Viz man queue.

[Jiří J.]

To bohužel není ani POSIX, takže to u mě nenajde moc využití. .. Ale stejně dík.

Našel jsem díky tomu pěkné schovaniny jako insque(3) (POSIX.1-2001).

[tom]

Ta hlavicka je pomerne oblibena, je dostupna na vsech beznych UNIX like systemech.

[dumblob]

Pěkně napsaná úvaha - pod ní bych se podepsal.

Summa summarum, po dlouhých rozvahách a mnohahodinovém přemýšlení o tom, kolik "šedých oblastí" by C++ přineslo, se rozhodnu pro C a spolknu těch pár řádků vlastní implementace linked listu. Nebo skočím do Pythonu a zapláču nad výkonem. Před pár dny se to opakovalo asi po čtvrté a já si řekl, že přece musí existovat cesta ven z tohoto začarovaného kruhu - tak prosím poraďte.

Když rada, tak bych zcela jistě volil cestu experimentování s dalšími jazyky. Začal bych jazyky Dao, Go, Rust, Scala (zhruba v tomto pořadí - všechny tyto mají nativní podporu paralelismu v nějaké formě) a případně dále - Lua, Terra, Ceylon, ECMAScript 6 (aka ECMAScript 2015), C#.

Pokud jste velký zastánce KISS, Cckař a navrch nechcete mít moderní jazyk s paralelismem, tak bych pořadí jazyků přeskládal a na první místo dal Terra.

[Václav "Darm" Novák]

Jak je to s podporou GUI frameworků (konkrétně vy mě zajímal binding na Qt). Rust prý nějak umí QML, ale kvalitu nevím. Mám jeden GUI projekt a jelikož je to v začátku, experimentům se nebráním. (nutnost je funkčnost Windows + Linux.)

[mirec]

Podopora GUI je vec, čo ma na ruste dosť serie. Bindingy na kompletné Qt nie sú až tak jednoduché a QML ... to rieši dokopy jeden človek (alebo skôr riešil, repozitár vyzerá byť dosť mŕtvy).

[Václav "Darm" Novák]

Chtěl jsem zkusit D a tam taky nic moc. Ono to s Qt asi není zas až tak snadné, vzhledem k tomu jak komplexní framework to je.

[kralyk z abclinuxu]

Bindingy pro GTK jsou celkem použitelné a vývoj je celkem aktivní... Podpora určitě není kompletní, ale GUI program se v tom napsat dá, pokud člověk nepotřebuje moc speciální věci...

[dumblob]

Dle mého pozorování docela dobře. Bindingy pro známé GUI knihovny existují ve všech zmíněných jazycích. V některých není podpora 100% (např. Lua a Qt), ale není to zase takový problém si dobastlit potřebné bindingy či požádat upstream (bindingy se dělají dobře - je to spíše rutinní práce, takže ji zvládne téměř každý).

Pokud však holdujete KISS principu, pak určitě všemi deseti doporučím grafickou "knihovničku" Zahnrad, která mně osobně nesmírně vyhovuje (i na komplexní, velká UI) a dal bych za ní ruku do ohně.

[Bedňa]

To nevyzerá zle.

[Bedňa]

Tak som sa s tým pohral a moc použiteľné mi to ešte nepríde.

[dumblob]

V cem vsem Vam Zahnrad neprijde pouzitelny? Docela me zajima jake GUI problemy resi ostatni.

[Bedňa]

Bugovalo mi to, ale to môže byť spôsobené tým, že som si neprečítal nápovedu v kóde.

[dumblob]

Ju, na Vánoce byl naplánovaný přepis na nové API a tento opravdu proběhl, takže pokud zkoušíte aktuální upstream, tak na nějaké chybky narazíte. Doporučil bych předvánoční "stabilní" verze (např. z 15. 12. 2015). Každopádně debug probíhá mílovými kroky - chyby jsou opravovány do dvou či tří dnů (a nahlášením lze urychlit opravu třeba na hodiny z mé zkušenosti).

Ale samozřejmě je možná i chyba mezi klávesnicí a židlí - dobrý nápad je si skutečně přečíst nápovědu v kódu (kód je krátký a dobře čitelný).

[Bedňa]

takže pokud zkoušíte aktuální upstream, tak na nějaké chybky narazíte.

Ale samozřejmě je možná i chyba mezi klávesnicí a židlí

Jj, skúšal som najnovší upstream, je možné že je to tak 50 na 50 :)

[Michal Kubeček]

Abych trochu poškádlil všechny ty hledače různých YAPL (pokud možno co nejméně používaných) a svatého grálu Dokonalého Jazyka (pokud možno co nejméně prakticky použitelného), připomenu jeden tradiční talk na téma, proč je C++ tak úspěšným jazykem, když je přece úplně špatně a používal by ho jen šílenec: Why C++ Sails When the Vasa Sank (bonusový bod pro ty, kdo vědí, o jakou Vasu jde, aniž by si pustili video nebo použili vyhledávač).

[JS1]

Rad si ji poslechnu, ale paradoxne Scott Meyers nedavno oznamil, ze uz ho C++ nebavi a bude delat neco jineho.

[pavlix]

paradoxne Scott Meyers nedavno oznamil, ze uz ho C++ nebavi a bude delat neco jineho.

To se asi nevylučuje.

[pavlix]

Dostanu další bonusový bod, že jsem se s ní seznámil osobně?

[Michal Kubeček]

Klidně… Fascinuje mne na tom ta schopnost přetvořit technické fiasko v turistickou atrakci. V tom jsou ale žabaři proti Italům, ti takhle využili nejen věž v Pise, ale dokonce i celé město. :-)

[pavlix]

Náhodou je kolem toho krásný příběh ve stylu „You are an engineer“. :)

[Sten]

Spíš ve stylu „you are an expert but he's the boss“

[pavlix]

Pardon, myslel jsem, že už to všichni znají. Podle toho bosse hádám, že jsi zatím nedotčen.

[⧠ A = 0]

Za to vše vděčíme toxickým sračkám ve stockholmských vodách, bez nich by žádná atrakce nebyla.

[Jiří J.]

Díky, zajímavý pohled. Mě víc pobavila jeho předchozí přednáška z DConfu 2014.

(Ale na Daniela nemá, cha!)

[kverulant]

Problém v C++ je právě v tom, že je v něm možné všechno a to jak je vidět z praxe programátoři nezvládají. Takže v nových verzích C++ se autoři rozhodli to ještě rozšířit (a stejně blbě jako do teď *1) a tak vlastně nevylepšili nic, jenom přidal x nových stylů jak prasit. Bohužel ale v C++ je napsáno tolik kódu, že se ho ještě hodně dlouho nezbavíme a budeme muset s tím muset bojovat asi do nekonečna. A kdo se mnou nesouhlasí, tak určitě neviděl aspoň 5 let starý program v C++ vytvářený aspoň s části samouky (min. 90% programů).

*1 např. první věc co mně napadla v C++11 u provolávání konstruktorů, jestli je zakázaná rekurze. A přesně podle stylu C++ není a je to nedefinované chování. Takže další varianta jak pro programátory, tak pro autory překladače, jak to sprasit tak, že se v tom nikdo nevyzná (netroufám si odhadovat jak to nějaká "chytrá hlava" využije jako "elegantní řešení"). Přitom i java to má ošetřené snad úplně od začátku, tak absolutně nechápu proč do standardu nevynutili detekci při překladu, zvlášť když je to triviální.

[Sten]

Přitom i java to má ošetřené snad úplně od začátku, tak absolutně nechápu proč do standardu nevynutili detekci při překladu, zvlášť když je to triviální.

Protože to na rozdíl od Javy triviální není, v C++ metody (ani konstruktory) nemusí být definované inline, dokonce nemusí být ani ve stejném souboru. Překladač pak bude mít vážné problémy rekurzi vůbec poznat.

[Radek Miček]

Překladač pak bude mít vážné problémy rekurzi vůbec poznat.

Proč? Při linkování je přeci vše k dispozici, ne?

[Sten]

Není. V Itanium ABI linker vidí, že ten .o soubor vyžaduje konstruktor z jiného .o souboru a ten konstruktor vyžaduje konstruktor z toho prvního .o souboru, ale už nevidí, kdo v tom prvním .o souboru vyžaduje konstruktor ze druhého .o souboru. Klidně tam může být konstruktorů víc, a pak je to legitimní kód.

[Sten]

Pardon, má tam být: první .o soubor vyžaduje konstruktor z druhého .o souboru a druhý .o soubor vyžaduje konstruktor z prvního. Ani u jednoho linker nevidí, kdo v tom .o souboru to vyžaduje.

[Radek Miček]

Aha, díky.

[Jiří J.]

Díky všem za odpovědi.

Nečekal jsem magické řešení, nepotřeboval jsem přímé odpovědi na otázky v zápisku (byly spíše reprezentativní), pouze jsem chtěl asi nadhodit volnější otázku typu "jak řešit různorodost přístupů přispěvatelů do projektu, umocněnou složitostí C++, bez bikesheddingu a podobného odrazování od přispívání do projektu".

Jedním z takových faktorů by právě byl i vyčerpávající 100-stránkový dokument toho, co se může a nemůže používat, co je přijatelné a co ne, apod. - než aby to schopný kolemjdoucí programátor četl, tak se mi na patch vybodne. Ostatně něco velmi podobného nedávno řešil Python:

The one-off nature of the CPython toolchain and workflow means that any new contributor is going to need spend time learning the tools and workflow before they can start contributing to CPython. Once a new contributor goes through the process of learning the CPython workflow they also are unlikely to be able to take that knowledge and apply it to future projects they wish to contribute to. This acts as a barrier to contribution which will scare off potential new contributors.

"Malým projektem" jsem pak myslel spíše "já něco napíšu, otevřu zdroják a rád bych, aby mi s tím občas někdo pomohl" spíše než "máme úzkou skupinu 5 lidí, kteří spolu neustále komunikují" - to jsem nevysvětlil, mea culpa.

Trochu mě přitom překvapila současná popularita C - měl jsem za to, že dnes už je to jen jazyk pro jaderné vývojáře a jiné vousaté dědky a trochu se vyděsil, kam se to řadím. Ale vono fakt ne.

Možná jsem taky trochu doufal, že bude existovat nějaká "databáze" stylů psaní / používání vlastností C++, podobná stylům indentu s chytlavými jmény. Pokud neexistuje, škoda.

Každopádně díky za diskuzi.

[Josef Kufner]

U tak malých projektů to nemá smysl moc řešit. Přispěvatel by se měl držet stylu, který v projektu vidí. Ten pull request pak buď přijmeš, nebo ne. A nebo ho přijmeš a opravíš.

Jakmile se začnou pull requesty objevovat v nezanedbatelném množství, může být vhodné sepsat kapitolu do README, kde uvedeš základní požadavky na styl i formátování. Díky těm neřešeným příspěvkům dříve budeš vědět, co je potřeba explicitně zmínit a co funguje samo.

Něco také pořeší .editorconfig (tím bych v README začal). A také je dobré přihodit konfiguraci formátovadla kódu, např. parametry indentu.

Já sám psal code style jednou a vešlo se to v pohodě na jednu stránku i s návodem na používání gettextu.