devel.cz

Komentáře

• dsteiner : Ještě abych to doplnil a napsal oč mi jde. Budu teď měnit práci a uznal jsem, že nejraději bych se vrátil k C++ přičemž by mi nevadilo nebo bych se chtěl naučit v praxi používat nové rysy jazyka C++11. Toť můj cíl. V minulosti jsem programoval v C++ (2001-2013), poté Java (2013-14), pak C++ na linuxu (2015) a nyní opět Java. Od roku 2011 jsem vystřídal co se týká C++ dvě firmy. Ani v jedné se C++11 nepoužívalo z historických důvodů. V té první protože se používala knihovna wxWidgets, která má řadu tříd a funkcí, které možná částečně nahrazují nové rysy, knihovny STL, BOOST apod. Ale nevím, já zase neznám pořádně tyhle. A wxWidgets není moc kompatibilní s C++11. Jsou tam např. typy wxArray nebo wxArrayString a když budu přes takové pole iterovat, tak to prostě neposkytuje patřičný interface pro zápis např. tohoto kódu: for (auto it = myvector.cbegin(); it != myvector.cend(); ++it) {...} V té druhé firmě to byly zase embedded aplikace na linuxu (HW v telefonní ústředně) a tam jim to nepřeložil kompilátor. Jde mi čistě o to, jak moc velký je to pro mě hendikep (neznalost C++11 v praxi) z hlediska hledání nové práce. Na druhé straně jak se tak dívám na nabídku firem Honeywell, Ixperta, Systek a další v okolí, tak bych řekl, že více pozic je právě na to old school C++ než na to nové. — 3.2.2017
• Staon : Smart pointery a RAII s novou normou nesouvisí. Jedná se o návyky, které byly pro C++-kaře běžné i před C++11. Pokud vám nic neříkají, nikdy jste neprogramoval v C++, ale pouze v "C s třídami" (např. bez smart pointerů nebo obecně RAII je prakticky nemožné používat výjimky). Nová norma v případě smart pointerů nepřináší nic moc nového, spíš pouze opravuje původní problémy (hlavně tu prasárnu v operátoru = v std::auto_ptr). Jediný důvod, proč nové vlastnosti nepoužívat, je, podle mne, nutnost přenášet kód na překladače, které C++11 nepodporují. Nemůžu mluvit obecně, ale u nás ve firmě by neznalost C++11 nebyla žádný handikep (máme starý překladač). Ale za neznalost RAII, smart pointerů, práce s výjimkami, práce s (před C++11) STL kontejnery bychom se s vámi natrvalo rozloučili ihned po pohovoru. — 13.3.2017
• dsteiner : 2 Staon: Díky za reakci. Přiznám se, že mě moc nepotěšila. Mám z ní takový dojem, že nějaké oblasti z C++ prostě neumím (a nevím přesně co a jaký to má rozsah - zda se to člověk naučí za týden nebo za rok) a to by bylo příčinou neúspěchu hned na pohovoru v některých firmách. Je to pro mě šokující, jelikož v C++ dělám už od VŠ tedy od roku 1996, kdy jsem se ho začal učit. Komerční praxe pak v součtu 13 let ve 4 různých firmách v letech 2001-2015 (kdy tedy 5/2013-12/2014 jsem v C++ nedělal). Nikde jsem nepotřeboval a ani nevím o tom, že by moji kolegové potřebovali / používali : smart pointery, RAII nebo C++11 a vyšší. Výjimky jsme občas používali, ale rozhodně ne tak často, jak jsem se s nimi setkal v Javě. Co se týká STL kontejnerů - nějak si nejsem vědom toho, že bych je používal, ale pracoval jsem s knihovnou wxWidgets (v letech 2005-2013) tak možná, že tato knihovna obsahuje podobné věci jako STL. Pokud ano, tak jistě není dobré to míchat. Co jsem se bývalých kolegů nedávno ptal, tak uvedené věci (smart pointery, RAII..) ve své práci stále nepoužívají. Stejně mi připadá, že těch pracovních míst na staré C++ je pořád hodně a o dost víc než na to nové. Když jsem v roce 2015 opouštěl firmu, tak mi nadřízený říkal, že jako C++ vývojář jsem výborný. Jenže tam by mě čekala práce, kde to zrovna o C++ nebylo. — 14.3.2017
• dzejkob : Nemůžu si pomoct - ale připadají mi to banality - i se svým více méně okrajovým použitím c++ stačí uvedené pojmy vyhledat - a potom přečtu a vidím a vím, že jsem místo toho použil třeba boost, nebo něco jiného. Nevím, proč by se kdokoliv nemohl jednoduše naučit používat tyto standardy, když používal cokoliv jiného. — 14.3.2017
• Staon : dzejkob: bohužel se mýlíte. Tyhle "banality" jsou rozdíl mezi kvalitním C++ kódem a nekvalitním kódem. Máme ve správě kódovou základnu, jejíž první dvě třetiny byly psané s vaším přístupem a v současné době nás táhne ke dnu natolik, že se bojím, že firmu nakonec v budoucnu dovede ke krachu. Podle našich pozorování naučit se efektivně používat C++ s výjimkami (mluvím pouze o používání, nikoliv o špecích jako je psaní šablon a metaprogramování) je výcvik minimálně na 3 roky a to pouze za předpokladu, že programátor má zájem a snaží se. Jen pro ukázku jednoho z mnoha problémů, které vám C++ je schopné přichystat (tato situace se mi skutečně stala, není to jen nějaký školní příklad). Na následující řádce kódu je potenciální memory leak. Dokážete řict kde? std::auto_ptr<Object> object_(new Object(allocateID())); — 15.3.2017
• dzejkob : No nemám zkušenost s údržbou rozsáhlé codebase v c++ ve více lidech - takže nevím - na moje malé projekty o max jednotek 10k loc mi místo stl stačil analogicky boost, mutexy taky boost, "smart pointery" mám nějak "zdrátované" po svém a výjmky je pravda, skutečně v c++ nepoužívám. Uznávám, že ta learning curve je dlouhá a "špeků" je dost - nicméně kdyby mi někdo sdělil, že naučit se používat výjmky v c++ mi bude trvat 3 roky, tak před 10 ti lety bych se do toho možná s chutí pustil - dnes od toho raději utéct s dalším důvodem navíc, proč je lepší do c++ raději více času už neinvestovat. — 14.3.2017
• Anonym : @Staon Tipnu si ... Destruktor, který vyhodí výjimku vytvoří *memory leak*. — 14.3.2017
• Staon : dzejkob: máte pravdu. C++ miluji, ale dneska bych do něho už asi taky nešel :-) — 15.3.2017
• Staon : uetoyo: v tomhle výraze se destruktor nevolá. Volá se tam funkce funkce allocateID, operátor new, konstruktor Object a konstruktor auto_ptr. Teoreticky by se mohl volat destruktor, kdyby se musela aplikovat automatická konverze mezi výsledkem allocateID a argumentem konstruktoru Object (což jsem neuvedl), ale takový chyták to není. Memory leak je tam i v případě, že k žádné konverzi nedochází. Mimochodem, výjimky vyhazované z destruktoru jsou ultra-prasárna, která může vést k násilnému ukončení procesu v průběhu odvíjení zásobníku při zpracování výjimky. Další z oblíbených C++ chytáků a know-how, které může programátor zaplatit skoro krví. — 15.3.2017