Vyplatí se učit C++?

[Solmyrus]

Souhlasim, ale presne jak rikate. Jde to kdyz jsou knihovny, ale moc jich neni. Java/C# na tohle nabizi nejen knihovny, ale uceleny technologie.
Vazim si kazdyho kdo neco umi, tudiz i lidi co ovladaji C++. Nicmene je nutne brat v potaz to, ze vytvoreni javovske aplikace  bude z 90% rychlejsi kvuli dostupnym technologiim a vetsi blbuvzdornosti. S spousti retez -> aplikace v jave/C# jsou levnejsi -> vetsina firem co chteji slozitejsi informacni system voli javu/C# -> vetsi poptavka na trhu prace.
Clovek, kterej ma na to ovladnout C++ a da se na rychle porozumi architekture technologii a vyhoupne se nad radovy programatory. Tim chci rict jsou i javysti, pred kterejma smekam protoze spravne navrhnout velkej informacni system vyzaduje stejny ne-li vyssi naroky nez na dobryho cppckare.

[Reklama]

[zboj]

Stručně můj názor:
Ten, kdo neumí C++, je jen programátor, zatímco ten, kdo C++ umí, je pan Programátor.
A je jedno, v čem programuje!

Nepravda. C++ je složité, ale není to jediné kritérium odlišující lopatu od profíka.

[Petr123]

Ten kdo umi LISP je pan Programator (viz SICP), ten kdo umi ASM je pan Programator, atd... nikdy nepochopim proc se kvuli nekolika lamam ktere za cely zivot neumi vytahnout hlavu ze sve vlastni zadeke musi vzdy zvrhnout jakakoliv diskuze v absolutni frasku.

[Borekza]

Nevšiml jsem si, zda v tomto vláknu bylo zmíněno RAII. To je asi největší výhoda C++ proti jazykům s GC paměti. Zdůrazňuji tu paměť, protože GC neřeší prostředky operačního systému (handly, soubory, sokety) a databázové prostředky (spojení, příkazy, result sety).
Je smůla, že C++ nemá standardní API pro sokety a databáze. Boost nepočítám, protože to není standard.

Jak by mohlo vypadat SQL API pro C++ v duchu RAII, ilustruje třeba knihovna SOCI. Je možné napsat něco jako

Kód: [Vybrat]

std::string jmeno, prijmeni, rodne_cislo = "123456";
SOCI::SQL(db,jméno,heslo) << "select jmeno,prijmeni from tabulka where rodnecislo=:rc", into(jmeno), into(prijmeni), use(rodne_cislo);
První objekt je databázové spojení, které lze uložit do proměnné nebo neuložit a rovnou na něm provést příkaz sql pomocí přetíženého operátoru <<. Pomocí přetíženého operátoru "," jsou zadány vazby na C++ proměnné. Funkce "into" a "use" balí proměnné různých typů do objektů řešících konverzi dat. Prostředky samozřejmě uvolňují destruktory.
Podobně elegantně jsou řešené připravené dotazy i resultset s více řádky, které je navíc možno iteratovat v knihovně STL.

V Javě s JDBC by stejný dotaz vypadal asi takto, s použitím try ... finally pro bezpečné zavření spojení:

Kód: [Vybrat]

Connection c = DriverManager.getConnection(db,jmeno,heslo);
try {
 PreparedStatement ps = c.prepareStatement("select jmeno,prijmeni from tabulka where rodnecislo=?");
 ps.setString(1, rodne_cislo);
 ResultSet rs = c.createStatement().executeQuery("select jmeno,prijmeni from tabulka where rodnecislo=?");
 if (rs.next())
 {
   jmeno = rs.getString(1);
   prijmeni = rs.getString(2);
 }
} finally {
 c.close();
}
Petr123: kdo umí Assembler a C++, je pan Programátor, ale dělá většinou mizerně placený embed jako alarmy, docházkové terminály nebo jiná mačkátka s displeyem, v lepším případě nějaké řízení strojů, i když na to jsou jiné jazyky než C++. A v některých starších firmách se (rovněž za bídné peníze) dělá Win32 desktop ve Visual C++ (MFC) nebo Delphi.

[noname]

Souhlasim, ale presne jak rikate. Jde to kdyz jsou knihovny, ale moc jich neni. Java/C# na tohle nabizi nejen knihovny, ale uceleny technologie.
Vazim si kazdyho kdo neco umi, tudiz i lidi co ovladaji C++. Nicmene je nutne brat v potaz to, ze vytvoreni javovske aplikace  bude z 90% rychlejsi kvuli dostupnym technologiim a vetsi blbuvzdornosti. S spousti retez -> aplikace v jave/C# jsou levnejsi -> vetsina firem co chteji slozitejsi informacni system voli javu/C# -> vetsi poptavka na trhu prace.
Clovek, kterej ma na to ovladnout C++ a da se na rychle porozumi architekture technologii a vyhoupne se nad radovy programatory. Tim chci rict jsou i javysti, pred kterejma smekam protoze spravne navrhnout velkej informacni system vyzaduje stejny ne-li vyssi naroky nez na dobryho cppckare.

S tým návrhom súhlasím, to je dosť umenie a vôbec to nie je jednoduché navrhnúť a potom ďalej spravovať, rozširovať, udržovať veľký systém. Taký človek musí jednak vedieť perfektne programovať a musí vedieť veľmi veľa o softwerovom inžinierstve.

[Reklama]

[Petr Novák]

S tým návrhom súhlasím, to je dosť umenie a vôbec to nie je jednoduché navrhnúť a potom ďalej spravovať, rozširovať, udržovať veľký systém. Taký človek musí jednak vedieť perfektne programovať a musí vedieť veľmi veľa o softwerovom inžinierstve.

Navrhnout aplikaci žádné umění není. Největší průser je právě to rozšiřování, což programátor neovlivní, stejně jako rozporuplné zadání. Tady má výhodu menší firma nebo živnostník, protože toho nikdo nenutí na nesmylné požadavky kývnout. Pokud se nejde se zákazníkem dohodnout, tak ať jde jinam. Průser větších firem je v tom, že nesmyslné zadání častěji z hlavy "analytika" nebo "architekta" než z hlavy zákazníka. Analytik totiž skutečnou analýzu neprovádí, jen zapisuje průběh schůzky se zákazníkem, nemá ponětí, co se honí v hlavě zákazníka a po skončení schůzky končí práce analytika. Skutečná analýzaje zůstane na programátorovi a to bez kontaktu se zákazníkem. Poslední slovo má "analytik" (většinou vedoucí vývoje nebo projektový manager), který je přesvědčen, že zákazníka pochopil.

[andy]

Hento porovnanie sql je neferove, lebo v c++ by si musel ukazat ako vyzera ODBC.
Btw mna fascinuje odbornik na c++ co nevie citat..

[borekz]

Hento porovnanie sql je neferove, lebo v c++ by si musel ukazat ako vyzera ODBC.

Nejde o SQL, ale obecně o desktruktory v C++ a RAII. Java má sice finalizer, ale ten je v praxi na nic. A tak se v Javě používají obyčejné metody pro vytváření a rušení prostředků, tak jak se v používaly obyčejné funkce v C před vynálezem C++.

Btw mna fascinuje odbornik na c++ co nevie citat..

Kde v předchozím příspěvku tvrdím, že jsem odborník ? Ani pořádně neovládám virtuální desktruktory při vícenásobné dědičnosti nebo novinky v C++14.

[borekz]

A když se ti nelíbí příkad se SOCI, tak jiný příklad s appendem do textového souboru (řekněme, že chceme schválně soubor pokaždé zavřít při zjišťování, kde program spadne):

C++:
std::ofstream("log.txt", ofstream::app) << " funkce xy, parametr " << param;

Java:
FileWriter wr = new FileWriter("log.txt", true);
try { wr.write("funkce xy, parametr " + param); } finally { wr.close(); }

Pokud nebazírujeme na 100% uvolňování prostředků, jde to podobně stručně jako v C++. Ale o tom to je v C++ to jde stručně a robustně zároveň.

Např. s hypotetickou třídou kombinující StringBuilder a Writer by šlo napsat toto, ale s rizikem neuvolnění prostředku při výjimce:
new FileAppender("log.txt", true).append("funkce xy, parametr " + param).close();

Nevím, jestli nejnovější JDK má takovou třídu ve stylu C++ streamů, ale není problém ji vytvořit a hlavně zde neřeším API, na rozdíl od tebe s tím ODBC. Pointa mého prvního příspěvku je v tom, že pouze v C++ se destruktor volá automaticky na konci bloku nebo po vyhodnocení výrazu a volá se i v případě výjimky. Takže se nemusí ručně psát try .. finally { volej náhradu destruktoru } a protože to dělá kompilátor automaticky, eliminuje se chyba lidského faktoru.

Vychvalovači Garbage Collectoru zapomínají, že operační paměť není jediný typ systémového prostředku.

[Solmyrus]

Porovnavat moznosti jazyka na takovyhle primitivni syntaxy je dost lamerina. Je to jako porovnavat schopnosti auta podle toho jakou ma klilku na dverich.
Spis by me zajimalo jestli ma cpp veci ktery by naplnily Java EE standart. Ma slusny ORM? Ma injectovani? Ma neco jako JTA?
Pokud ano verim ze je v bussinesu pouzitelny.

Jinak ze navrhnout apku dokaze kazdej... Kolik jsi navrhoval vetsich veci? Prave rozsiritelnost je dana navrhem na zacatku.

[hu]

Vychvalovači Garbage Collectoru zapomínají, že operační paměť není jediný typ systémového prostředku.

Tesat.

[Daniel Kozak]

Vychvalovači Garbage Collectoru zapomínají, že operační paměť není jediný typ systémového prostředku.

Prave, proto nechapu proc je zde zminovane RAII a GC, to spolu moc nesouvisi. Jak uz jste sam napsal GC je jen pomucka pro spravu pameti. Neni problem pouzivat GC a RAII zaroven. Samozrejme je potreba pouzivat jazyk, ktery to umoznuje.

[Jakub Galgonek]

V Javě s JDBC by stejný dotaz vypadal asi takto, s použitím try ... finally pro bezpečné zavření spojení:

Kód: [Vybrat]

Connection c = DriverManager.getConnection(db,jmeno,heslo);
try {
 PreparedStatement ps = c.prepareStatement("select jmeno,prijmeni from tabulka where rodnecislo=?");
 ps.setString(1, rodne_cislo);
 ResultSet rs = c.createStatement().executeQuery("select jmeno,prijmeni from tabulka where rodnecislo=?");
 if (rs.next())
 {
   jmeno = rs.getString(1);
   prijmeni = rs.getString(2);
 }
} finally {
 c.close();
}

Nebo nějak takto:

Kód: [Vybrat]

try (Connection c = DriverManager.getConnection(db,jmeno,heslo)) {
 try (PreparedStatement ps = c.prepareStatement("select jmeno,prijmeni from tabulka where rodnecislo=?")) {
   ps.setString(1, rodne_cislo);
   ResultSet rs = ps.executeQuery();
   if (rs.next()) {
     jmeno = rs.getString(1);
     prijmeni = rs.getString(2);
   }
  }
}


[Pavel Tišnovský]

Nejde o SQL, ale obecně o desktruktory v C++ a RAII. Java má sice finalizer, ale ten je v praxi na nic. A tak se v Javě používají obyčejné metody pro vytváření a rušení prostředků, tak jak se v používaly obyčejné funkce v C před vynálezem C++.

Sice to není úplné RAII, ale při použití rozhraní Autocloseable v Javě zrovna u toho SQL dosáhneš podobného výsledku. A předřečník má pravdu v tom, že zrovna JDBC by se asi nemělo používat tak, že si v jedné metodě otevřeš připojení do databáze, vytvoříš statement, získáš výsledky a potom to všechno zase uzavřeš (i když tady v jednom nejmenovaném seriálu se to používá..:-/)

[Ondro]

Navrhnout aplikaci žádné umění není. Největší průser je právě to rozšiřování, což programátor neovlivní, stejně jako rozporuplné zadání. Tady má výhodu menší firma nebo živnostník, protože toho nikdo nenutí na nesmylné požadavky kývnout. Pokud se nejde se zákazníkem dohodnout, tak ať jde jinam. Průser větších firem je v tom, že nesmyslné zadání častěji z hlavy "analytika" nebo "architekta" než z hlavy zákazníka. Analytik totiž skutečnou analýzu neprovádí, jen zapisuje průběh schůzky se zákazníkem, nemá ponětí, co se honí v hlavě zákazníka a po skončení schůzky končí práce analytika. Skutečná analýzaje zůstane na programátorovi a to bez kontaktu se zákazníkem. Poslední slovo má "analytik" (většinou vedoucí vývoje nebo projektový manager), který je přesvědčen, že zákazníka pochopil.

Pekne napisane. Ja len doplnim, ze na to vsetko su potrebne skusenosti. Bez toho clovek nema sancu to dobre navrhnut. Niekdedy ani to nepomoze a len sa to lepi aby to nejako fungovalo a casom uz ked to nebude udrzatelne(uz ani vykonny HW nepomaha), tak sa to mozno postavi odznova. Vo velkych firmach sa to velmi casto len lepi bez vecsej snahy to robit dobre.
Casto z jednej a ani druhej strany(zakaznik/dodavatel) sa nemysli na cloveka, ktory bude vysledny projekt pouzivat. Vysledkom toho je, ze program robi to, co ma ale uzivatelska privetivost je mizerna.