Proč se častěji programuje v C, než v C++?

10.5.2006 18:22 | Linux | poslední úprava: 10.5.2006 18:35

Proč je drtivá většina programů pro Linux napsaná v C, a ne v C++? Marně hledám na tuto otázku odpověď...

       

Komentáře

[Zdeněk Burda]

Jak jsi došel k tomu, že je v linuxu víc používané C# než C++?

[Thunder.m]

Jádro je předce taky v C# (nebo ne?) a když si pro sebe kompiluju nějaký program, tak soubory v nich mají koncovky .c, nepamatuji si že bych kompiloval program s koncovkami .cpp (nebo vývojáři ignorují názvy souborů?).

[Michal Karas]

To si děláš legraci, že jo? Koncovka .c znamená, že je to staré dobré C.

[Thunder.m]

Tak teď to asi nechápu :) Je nějaký rozdíl mezi C, C# a C++? Nebo jsou jen dvě verze C (C#) a C++ jak jsem si to myslel?

[Michal Karas]

Nejdřív bylo C, pak dlouho nic, potom C++ a nakonec až přišel Microsoft s C#.

[happy barney]

medzi C++ a C# bola Java, ale m$ nechce mat nieco kompatibilne, tak si vymysleli "vlastnu javu" a nazvali to C#.
tym nevravim, ze Java ci C# su dobre ci zle programovacie jazyky.

[Zdeněk Burda]

C, C++ a C# jsou rozdílné potvory, podívej se třeba na google (hledej C language, C# language a C++ language)

[Thunder.m]

Díky, upravil jsem název a obsah blogu :)

[diverman]

Já nevím jak C#, ale zdrojové soubory jazyka C se ukládají většinou jako .c, soubory C++ do .cpp.

C# určitě není na linuxu doma. O to se snaží projekt Mono.

[David Watzke]

C++ nejen .cpp ale i .cc (což je IMHO lepší ).

[diverman]

Ono je to principielně jedno. Ale proč zrovna .cc?

[David Watzke]

Nevím kdo to vymyslel... ale je to asi podle "C with Classes".

[Martin]

sípípí

sísí

cpp mi jako zkratka přijde logičtější, ale zato to zní pěkně...hmmmmm...idiotsky? ;o)))

[David Watzke]

Mně přijde logičtější .c++

[andree]

je to uplne fuk, hlavne aby sa dali odlisit od headrov... a kto tu pozera na pripony, ked pracuje v nejakom IDE typu visual studio/kdeveloper? vo velkom projekte si treba drzat poriadok v inych veciach ako v priponach

[Martin]

A jak bys tu připonu v angličtině četl, ty chytrej? ;o)

[Michal Kubeček]

Že by zcela překvapivě "see-plus-plus"? :-)

[kozzi]

spis "see-plas-plas"

[David Watzke]

Když už jsme u toho, tak spíš "sí-plas-plas", ne?

[zde]

C++ se zásadně čte jako ceeee - flus - flus, a pro správnou výslovnost je třeba nejprve trochu odchrchlat, natáhnout hleny na jazyk, a pořádně se nadechnout.

[Michal Kubeček]

No, nevím. Buď to chcete psát anglicky - a pak trvám na see-plus-plus (možná sea-) - a nebo česky - a pak spíš sí-plas-plas… Nebo je tu ještě možnost použití standardní fonetické transkripce (si: - plʌs - plʌs), ale určitě ne "see-plas-plas"…

[Martin]

Kruci, zas tak blbej nejsu ;o) Myslel jsem to tak, že sííplasplas mi zní ještě blbějc než sípípí :o))

Eh...to nereš ;o)

[Michal Kubeček]

To je věc osobního vkusu. Vzhledem k tomu, že se tak jmenuje i ten jazyk, asi vám nezbyde, než si na to zvyknout… :-)

[Martin]

Šlo mi o čtení názvů souborů...ale to je fuk, říkám - neřeš to...bylo to jenom chvilkový zatemnění mozku, už je to dobrý ;o) Jsem v pořádku :o)

[David Watzke]

Proč bych četl příponu a proč v angličtině? Prostě Cé plus plus Nepovídám si s těmi soubory, důležitý je, že hned vím co jsou zač

[Martin]

Sorry :o)

Celý dny se učím na maturu a už z toho blbnu. Fakt to nemělo hlavu ani patu, co jsem říkal, došlo mi to příliš pozdě ;o) Můžem na to zapomenout? Prosím? ;o)

[David Watzke]

Zapomenout? Na co?

[Martin]

Jak to mám vědět? Já netuším, na co jsi zapomněl... :o)

[Luboš Doležel (Doli)]

Lze používat i příponu .cxx a pro zlost Windowsákům i příponu .C

[Kníže Ignor]

podle mě je teda C++ Č, takže pokud tam nechcete mít ta pluska

[kozzi]

no ja bych rek ze .cxx

[Thunder.m]

Díky za jasnou odpověď, teď už v tom nemám bordel :) A teď k otázce blogu :)

1. Je to tak že programy v C převládají nad těmi v C++? (hlavně psané pro linux) 
2. if (předchozí_věta) {proč?};

[andree]

nemam presne statistiky, ale asi to tak bude... c je holt jednoduchsie na naucenie sa a s trochou nervov sa v tom da napisat to iste ako v c++. Uz ina vec je ako sa to udrzuje (ja som napr. v cistom c neurobil aplikaciu (taku co aj nieco uzitocne robila) uz nejakych tych par rokov). Ale pozri - ak chce niekto naprogramovat hru alike piskvorky alebo nejaky programcek typu dd, je to fakt zbytocne robit v c++ (napr. kvoli vacsim binarkam.. co jaaa viim? :) ). Pisat kernel v c++ by asi bola blbost no - tam to skratka netreba (aj ked na druhej strane by to kludne mohlo skoncit ako spor assembler vs. vyssie jazyky). Vacsina veci su tam uzavrete celky a ziadne dedicnosti a podobne veci tam pouzivat snad nie je treba...

Na druhej strane - je otazka co povazujes za vacsinu programov. Ak sa nemylim, vsetky programy pre KDE su v c++ (qt je objektova kniznica no), uz pomaly aj gnome funguju na c++/c# (vid spominane mono).

[Spike]

Gnome je postavené na knihovně GTK+ (2) a ta využívá čisté C + GObject. (Samozřejmě, uživatelské aplikace jsou psány v nejrůznějších jazycích -- C++, C#, Python...)

[Miloslav Ponkrác]

psát kernel v C++ je naprosto v pohodě, není to problém. klidně bych si do toho troufnul, dokonce raději než v C. taky pár kernelů různých operačních systémů napsaných v C++ bylo. namátkou Symbian, nebo jedna implementace mikrojádra L4 (tuším, že se má používat v Hurdu). Důvodem, proč není více operačních systémů napsaných v C++ je to, že C++ je tu teprve krátce, zatímco C daleko déle. proč by měla být blbost psát kernel v C++? proč by C++ muselo nutně dávat větší binárky?

já kdybych dnes začal psát operační systém, tak C++ a asm je pro mě jasná volba. nic lepšího neznám.

[lankvil]

Ve starém dobrém céčku je to větší zábava.

[hwsoft]

Ja bych pro embeded zarizeni v C++ psat nemohl, obcas mam jenom 2kByte RAM a to v plusku nestaci ani na cout ;).

Ale treba QT se mi libi, je to sice takovy znasilneny C++, ale pise se v tom dobre.

[Thunder.m]

Je třeba kód v C rychlejší, než v C++?

[Michal Kubeček]

Na to se nedá jednoznačně odpovědět. Někdy ano, někdy ne. Záleží na tom, jaký kód, jaký použijete překladač, s jakými volbami atd. Navíc je otázka, co vlastně chcete porovnávat. Ve většině případů sice céčkový zdroják přeložíte i jako C++, ale takové použití C++ postrádá smysl. To je jako kdybyste napsal formálně céčkový zdroják, který by ale ve skutečnosti používal pouze inline assembler a nic z vlastního céčka…

[Vinicius]

Muzu se zeptat jestli pouzivat QT-Designer? Ja jsem byl z kodu co vygeneroval vzdycky rozpacity. Jsou nejake alternativy ke QT designeru?

[Michal Kubeček]

Osobně si myslím, že faktorů je víc:

1. Rozšíření. Do nedávné doby se dalo říci, že linuxový (obecněji unixový) počítač bez překladače céčka je něco proti přírodě. O překladači C++ se tohle zdaleka říci nedá.
2. Kompatibilita. Použitelnost standardní C++ knihovny byla ještě nedávno na spoustě platforem včetně Linuxu velmi sporná. Taková libg++ byla často nestandardní, v horších případech navíc nefunkční. Teprve s příchodem trojkové řady GCC a libstdc++ se situace výrazně zlepšila.
3. Kvalita překladače. Zatímco překladač klasického céčka v GCC je poměrně kvalitní a spolehlivý, o překladači C++ se to bohužel příliš tvrdit nedá. U předčtyřkových verzí C++ kompilátoru se mi pravidelně dařilo generovat internal compiler error.
4. Síla zvyku. Přestože to tak na první pohled nevypadá, C++ je prostě jiný jazyk, není to jen C s pár přidanými vlastnostmi. Máte-li programovat skutečně v C++, a ne jen brát C++ jako C s doplněnými jednořádkovými komentáři (nadsázka), je potřeba začít myslet jinak. Na přirozené používání objektů a šablon je třeba si zvyknout a naopak si odvyknout spoustu věcí, které si navyknete v klasickém céčku. Kdo to neudělá, celkem pochopitelně dojde k závěru (který tu už i párkrát zazněl), že C++ nestojí za námahu, protože nic nepřináší a jen generuje méně efektivní kód (což ve skutečnosti není tak úplně pravda).
5. Knihovny. Většina podpůrných knihoven je pro klasické C, takže chcete-li je efektivně využívat v C++, potřebujete nad ně nějaký wrapper, který je ne vždy k dispozici a i když ano, nemusí být aktuální nebo stejně odladěný.

Nejspíš by se našly i další důvody, tohle jsou ty, které mne napadly.

[Jiří (BoodOk) Kadeřávek]

No, mozna v tom hraje roli i to, ze spousta lidi ma proste radeji stare dobre strukturovane programovani nez objektove eldorado (i kdyz to v C++ je jeste OK). Ale da se to zahrnout pod bod 4. (sila zvyku). Proste neco vyssiho nez assembler, ale neco, nad cim jeste maji perfektni kontrolu. Neco, co je potreba pro male ale mocne knihovny, nad kterymi se stavi dalsi kod, taktez v C.

[Honza Král]

videl bych to v tom, ze podle spousty programatoru (me nevyjimaje) je C++ paskvil, mnohem radsi neco napisu v C a mam v tom poradek nez v C++, kde se nvyznam a kdybych mel cist C++ po nekom jinem, zesilim z toho (samozrejme prehanim, i v C++ se da psat elegantne a ciste, ale to se da i v php a stejne je ten jazyk na vetsi projekty uplne nanic)

navic kdyz neco napisu v C++, da nejakou praci, aby to bylo pristupne z C, kdyz neco napisu v C, vcelk zadarmo to muzu pouzivat z C++

disclaimer: pisu s nadsazkou, nechytejte se kazdeho slova.. nicmene si stojim za tim, ze C++ (a hlavne PHP) je paskvil, ktery svadi k mnoha nerestem a 100% bych si je nevybral pro vetsi praci...

[Michal Kubeček]

Pokud se píše skutečně v C++, je obecně zdroják přehlednější než v C. Něco jiného samozřejmě je, pokud někdo používá C++ jen jako nadstavbu nad C. Nebo pokud je autor čuně, protože čuně píše čuňácké programy v jakémkoli jazyce; samozřejmě to platí i naopak, člověk s potřebnou sebekázní píše přehledně a srozumitelně v jakémkoli jazyce, ale v některých mu to dá víc práce.

Mimochodem, podívejte se třeba na datové struktury, které používají funkce knihovny libc pro práci se sockety a jejich adresami. Opravdu si myslíte, že tohle by v C++ nebylo výrazně přehlednější?

[Honza Král]

ano, mate pravdu - pravdepodobne by to bylo prehlednejsi, ale dalo by to mnohem vic prace to udrzet prehledne, aby se to nezvrtlo v neco jeste mnohem horsiho nez je to ted...

naprosto soouhlasim, ze "spravny programator"(TM) pise pekne, uhledne a elegantni programy v cemkoli, ale pravdou take je, ze nektere jazyky svadi (nekdo muze rict davaji prostor) ke "zvrhlostem" vice nez jine... to je duvod proc ja nemam rad C++ - priserna zmatenost jazyka a silene nepruhledne mechanismy

[Miloslav Ponkrác]

Bohužel Vám musím s lítostí sdělit, že prostor ke zvrhlostem je v každém programovacím jazyku. A pokud chcete jazyk, který nedává prostor ke zvrhlostem, respektive ho dává co nejmenší, tak absolutně nechápu, proč se zabýváte nějakým Céčkem?

Jazyky C/C++ jsou pro lidi, kteří ví co píší a hodlají mít trochu větší volnost, než tomu bývá jinde. Eventuálně pro lidi, kteří potřebují rychlost a pak jsou vlastně donuceni k C/C++. Díky volnosti C/C++ je zde prostor ke zvrhlostem daleko větší, než tomu bývá ve většině jiných programovacích jazycích. Pokud nevíte co píšete, tak v C i C++ to dopadne špatně.

Na druhé straně co oceňuji u C/C++ je vnitřní logika a konzistence obou jazyků. Řekněme, že C++ je možná trochu přeplácané, ale logicky postavené. Nevidím v něm žádnou zmatenost, ani šíleně neprůhledné mechanismy.

[Michal Kubeček]

Postupem času jsem dospěl k závěru, že jazyky, které se snaží přísnými pravidly zvrhlostem bránit, vedou pouze k tomu, že "zvrhlíci" vytvářejí zvrhlosti stejně, pouze jsou tyto v důsledku nutnosti obcházet obranné mechanismy jazyka podstatně rafinovanější a … prostě zvrhlejší. :-) Nemluvě o tom, že takový jazyk často nutí ke zvrhlostem i programátora, který by se ve volnějším jazyce choval slušně, protože by se s ním nemusel přetlačovat.

[Miloslav Ponkrác]

Naprosto souhlasím! Po dvaceti letech programátorské praxe vím, že "čisté" jazyky, které nedovolují žádnou zvrhlost a bojují proti nim všemi prostředky jsou jen pro zlost. A stejně se v nich zvrhlosti píšou dál, jen jinak.

[Luk]

Je pravda, že třeba Java je průhlednější než C++. Ale skutečně záleží hlavně na programátorovi, jak to udělá. Někdo provozuje skutečné orgie s přetěžováním operátorů a chlubí se, jak úsporný kód píše. Ale aby se v něm pak prase vyznalo. Mně je ovšem bližší takový javovský styl psaní kódu C++, tedy používat raději metody a na operátory se vykašlat (i když někdy je lepší tuto zásadu porušit).

[Miloslav Ponkrác]

viděl bych to tak, že spousta programátorů (mě nevyjímaje) považuje C za paskvil, mnohem radjěi napíše něco v C++. mám v tom větší pořádek, než v c.

navíc udělat něco přístupné z C, máte-li projekt v C++ není až tak veliký problém, ale nikdy se to po mě ještě nepožadovalo

disclaimer: píšu s nadsázkou, nechytejte se každého slova..nicméně si stojím za tím, že C je paskvil, který svádí k mnoha neřesten a 100% bych si je nevybral pro větší práci

a teď konec srandy. C++ je s námi relativně krátkou dobu, sice jsem v něm programoval před mnoha mnoha lety, ale standard C++ tu není zase tak dlouho a kompilátory vyhovující standardu C++ přišly ještě později. tudíž skutečně efektivní práce v C++ je tu poměrně krátkou dobu.

pokud někdo vezme C++ a začne ho používat jako C, tak celkem nenajde důvod, proč ho brát na vědomí. ale jakmile začnete poznávat efektivitu C++ a odnaučíte se ty blbiny, co vás nanutilo C, objevíte v C++ mnohem efektivnější nástroj. já osobně bych dnes větší projekt v C dělat nechtěl, ale v C++ bych do toho šel daleko raději.

C není nic jiného, než přenositelný stroják a tuhle low level úroveň programování už nechci zažít.

dalším důvodem je to, že Céčko je naprosto všude, ale C++ ne. tady by se hodil nějaký generický kompilátor z C++ do C a bylo by vystaráno, ale pokud vím, nic použitelného neexistuje.

C++ je složité na naučení, to je prostě fakt! C++ je nejsložitější jazyk na naučení, který jsem kdy poznal a to spoustu lidí odrazuje. trvá několik měsíců, než jej dokonale po všech stránkách zvládnete. Céčko je proti tomu jednoduchý jazyk, kde když přestanete zápasit s pointerama a vyhnete se několika málo záludnostem, tak lze vyžít.

C++ má mizernou knihovnu, to bohužel musím konstatovat. v objektové knihovně toho moc nenajdete, nepočítám-li nějaké ty generické algoritmy a datové struktury a proudy. zbytek se bastlí pomocí knihoven zděděných z Céčka. v knihovně není třeba typ datum, nejsou tam thready, není tam žádná podpora GUI, není tam skoro nic. a dnes dost často o úspěchu jazyka rozhoduje kvalita knihoven.

[springer]

C je paskvil, který svádí k mnoha neřesten a 100% bych si je nevybral pro větší práci

Céčko je proti tomu jednoduchý jazyk, kde když přestanete zápasit s pointerama a vyhnete se několika málo záludnostem, tak lze vyžít.

nejak se nemohu zbavit dojmu, ze si protirecite

[Miloslav Ponkrác]

kde si prosím Vás protiřečím?

[springer]

v tech dvou vetach, ktere jsem z vaseho prispevku odcitoval. Budto se u C jedna o jednoduchy jazyk, s kterym lze vyzit po zvladnuti nekolika zaludnosti, nebo je to paskvil?

[Michal Kubeček]

Nemyslím si, že se ty dvě věty vylučují. Tím ovšem netvrdím, že s oběma souhlasím, konkrétně si nemyslím, že je C paskvil. Spíš jazyk, který byl navržen v určité době k určitému účelu a který k tento účel splňuje velmi dobře, ale bylo by chybou považovat ho za něco výrazně odlišného.

[Miloslav Ponkrác]

ani já nepovažuji C za paskvil. ta věta, kde píšu, že C je paskvil je parafráze na stejnou větu napsanou o C++. pokud si všimnete, tak první tři odstavce jsem jen parafrázoval někoho jiného. pak jsem napsal konec srandy a začal jsem psát vážně.

C je velmi dobrý jazyk poplatný době, ve které byl stvořen. to nic ale nemění na faktu, že přestože jsem v čistém C psal řadu let (v době, kdy ještě neexistovalo C++), nechtěl bych se k tomu již vrátit.

co si ale na Céčku cením, že je jedním z nejlogičtějších a nejkonzistentnějších jazyků, které jsem za těch dvacet let poznal (spolu s C++). C/C++ staví na tom, že každá vlastnost jazyka dělá jen jednu konkrétní věc, a že každou vlastnost jazyka lze použít bez výjimek všude. pochopíte-li pár základních principů jazyka, máte vyhráno. takovou logiku u spoustu jazyků nenajdete. asi nejméně logický jazyk, který je plný výjimek a řešení přes ruku, který jsem zažil je Java.

[Heron]

který je plný výjimek a řešení přes ruku, který jsem zažil je Java.

Můžete, prosím, uvést nějaký konkrétní příklad? Znám jak C, C++, tak právě Javu (a spoustu jiných) a připadá mi, že jakmile jsem pochopil do hloubky sílu objektů, tak je pro mě programování v Javě daleko nejefekticnější. Malé prográmky nebo hračičky v OpenGL píšu v C.

[Miloslav Ponkrác]

klidně si řekněte jakoukoli konkrétní featuru v Javě a zjistíte, že je to nekonzistentní. já jsem nucen v Javě dost psát, takže můžu vyprávět. pokud objekty, tak třeba v Pythonu, nebo ve Smalltalku. i když ten Smalltalk je trochu pasé.

vezměte si jen takovou obyčejnou věc jako je řetězec v Javě.

Java je první a poslední programovací jazyk, který jsem viděl, kde operátor porovnání nezvládne porovnávat řetězce. v každém jiném programovacím jazyce operátor porovnání prostě porovnává hodnoty řetězců, zatímco v Javě nikoli (vynechávám Céčko, kde řetězec jako typ vůbec neexistuje a nahrazuje se polem). operátor porovnání vám prostě porovná, zda oba řetězce mají stejnou adresu, což je platné jako mrtvému zimník a ještě jsem nenatrefil na situaci, kdy by to bylo pro řetězce užitečné. jedné co to přitahuje jsou chyby, kdy na to člověk zapomene a pak se diví, proč to funguje jinak.

Java má zbytečně dvě třídy pro řetězce String a StringBuffer. Nutí tak programátora pohybovat se mezi dvěma třídami, které reprezentují totéž, zbytečně mezi nimi konvertovat, apod.. chápu mezi nimi rozdíl, ale existence dvou tříd pro řetězce je zbytečnost, kterou měl na sebe převzít kompilátor a nezatěžovat tím programátora. tento argument platí o to víc, že kompilátor občas svévolně mění operaci na třídě String za operaci na třídě StringBuffer, aniž by to ve zdrojovém kódu Javy bylo předepsáno.

Java neustále vykřikuje do světa, že operátory jsou větší zlo, než Hitler a atomová válka. Ale zavede operátor+ pro třídu String. to je nekonzistence jako prase. proč? a když už, proč nezavede operátor porovnání na porovnání hodnot, který by skutečně porovnával řetězce? a proč nezavede operátor+ i pro StringBuffer? prostě je to to nekonzistentní a je to další výjimka z pravidel jazyka, kteréhož je Java plná.

Java kóduje řetězce v utf-16 se všemi nevýhodami z toho vyplývajícími.

A to nemluvím o dalších věcech, na kterých jsem si naběhnul, když jsem před řadou let začínal v Javě, jako třeba zápis:

String a = "\u000D";

který skončil chybou unclosed string literal, než mi došlo, že Java to má dělané trochu nelogicky a neočekávaně.

a to jsem mluvil jen řetězcích. stejně tak bych mohl vzít cokoli jiného.

[Heron]

Aha. Upřímně, čekal jsem něco většího než kritiku Stringů.

Se Sting, StringBuilder a StringBuffer jsem se vyrovnal během 5 minut, nevím proč vám to tak vadí.

Co mi vadí víc (a to už i na C#) je to, že GarbageCollector má trochu výkonnostní problémy s velkým počtem (ve stovkách tisíc) objektů.

Ale úplně nejvíc mi vadí, že tam není vše objekt. Objakty se předávají odkazem (a tak to má být), ale třeba int se předává hodnotou. Kdyby byl int immutable object, jako třeba String, bylo by to imho konzistentnější.

[Miloslav Ponkrác]

mě to nevadí, pokud nemusím dělat v javě nejde o to, jestl se s tím člověk vyrovná, jen že je to nelogické a nekonzistentní. a příklad na tyhle věci jste ode mě chtěl a já posloužil.

nekonzistentnosti v javě jsou spíš pravidlem, než výjimkou a jsou na každém rohu.

přesto, že v javě je spousta neobjektových věcí, přesto nemají javisti problém s tím tvrdit, že je to nejlépe a nejvíce objektový jazyk. já už se tomu jenom směju.

java má vůbec problém hodnota versus odkaz. nedokázala tuhle věc nějak čistě a konzistentně vyřešit. pak začíná zavádět dvojici objektů - jeden jako konstantu, druhý jako měnitelný objekt. to ovšem nejde u všech tříd (a ne všude je to vhodné). dokonce díky tomu je v důsledku nutné alokovat v javě několikanásobně víc instancí, než v C++ (což se zpětně odráží i na gc a jeho problémech), protože mnohdy je nutné vytvořit nový objekt jen proto, aby nedošlo ke změně jiného už existujícího.

C# bohužel vznikl jako kopie Javy a zkopírovali někdy i totální kraviny z Javy, jako je třeba Unicode řetězec v utf-16 ála Java, nebo právě debilní manipulace se stringy (naštěstí operátory jdou přetypovat a u stringu se to provedlo) a spoustu dalších věcí.

[Heron]

Tak operátory do OOP imho nepatří a i když píšu třeba:

int x = 3;
int y = 4;
int z = x+y;

Tak by mi nevadilo psát:

Int x = new Int (3);
Int y = new Int (4);
Int z = new Int (x.add(y));

S tím, že Int by byl immutable objekt.

Tímto lze vyřešit všechny "nekonzistence". Existuje takový jazyk?

[Miloslav Ponkrác]

no, mě by tohle třeba vadilo. a pokud by int byl konstantní objekt, tak by to vedlo jenom k tomu, že by se dále zvýšil počet instancí v javě, žralo by to víc paměti, trochu víc by se zapotil gc atd.

když už byste chtěl být konzistentní, tak by to mělo vypadat v javě nějak takto:

Int x = 3; // 3 je literál typu class Int Int y = 4; Int z = x.add(y); // add vrátí nový objekt typu Int

ale ještě lépe takto:

Int z = 3.add(4);

ale slušné jazyky používají operátory:

Int z = 3 + 4;

java je snad jediný jazyk na světě, který se operátorům brání. já si to vysvětluji tak, že ředitel Sunu na škole dostal z operátorů nedostatečnou a teď má komplexy z operátorů. jinak si to nedokážu vysvětlit, protože žádný jiný jazyk, který znám se operátorům nebrání.

nekonzistence na 100% vyřešit nelze, ale počet nekonzistencí v javě je prostě několikanásobný oproti průměru jinde.

[Heron]

Hmm, to nevypadá špatně:

if (3.add(4).compareTo(7)) {
} else {
}

Sakra, ale nějaký jazyk mi to připomíná, nemůžu si vzpomenout...

Scheme také nemá operátory:

(+ 2 4 6 (- 7 8) (* 9 (/ 1 3)))

, kde +,-,*,/ jsou speciální formy. Podobně jako třeba define.

[Miloslav Ponkrác]

Ke Scheme je ještě setsakra daleko, i když moje oblíbená věta je, že stejně všichni jednou skončíme u Lispu.

Ale třeba tenhle zápis je prostě jediný správný pro skutečné objektové jazyky.

[Michal Kubeček]

Ano, skončíme, to je to správné slovo. Protože až budu okolnostmi donucen programovat v Lispu, bude to naprostý konec. Jeden pohled do ~/.emacs byl přesvědčivější než hodiny přednášek o výhodách vim… :-)

[Kyosuke]

Pozdě, ale musím: +, -, * a / jsou úplně normální procedury a rozhodně ne speciální formy. Takže ve Scheme je to v podstatě totéž, jako kdyby to v Javě byly předefinovatelné operátory.

[Marek Bernát]

A to slovíčko new má byť načo dobré?

[Heron]

Na to, že se vytvoří 6 objektů místo 3 . Jasně, pokud by literál 3 byl chápán jako instance objektu (což by měl, máte pravdu), tak by to šlo bez "new".

[Kyosuke]

Ano, operátory do OOP nepatří a právě proto má Smalltalk pouze metody – +, -, *, / a další...

[Michal Kubeček]

C# bohužel vznikl jako kopie Javy a zkopírovali někdy i totální kraviny z Javy, jako je třeba Unicode řetězec v utf-16 ála Java

IMHO tohle není podle Javy, ale proto, že UTF-16 používají ve Windows. Tedy často spíš používají UCS-2 a pro zmatení nepřítele mu říkají UTF-16… :-)

[Heron]

Sleduju zdejší diskusi o UTF-16 ve stringách, co by tam podle vás mělo být? Snad ne 7b ASCII. Podpora UNICODE být prostě musí. Co vám tedy přesně vadí na UTF-16?

[Miloslav Ponkrác]

To je nepochopení Unicode. Pro ilustraci: dnešní Unicode potřebuje ke své plné reprezentaci všech znaků 21 bitů. Tudíž snadno Vám dojde, že 2 bajty na znak, jak to má Java a C# je poněkud málo a musí se to dost nechutně kódovat způsobem, kdy některé znaky jsou uloženy jako jeden znak a některé znaky jako dva znaky. Je to dost nechutné a tomuhle kódování se říká utf-16 a přináší to zbytečné komplikace. U Javy je to řekněme pochopitelné, protože v době vzniku to nemohla vědět (i když kdyby byla Java skutečně objektová, jak se všude rádo tvrdí a znak byl objekt, tak by problémy neměla ani dnes), ale u C# je to diletantsví, protože v době vzniku už věděli, že 2 bajty na znak je málo.

[Michal Kubeček]

UTF-16 je kódování, které sdružuje téměř všechny nevýhody jednotlivých reprezentací Unicode: zabírá více místa než UTF-8, má proměnnou délku znaku a ještě ke všemu je endianness-dependent.

[Miloslav Ponkrác]

Myslím, že to je z Javy. Na celém konceptu .NETu je vidět to, že Javu přebrali i s chlupama.

[Kyosuke]

„C/C++ staví na tom, že každá vlastnost jazyka dělá jen jednu konkrétní věc, a že každou vlastnost jazyka lze použít bez výjimek všude pochopíte-li pár základních principů jazyka, máte vyhráno.“

Tak přesně tohle dělá Lisp a hlavně Scheme, s tím rozdílem, že Lisp je „meanie“ a C je „doie“. Zrovna nedávno jsem narazil na stránku, která to docela zajímavě rozebírala, včetně psychologie myšlení. Zřejmě jazyky s malým pružným jádrem (jako C a Scheme) mají svoje kouzlo...

[Michal Kubeček]

tady by se hodil nějaký generický kompilátor z C++ do C a bylo by vystaráno, ale pokud vím, nic použitelného neexistuje

Mám pocit, že jsem někde zaslechl (agentura JPP), že první překladače "překladačů" C++ byly ve skutečnosti preprocesory, které C++ překládaly na C, ale výsledek byl velmi neefektivní, takže v okamžiku, kdy se objevily nativní kompilátory C++, po konverzi z C++ do C se slehla zem. Ale možná je to jen takový folklór.

v objektové knihovně toho moc nenajdete, nepočítám-li nějaké ty generické algoritmy a datové struktury a proudy. zbytek se bastlí pomocí knihoven zděděných z Céčka. v knihovně není třeba typ datum, nejsou tam thready, není tam žádná podpora GUI, není tam skoro nic. a dnes dost často o úspěchu jazyka rozhoduje kvalita knihoven.

GUI bych do standardní C++ knihovny určitě necpal, nejsem si ani příliš jistý, jestli se nějaký univerzální koncept, zastřešující rozdílnou filosofii jednotlivých GUI, dá vůbec vytvořit. Co mi tam ale zoufale chybí, je standardní interface pro síťovou komunikaci, to považuji za asi největší nedostatek.

[Sinuhet]

Cfront

[Miloslav Ponkrác]

Ano, provním překladačem byl CFront, který překládal do C. Ale už se nevyvíjí, ani není jasná jeho licence a jeho vývoj skončil na tom, že nedokončil implmenntaci výjimek. O šablonách ani nemluvím.

Jenže každý úspěšný jazyk má GUI knihovnu. Klidně i několik. S tou sítí máte pravdu, chybí tam skoro všechno.

[Michal Kubeček]

první překladače "překladačů"

Pokud by to někomu nedávalo smysl (tak jako teď mně), tak tam mělo být první generace "překladačů".

[elviin]

pracuje se na tom: boost::asio

[Honza Král]

moc pekne :) asi jsem nevenoval C++ dost casu, treba jeste nekdy budu mit tu moznost a dam vam za pravdu... ;)

zatim kazdy s jazyku se kterym jsem se setkal jsem si vylozene po case prestal rozumnet, krome snad C, pythonu a haskellu (ale tomu jsem se bohuzel venoval jen velmi povrchne a pak jsem nenasel cas/chut/moznost v nem pokracovat)... asi si necham narust vlasy a vousy a naucim se LISP... ;)

[Ivanhoej]

Ked som sa ucil programovat zacinal som Basicom potom Pascal ale C ma natolko oslovilo, ze som pri nom uz ostal. Kupil som si knizku Programovanie v jazyku C od Brian Kernighan & Dennis M. Ritchie a celu som ju preluskal. Viack krat som sa snazil prejist na C++, ale po par hodinach som vzdy chytil odpor (moc zlozite). Nakoniec som zakotvil pri dvoch jazykoch C a Python. A dufam, ze si stym uz vystacim.

[rastos]

Práve včera som mal debatu s kolegom na príbuznú tému. Programuje už viac ako 10 rokov (koniec koncov ja tiež) a dospeli sme k názoru, že znovu-pužiteľnosť kódu ako koncept proste nefunguje. Teda ... ja si myslím, že funguje, keď kód píše dobrý programátor a na tento aspekt berie ohľad. Ale v praxi sa tak deje zriedka. Tým pádom jeden z hlavných dôvodov pre používanie C++ padá.

Po druhé: v dnešnej dobe "keď objekty tak Java". Ale keď človek porovná zápis:

float a,b;
FILE f=fopen("subor","r");
fscanf(f,"%f %f",&a,&b);

s ekvivalentnym zápisom v Jave, tak je to hrôza.

Na druhej strane som nedávno bol dokopaný napísať kus kódu (~50kB) s veľmi striktnou kontrolou chýb v C a tam by mi možnosť použiť exception handling ušetrila mnoho práce.

[Michal Kubeček]

Na druhou stranu, když to porovnám s

  float a, b;
  std::ifstream f("subor");
  f >> a >> b;

nevychází z toho C++ zase tak zle. A v okamžiku, kdy těch operací bude dvacet za sebou a bude potřeba doplnit zpracování chyb, začne mít C++ (díky výjimkám) výrazně navrch.

[Michal Kubeček]

Problém vidím, jak už jsem naznačil výše, spíš v tom, že řada programátorů bude sice formálně psát program v C++, ale ve skutečnosti to napíše stejně jako v tom céčku. Těm pak opravdu C++ nemá co nabídnout.

[elviin]

asi tak

[Miloslav Ponkrác]

to není zase tak úplně pravda

1) C++ jim nedovolí některé prasárny, které v C projdou. přeložit C zdroják C++ kompilátorem občas znamená se divit, které chyby člověk přehlédl a C kompilátor v pohodě vzal

2) C++ jim umožňuje používat další vlastnosti, které v C nejsou. můžou je objevovat postupně. koneckonců přesně takhle jsem se já C++ naučil.

[springer]

kdysi davno jsem cetl v knizce od Jacka Purduma (C Programmers Library 1984), ze nema cenu pouzivat float, protoze je to stejne interne prelozeno na double. Je to dnes stale jeste tak?

[Kyosuke]

A není to nějaký nesmysl? Tedy je pravda, že literál „3.14“ je typu double a pokud chcete single, musíte „3.14f“, ale když člověk řekne „float x;“, nechápu, jak by si mohl kompilátor dovolit mu odmlouvat.

[springer]

compiler neodmlouva,jenom (pry) do kodu vsune radu konverzi mezi float a double, nebot vsechny aritmeticke operace se provadi s "dvojnasobnou" presnosti. Samozrejme ma float smysl tehdy, jestlize si chci uschovat pri nejakych maticovych vypoctech miliardy desetinych cisel a tam je uspora 2 bytu pro cislo jiz asi znat. Ale beznme to pry nema cenu.

[Kyosuke]

Všechny FPU operace se na x86 provádějí s extended přesností prostě proto, že to tak je v hardwaru. Teprv FLD/FST/FSTP načítají nebo ukládají 4, 8 nebo 10 bajtů. Řadu konverzí nevkládá kompilátor, ale Intel... Maximálně tam může být nějaké zaokrouhlování po operaci (nastavitelné v řídicím slově FPU), ale to je směrem dolů, ne nahoru. Teda alespoň takhle jsem si to zatím představoval. Hmm, nějaký x86 FPU expert poblíž?

[Miloslav Ponkrác]

všechny výpočty uvnitř reálné jednotky x86 se provádějí ve tvaru 80-bitového čísla ve formátu IEEE. nemusí se ovšem počítat s maximální přesností, pokud nastavíte v FPU nižší přesnost, výpočet skončí dříve (alespoň teoreticky), není to tedy žádné zaokrouhlování, či osekávání až po výpočtu, jak tvrdíte. konverze mezi vstupními a výstupními formáty do 80-bitového formátu provádí sama FPU pomocí strojových instrukcí.

nicméně je nutné říci, že kompilátor pro x86 čistě teoreticky nemusí pro výpočet použít standardní FPU jednotku! může třeba počítat reálná čísla pomocí SIMD instrukcí a počítat třeba 4 výpočty naráz! takže bacha na to! a tady platí, že výpočtů s kratším reálným číslem (třeba floatem) udělá v jednom taktu více, takže (čistě teoreticky) chytrý kompilátor vám při vhodném použití floatů udělá mnohem rychlejší kód, než při použití double.

i když pravda takové optimalizace se asi setkáme možná jen u Intel kompilátorů. u gcc si vůbec o optimalizaci nedělám iluze.

takže nedělejte žádné závěry ohledně toho, co kompilátor používá vnitřně a nechte to na něm.

[Kyosuke]

Čistě teoreticky můžu Cčko nechat běžet na papíře a pak jediné, na čem mi záleží, je sémantika jazyka. Samozřejmě jsem měl na mysli FPU jednotku, ale v případě GCC jsem až do zapnutí experimentálního ssa-tree vektorizéru žádné zrychlení z vektorizace nepocítil. Pokud vím, GCC zatím používá v režimu -mfpmath=sse jen skalární SSE operace.

A že to není zaokrouhlování? Nevím, proč by to mělo skončit dříve nebo rychleji, pokud to není nějak mikrokódované nebo sekvencované, o čemž v dnešní době pochybuji – alespoň u části FPU instrukční sady, o 8087 radši uvažovat nebudu. . Někde jsem našel informaci, že přepnutím x87 FPU do single-precision režimu se urychlí jen fdiv a fsqrt, a to se týkalo Pentia II. S pokračujícím hardwiringem operací do pevné logiky se mi tomu dnes chce věřit ještě míň. Výkonnostní boost při použití singlu (v FPU) je spíš záležitost přístupu do paměti a cache, nebo alespoň nevím o jiném důvodu. Otázka je, Jak člověk intepretuje termín „po výpočtu“. Když z se hradel logiky výpočtu šíří signál do hradel registru a část ho neprojde nebo je ještě pozměněna, je to „zaokrouhlení po výpočtu“ nebo „zaokrouhlení při výpočtu“?

Asi se budu muset ponořit do dokumentace od AMD, co ji mám staženou. Nasadil jste mi brouka do hlavy.

[Miloslav Ponkrác]

tady je to klasický konflikt interface versus implementace.

prostě FPU na x86 má jako interface dáno, že mu nastavíte požadovanou přesnot výpočtu. implementace je vnitřní záležitost procesoru a některé z nich informaci o přesnosti využívají k předčasnému ukončení výpočtu, je-li dosažena požadovaná přesnost, a jiné to nepoužívají. dokonce to FPU může využívat jen někdy a jen u některých funkcí. to, že se ponoříte do nějaké dokumentace od AMD, kde je popisována _jedna_ _konkrétní_ _implementace_ nic neřeší. pokud chcete napsat nejrychlejší možný kód, tak prostě nastavíte přesnost, kterou potřebujete, protože takto funguje "interface FPU" a víte, že jste udělal to nejlepší pro maximální rychlost. a třeba Pentium VIII vydané v roce 2010 může informaci o nižší přesnosti využít způsobem, který pětkrát zrychlí výpočet. stejně tak vím, že mnohé procesory tuto informaci skutečně využívaly k rychlejšímu výpočtu. prostě dodržujte interface, který takto funguje, to je celé. implementační detaily jednoho současného procesoru nic neznamenají.

to samé gcc. gcc stále generuje horší kód, než kompilátor z MS Visual C/C++ 6.0, který jsem pořídil v roce 1996. už jsem psal, že si o jeho optimalizacích nedělám iluze. jako vzor optimalizací je gcc hodně špatný příklad.

[zde]

No, ony ty x86 procesory jsou dosti šílená architektura. Od dob kdy násobení ve floatech začalo být rychlejší než v integerech je možné úplně všecko :(

[Luk]

Záleží na kompilátoru a na platformě. Obecně to rozhodně neplatí (teď si nejsem úplně jistý, ale mám dojem, že GCC pro procesor Intel používá: sizeof(float)=32, sizeof(double)=64 a sizeof(long double)=80).

[Luk]

Grrr... Měl bych si to po sobě přečíst. Samozřejmě: sizeof(float)=4, sizeof(double)=8 a sizeof(long double)=16. S tím, že u long double se používá jen 80 bitů.

[Miloslav Ponkrác]

to je samozřejmě naprostá blbost. float a double jsou dva různé typy, které mohou, ale nemusejí být totožné. třeba na x86 procesorech je float 4 bajty dlouhé plovoucí číslo a double je 8 bajtů dlouhé plovoucí číslo.

v striktním Céčku samozřejmě existuje matematická knihovna jen pro práci s double (nepočítám-li C99), takže voláte-li třeba sinus, pak stejně dojde ke konverzi do double a zpět. ale v C++ je to řešené rozumněji, tam se prostě s float pracuje jako s float i v knihovnách.

[zde]

Protože C++ saje, a už to prosím neřešte.

[zde]

Co říká na C++ Linus? http://www.tux.org/lkml/#s15-3

In fact, in Linux we did try C++ once already, back in 1992. It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA. The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed:

* the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels.

* any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.

* you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++.

In general, I'd say that anybody who designs his kernel modules for C++ is either

* (a) looking for problems

* (b) a C++ bigot that can't see what he is writing is really just C anyway

* (c) was given an assignment in CS class to do so.

Feel free to make up (d).

[Michal Kubeček]

Pomineme-li věci, které jsou výrazem čistě subjektivní averze, a to, co už dávno není pravda, zůstanou pouze důvody specifické pro kernel. Co to vypovídá o psaní aplikací v C++?

[zde]

Kernel se od aplikačniho kódu neliší nijak podstatně, v podstatě hlavní rozdíl je pouze v tom že kernel má na kvalitu kódu VYŠŠÍ požadavky než userspace. To znamená že to co platí pro kernel, platí TAKÉ pro aplikace, jen je mnohem snadnější to porušit.

[Miloslav Ponkrác]

Tady bych se hádal. Kernel nemá vyšší požadavky, než userspace. To je naprostá blbost. Kernel má naprosto stejné požadavky jako userspace. Možná, že v user space se neřeší některé procesor specific věci, ale ty se stejně píšou v asm.

[Miloslav Ponkrác]

to ovšem neznamená, že Linux musí mít nutně pravdu

1) Windows při programování jádra zavedli výjimky jako standardní způsob ošetřování chyb v jádře - poté, co jsem se s tím seznámil to považuji za jeden z nejlepších nápadů, který jsem kdy viděl

2) klidně se dá používat C++ a nepoužívat výjimky - to že Linus C++ neumí a nezvládá není problém C++, ale Linuse. já se taky nevyjadřuji k tomu co neumím, ale Linusovi asi chybí sebereflexe

3) to samé s alokací. C++ neskrývá žádné alokační věci, alespoň jsem si nevšiml a to s C++ dělám zhruba od roku 1991. lze používat malloc/realloc/free, nebo new/delete. ani jedno z těchto věcí nic neskrývá, dokonce new/delete si můžete napsat vlastní, což je pro kernel ideální volba. opět se musím vyjádřit k tomu, že Linus je člověk, který se vyjadřuje k tomu, čemu nerozumí.

4) OOP se dá psát v každém jazyce, klidně i ve strojáku. OOP není nic jiného, než metodika. ale v C++ je to přeci jen kapku příjemnější, protože C++ má na to prostředky.

5) existují kernely operačních systémů, které byly napsány v C++ a problémy popisované Linusem se neprojevily. čím dál více věcí kolem operačních systémů se píše v C++ (někdy i osekaném), protože výsledkem je mnohem čistější, udržovatelnější a přehlednější kód, který přitom neztrácí žádné výhody Céčka. výsledkem použití C++ jsou prakticky jen výhody - to jsou výsledky skutečného použití C++. a tyhle výsledky jsou pro mě relevantnější, než bláboly Linuse, který s tím nemá žádné zkušenosti.

[Kyosuke]

Je zvláštní, že i přesto, že měl tyto výhody, byl systémový jazyk Bliss, na který mnozí PDPčkaři rádi vzpomínají, ošklivě zabit Cčkem. Ale možná teď přijde jiná doba... Bohužel ne blissová, pokud se nenajde nějaká banda fanatiků.

[Miloslav Ponkrác]

v google jsem našel jen Bliss, the premature baby charity, to asi nebude ono, že?

[Kyosuke]

Staří projevit Mozek++ a použít "bliss language"...

[pp_jj]

to ovšem neznamená, že Linux musí mít nutně pravdu

A stejně je to Linus

[happy barney]

ad 2) pouzivanie vynimiek bolo ruskou ruletou v podobe minimalne "Segmentation violation"

mne osobne jedine co na C++ vadilo, bolo nejednotne generovanie symbolov, kazdy kompilator si ich generoval podla seba. a tym padom jedina rozumna komunikacia kniznic bola cez extern "C", co nie je to prave orechove.

[zde]

C++ je plné ojebávek. Prakticky každou výtku proti němu jde nějak obejít, ale otázkou je jaký smysl má používat jazyk, který je třeba šíleným způsobem ohýbat, aby dělal triviání věci. Kdysi jsem v C++ taky programoval, a myslím že docela dost. Těch idiotských omezení je spousta, a prostě NEMÁ SMYSL je soustavně obcházet.

- nelze mít vlastní alokátor (malloc, zone, ...) a vytvářet v něm objekty- je třeba přetěžovat operátory new/delete což je hodně přes ruku.

- nelze vzít adresu konstruktoru. Díky tomu jsou věci jako serializace nebo cokoliv s dynamickou registrací tříd zbytečně komplikované.

- implicitní copy constructory- obvykle působí víc škody než užitku, obvykle se volá kdy nemá.

- implicitní přístup k instančním proměnným- činí čtení kódu bez předchozího podrobného detektivního nastudování všech headerů téměř nemožné.

- "template bomby"- díky špatnému odlišení deklarace třídy a její implementace se každý template a každá VMT instancuje (pro jistotu) do každého object file, a pak se to pokouší (s různým úspěchem) mergovat linker. Děkuji, nechci. Pěkně je to rozebráno tady: What's wrong with C++ templates?

- nestandardní formát objektů (kde je VMT pointer?, jaký je její layout? Jaké indexy mají jednotlivé metody? Jak se řeší virtuální MI?)

- nestandardní name mangling (který se navíc mění pomalu s každou verzí Gcc).

Prostě je to SHIT, SHIT, SHIT, a já už nikdy žádný projekt v C++ nevezmu.

[Miloslav Ponkrác]

Já Vám prozradím jednu věc, prakticky každý programovací jazyk je plný ojebávek. Ukažte mi jeden, kde nemusíte nikdy nic obcházet.

1) alokátorů můžete mít kolik chcete. a pokud máte nějaké speciální požadavky na to, jak vytvářet objekty, řeší se to ve všech programovacích jazycích použitím návrhového vzoru ála ClassFactory, a je jedno, jestli se bavíme o C++, Javě, či dalších

2) nelze vzít adresu konstruktoru, protože konstruktor toho dělá mnohem více, než máte předepsáno v kódu. pak pochopíte, že jeho přímým použitím by se nadělalo víc škody, než užitku. neznám dobrý programovací jazyk, kde byste mohl přímo získat adresu konstruktoru. každý z nich si hlídá, aby konstruktor bylo možné zavolal jen v určitých přesně definovaných případech. pokud by Vám dovolil operovat s adresou konstruktoru a volat kdy se Vám namane, tak vytvoříte tak strašné chyby, že je budete hledat až do konání světa. znovu připomínám, že konstruktor je platform and compiler and config_of_compiler depended. na druhé straně Vám C++ nijak nebrání a umožňuje Vám přímé volání konstruktoru na Vámi předaném bloku paměti. a pokud Vám to nestačí, viz návrhový vzor ClassFactory, což je správná cesta v objektivém programování

3) implicitní copy constructor lze jednak zakázat, a jednak se nevytvoří vždy.

4) instanční proměnné - nerozumím přesně, co chcete říci

5) template se nevloží do každého object file, to je naprostá blbost. vloží se jen to, co je využito. Navíc template může, ale nemusí řešit linker, některé kompilátory ukládají temlaty do zvláštního repository, které se pak spolu s objektovými soubory slinkují. Pak jsou instance šablon v kódu jen jednou. Tomuto řešení se říká CFront model.

6) nestandardní formát objektů vám vadí? proboha ukažte mi programovací jazyk, kde máte zaručený nějaký standardní formát objektů! do nějakýho VM pointeru, či offsetu položek nemáte co sahat! to není Vaše starost! ve skutečnosti v žádném programovacím jazyce nemáte zaručen ani standardní formát celočíselné hodnoty! natož objektů! chápejte, že objekty nejsou pole bajtů, do kterého byste měl sahat! nejsme ve strojáku, aby bylo jasno.

7) mám pocit, že gcc to mění právě proto, aby dostála nějakému standardnímu name decoration způsobu.

[zde]

1) Class factory je extémně blbá metoda, bohužel doporučovaná pomalu v každém C++ textooku. Blbá proto protože separátní freelisty akorát fragmentují paměť. Průměrná malloc/free knihovna je mnohem efektivnější.

2) Ano, volá parent kontruktory a nastavuje VMT, v blbých implementacích i alokuje paměť. Proč bych ho ale nemohl volat přímo? Adresu konstruktoru vezmu snadno v C, Javě i C# tak proč ne v C++?

4) Tím myslím že když v kódu vidím

hovnocuc = 1

tak nepoznám jestli je to globální proměnná nebo jde o

this->hovnocuc

. Explicitní 'self' nebo 'this' je mnohem lepší.

5) Vloží se to co je využito. Ovšem když stejnou věc využiju v deseti modulech, je to tam desetkrát. Ten druhý model je sice hezký ale prakticky všichni jedou podle toho prvního.

6) Jak chcete například v C++ (efektivně) implementovat wrapper, který před a po volání každé (z několika desítek nebo stovek) virtuálních metod nějaké třídy něco jiného zavolá? Nebo jak uděláte delagaci.. Nebo chcete volat metodu, kterou určíte teprve za runtime ze seznamu metod se stejnou signaturou.. Prostě sáhnout do VMT na správný offset je nejčistší řešení, přesto to jazyk vůbec nepodporuje. Member pointers jsou proti tomu zoufale neefektivní.

7) nevím a je mi to jedno. C++ mi na disk ani do domu nesmí :)

[Miloslav Ponkrác]

1) Pokud Vám záleží na efektivitě alokace, není nic jednoduššího, než si si sám napsat co potřebujete. C++ je jedním z mála jazyků, který Vám to umožňuje. Takže ClassFactory klidně se super efektivní alokací je možné.

2) Konstruktor v C++ přímo volat lze! To už jsem Vám přeci napsal. Jinak mi prosím předvěďte, jak získáte adresu konstruktoru v Javě, nebo C#. Vrcholně by mě to zajímalo.

4) Tak si tam to explicitní this prostě pište, ne? Ve většině projektů, kterých jsem se zúčastnil se tohle řešilo pomocí konvencí. Takže Microsoft začíná všechny datové členy názvem m_ a u největších machrů v C++ jsem viděl, že se ustálilo končit datové členy podtržítkem. Takže třeba x_ = 3 dává najevo, že jde o datový člen. U globálních proměnných píšu bez výjimky g_ a u statických s_ a u thread proměnných píšu t_. Bohatě to stačí.

5) A pak se to slinkuje a je to tam jednou.

6) Postupně: Napíšu wrapper pro celou třídu. Budu-li chtít určovat, kterou metodu ze seznamu chci volat, nebudu sahat na VM, ale pokud je počet možností malý, udělám několik tříd s jedním předkem. Pokud je seznam tříd velký, holt budu mít pole (klidně member) pointerů (efektivnější, než VM, věřte mi). Ale ze všeho nejspíš sáhnu ke třetí metodě a to uvědomím si, že mám špatný návrh datových struktur celého programu pokud toto chci využívat ve větší míře.

7) To je samozřejmě Vaše volba. Já jsem děvka prodejná, a když mi dobře zaplatíte budu pro Vás psát v jakémkoli jazyce Ale pokud si můžu vybrat, tak C++ bude jedna z voleb, kteoru upřednostním.

[happy barney]

ad 4) v tom je lepsi sposob pouzivany v Jave

class Global {
  static public int i;
};

no a ako v kazdej diskusii o C++, neda mi nespomenut gotw

[zde]

1) Teď už alespoň částečně ano. Ale myslím že původně do new() posílat dodatečné argumenty při volání konstruktoru nešlo; určitě to alespoň nebylo dokumentováno. Navíc super efektivní (tj stejně efektivní jako v C) to stejně nikdy nebude; věci jako částečnou inicializaci recyklovaných objektů (tj neinicializovat VMT ptr, refcounty, zámky, atd) o kterých víte v jakém stavu se nacházejí v C++ nikdy nedocílíte; ten konstruktor bude postě vždy dělat vše, a protože to dělá skrytě, nikdy to neovlivníte.

2) Viz jiný můj příspěvek. Prostě mi vadí že C++ neumí dynamicky vybrat třídu, aniž bych předtím musel konstruktor každé třídy owrapovat, přestože kdekoliv jinde to jde. Když budu mít konstruktory prázdné nebo přesunuté do regulérní metody a inlinované tak je to sice vyjde prakticky zadarmo, ale opět jde o to trapné obcházení něčeho, co bylo špatně navrženo.

4) Ok

5) Jak kdy. Pokud ty objecty jen naskládáte do statické knihovny, tak to tam furt zbude duplicitně.

6) Nepochopil jsem. Ještě jednou prosím. Uvažuji dejmetomu prostou delegaci- tj jeden objekt nabízí dejmetomu 50 metod, a dispatchuje je do metod některého svého subclassu, reference na jehož instanci je známa až za runtime.. Podle mne je toto v C++ bez copy-paste všech 50 metod nerealizovatelné. Kdybych to samé dělal v C, tak si metody snadno očísluji (což musím tak jak tak a dělá to i C++), a proženu přes jeden dispatcher. V C++ to ale nejde, protože ta enumerace je nesmyslně v době překladu nedostupná.

7) To já taky, ale za "C++" bych potřeboval minimálně jednu nulu navíc. Naštěstí existují jedinci s menším prahem bolesti

[Miloslav Ponkrác]

ad 1) Myslet znamená <censored> vědět. Do new() lze posílat dodatečné parametry od té doby, co má C++ standard. Nechtějte, abych Vám připomenul, co nešlo v původním C, než mělo ANSI standard, byl by to velmi dlouhý výčet. Cokoli jde v C, jde i v C++. Jde-li něco v C "super efektivně", jde to i v C++. Tečka. Pokud myslíte, že ne, dokažte mi opak. Pokud chcete programovat super efektivně, doporučil bych Vám strojový kód. Cokoli jiného je totiž už ústupek efektivitě, a to Vy přeci nechcete, ne? Já raději volím prostředky, které jsou možná o 1% pomalejší v běhu, než "super efektivní" řešení, ale napíšu je za tisícinu času a udělám v tom miliónkát míň chyb.

ad 2) Otázkou je, jestli to co chcete je užitečné a jak často to je potřeba. Mimochodem, sám jste navrhnul řešení. Jinak Vaše tvrzení, že "kdekoli jinde to jde" se diplomaticky řečeno nezakládá na pravdě.

ad 6) Pokud dokážete něco napsat v C, jde to napsat i v C++. Napíšete-li větu, kde uvedete řešení v C, můžete to stejně použít v C++. Jinak přesně nechápu, co chcete dokázat, bodl by naprosto konkrétní příklad.

[I love M$]

Na ty adresy konstruktorů v Javě a C# bych se také zeptal, už jen proto, že třeba takový C# se tváří jakože žádné ukazatele nejsou a ikdyž mu jdou povolit, tak pro program kde chci pracovat s ukazateli bych si teda C# opravdu nevybral. Celkově mi příjde že řešíte věci, ke kterým přistupovat snad jedině tehdy, když potřebuju vyždímat maximum výkonu, a znovu tedy proto bych si nevybral něco co běží na run-timu či frameworku. I kdybych získal adresu konstruktoru tak co s ní v C#.Pokud si chci hrát z databázemi na Windows, tak je C# v kombinaci s ADO možná to nejlepší (samozřejmě je dobrý nejen na to), ale pokud si chci trochu hrát s pamětí a mít ji trochu "v ruce" a zároveň psát objektově ale "nízkoúrovňově", tak je (podle mého názoru) C++ to nejlepší vůbec. Hlavně mi přijde, že věci, které popisujete jsou pro C# trošičku husarské kousky. Navíc osobně považuji za výhodu, že C++ je jazyk hybridní, tedy že mohu kombinovat objekty s globálními proměnnými/funkcemi což mi třeba u C# docela chybí.

tak nepoznám jestli je to globální proměnná

Ktomu přeci slouží štábní kultura.

ad 5) již popsal kolega, jen mě napadá, jestli má cenu se tím tolik zabývat. Já osobně považuji za nejdůležitější to, jestli to chodí (a jak rychle). Když si překládám svoje gamesy v gcc a následně intelem a zjišťuju, že binárka od intelu je o 15% rychlejší tak je mi fakt jedno, že má místo 1,7MB přes 2MB a že tam třeba linker něco zapoměl oříznout - něco co se nepoužije nebo je to tam zbytečně vícekrát, ani po tom nepátrám. Ať se do toho "exáče" Intel třeba podepíše, stejně jsou to na dnešních discích směšné velikosti a v tempech i v Linuxu natož ve Windows mám 1000* víc bordelu.

[zde]

Na ty adresy konstruktorů v Javě a C# bych se také zeptal

Java i C# mají něco jako new(String s), tj jméno třídy je známo až za runtime. Samozřejmě že v C++ můžu ty konstruktory owrapovat do normálních funkcí, a ty zaregistrovat v nějakém seznamu/slovníku, ovšem ten wrapper mi přijde zbytečný. Dynamicky typované jazyky každou referenci na třídu považují za normální hodnotu s kterou lze libovolně pracovat, jen C++ se tváří že nic takového jako class-as-value neexistuje, přestože tak interně funguje. Dokonce i Delphi byl o třídu lepší design než nepoužitelné C++.

a že tam třeba linker něco zapoměl oříznout

On to linker v praxi ořízne jak má. Ale má s tím zbytečně moc práce, potřebuje být kompatibilní s různými úchylnými extenzemi ELF formátu, a potřebujete mít aktuální celý toolchain který to kompatibilním způsobem podporuje- prostě spousta zbytečných závislostí; vše jen proto že hloupé C++ se nenamáhá generovat metadata do samostatného objektu, protože se před programátorem snaží usilovně skrývat že něco takového vůbec existuje. C++ = Mor a cholera.

[Miloslav Ponkrác]

Helejte, buď přiznejte, že nenávidíte C++, ale přestaňte lhát.

Jméno třídy v Javě musí být známo už při kompilaci, pokud nepoužíváte reflexi, a tu jste nepoužil. C++ dokáže ekvivalentně to stejné. Takže přestaňte lakovat. Ano Java, ani C#, ani C++ není dynamicky typovaný jazyk, takže se přestaňte ohánět dynamicky typovanými jazyky a raději si dejte panáka, ať se uklidníte.

Delphi a jeho objekty byla jedna z nejhorších věcí, kterým jsem se bohužel musel věnovat. Nikdy předtím ani potom jsem nemusel kompilátor víc hlídat v objektech, než právě u Delphi. Když jsem mu neřekl, klidně si nezavolal konstruktor, nebo si zavolal konstruktor předka, aniž by mu to nějak přišlo divný. Takže Delphi jako vzor si strčtě za klobouk.

Prostě rovnou napište, že nenávidíte v C++, ale přestaňte se ztrapňovat argumenty, které Vás jen ukazují jako diletanta v C++.

[Miloslav Ponkrác]

A vidíte, Windows výjimky v jádře úspěšně používají a dávají k dispozici i programům tyto výjimky zachytávat a používat. Díky tomu tyhle výjimky Microsoft přenesl i do jazyka C (bohužel gcc to na Windows nepodporuje) a je to jedna z nejlepších věcí,které jsem od Microsoftu viděl. Spousta problémů se výjimkami v jádře zjednodušila.

Nejednotné generování symbolů mi v C++ taky vadilo. Ale ani jednotné symboly by přenositelnost mezi kompilátory nezaručila.

[happy barney]

njn, ja som pod windos vlastne ani neprogramoval, v casoch ked som zacinal mi z porovnania winapi/xlib jednoznacne vyslo, co je zaujimavejsie

no a skoncil som v perli )

[Luk]

Spíš bych jako hlavní skutečnou překážku použití C++ v jádře viděl problémy kompilátoru. I když to už je také prakticky minulostí.

[zde]

No, v několika (ale opravdu jen několika) případech se mi C++ docela líbí. Například vestavěná dědičnost v C++ je nepatrně lepší než užívání #define typu:

#define _PyObject_HEAD_EXTRA            \
        struct _object *_ob_next;       \
        struct _object *_ob_prev;

#define PyObject_HEAD                   \
        _PyObject_HEAD_EXTRA            \
        int ob_refcnt;                  \
        struct _typeobject *ob_type;

#define PyObject_VAR_HEAD               \
        PyObject_HEAD                   \
        int ob_size;

typedef struct {
    PyObject_VAR_HEAD
    PyObject **ob_item;
} PyListObject;

Ale fakt je že spousta magorů by začala používat blbosti jako přetěžování (když je to jiná funkce, tak to jinak pojmenuj, pitomče!), RTTI (jak se to vypíná? nechceme žádné hidden members!), výjimky, atd, takže je lepší zůstat u C.

[Miloslav Ponkrác]

Přetěžování je ideální tam, kde stejnou činnost vykonáváte nad odlišným seznamem parametrů. Přetěžování je velice přirozené a nenajdete programovací jazyk, kde by přetěžování nebylo využito. Chybou je, pokud je stejný název pro různé činnosti, pak je to špatné.

RTTI - C++ má bohužel slabé RTTI, uvítal bych jeho rozšíření. Sám ve svých projektem jsem si musel napsat rozšíření RTTI. jinak RTTI samozřejmě vypnout jde.

výjimky - bez nich ani ránu. jazyk bez výjimek je pro mě jazyk, který mě nezajímá. naštěstí jsem už několik let nemusel žádný takový jazyk pooužívat.

[zde]

Přetěžování je moc fuj a ošklivá věc, protože pokud přetěžujete dejmetomu foo(), tak při vcelku běžných zápisech typu

foo(bar(0))

nevidíte bez dohledání typu návratové hodnoty funkce bar(), která verze foo() se vlastně bude volat, přestože ta vazba je plně statická.

Zatímco zdrojáky v C se dají normálně číst, v C++ se obvykle musí luštit, a neustále přitom grep-ovat headery. Tohle samotné je ohromná nevýhoda, a těch pár výhod které C++ přináší ji imho dostatečně nevyvažuje.

Přetěžování je velice přirozené a nenajdete programovací jazyk, kde by nebylo

Dynamicky typované jazyky nic takového nepotřebují a nemají. Staticky typované jazyky jako Java nebo C# to mají jen pro normální funkce (ne operátory), a podle mne pouze z historických důvodů- relativně snadno se to implementuje, ve spojení s manglingem to "zadarmo" dává typovou kontrolu v link-time, a v dobách začátků objektového programování se za to asi dával nějaký nepodstatný plus bod, takže to tam všichni přidali, přestože jde o blbost. S tím jestli je to potřebné nebo užitečné to ale nijak nesouvisí.

Pokud jste psal rozšíření RTTI, jak se vám to povedlo udělat portabilně, když formát RTTI dat není standardizován, ani de facto stabilizován? Není lepší RTTI vypnout a implementovat si nějaké tagování objektů plně ve vlastní režii, nebo ještě lépe vzít jen čisté C?

výjimky- ten samý problém. Je sice hezké že mám strukturované výjimky, a že se mi samy volají destruktory při stack unwindingu. Ale když chci například za běhu vypisovat call chain a aktivní exception handlery pro daný thread [což je zcela normální a legitimní věc a, C++ má veškerá data aby to umožnilo] opět narazím, protože portabilně to nejde, a formát tabulek není standadizován ani stabilizován.

C++ zkrátka všechno udělá "napůl"- buď je featura principielně zcestná (přetěžování, private members, implicitní this, zmršené konstruktory) nebo je sice užitečná, ovšem nejde ji portabilně použít naplno.

[Miloslav Ponkrác]

Pokud chcete mít pořádek ve foo(bar()), pak to klidně pište jako foo(dynamic_cast<typ>(bar()), případně v Céčkovém stylu foo((typ)bar()). Budete to vidět na první pohled bez dohledání návratového typu funkce bar(). Přetěžování je velmi přehledné, pokud se drží rozumně a velmi přirozené. A jak říkám, přetěžování je v každém jazyce. Takový operátor sizeof je třeba v Céčku de facto přetížený pro každý typ. Operátor + máte v Céčku přetížený pro mnoho typů. A třeba funkce printf() je de facto jen jinak realizovaná přetížená funkce, která může přijmout mnoho různých počtů a typů argumentů.

Dynamicky typované jazyky většinou nic takového nemají, protože je tam ta beztypovost. Ale to neznamená, že to přetěžování nemají všechny dynamické jazyky. Navíc přetížení funkcí se v každém dynamickém jazyce dá zrealizovat, prostě zjistíte typy předaných parametrů a rozvětvíte kód podle zjištěných typů. Jinak řečeno, dynamicky typované jazyky mají prostředky jak přetížení funkcí zrealizovat a dost často se také tak děje. Takže Vaše teze o tom, že dynamicky typované jazyky to nemají, tak pravda je, že to mají implicitně. To v Céčku na uživatelské úrovni nemůžete ani to.

Přetěžování funkcí a operátorů se děje odjakživa a v každém jazyce. V Pascalu máte funkci abs, která Vám dává absolutní hodnotu čísla stejného typu, jaký vstoupil, například. Už to je příklad klasického přetěžování funkce. Jediným pokrokem, který se udál je, že se jazyky jako je C++, C#, Ada a další naučily tuto možnost přetěžování funkce dát i programátorovi.

Ad RTTI - nepotřebujete portabilní formát, stačí Vám, když se zamyslíte co je portabilního. A zjistíte, že je portabilní interface k RTTI.

Ne, čisté C není lepší, než C++, protože jak už jsem psal, psal jsem v čistém C mnoho let ještě v době, kdy C++ neexistovalo, a tuhle low level úroveň programování už nechci zažít. C není nic jiného, než přenositelný stroják. Céčko nemá nic, nemá ani pořádnou práci s řetězci, s datovými strukturami, a mnoho dalších věcí, které ocení každý, kdo se pozvedl nad úroveň strojového jazyka. Jinak pokud Vás to zajímá, umím velmi dobře i v assembleru, ale používám to zřídka, právě ze stejných praktických důvodů, jako velmi zřídka používám Céčko.

Výjimky - zajímavé je, že se tu sešlo spousta zasánců Céčka, kteří po C++ najednou nutně potřebují po C++ věci, které spousta vynikajících programátorů v C++ nikdy nepostrádala. Jeden tu chtěl znát bajtovou strukturu objektu, Vy zase speciality ve výjimkách. Nikdy jsem to nepotřeboval. Bylo by to sice hezké, ale pokud to budu chtít, tak buď vím, že gcc má rozšíření, které mi leccos z toho umožňuje, nebo že (pokud budu ve Windows) výjimky ve Windows jsou postaveny na výjimkách kernelu Windows, které mají standardní a předepsaný formát, a ve Windows dokážu vypsat ještě mnohem víc, než požadujete ve výjimkách. Jinak stadardní řešení je ponechat v programu debug informace a číst je knihovnou, což je třeba věc, kterou Microsoft v kompilátorech pro C/C++ standardně podporuje. Ale zdůrazňuji, že mě standardní výjimky v C++ stačí víc, než dostatečně. Spíše bych postupoval tak, že když chci něco nadstadardního, tak si to sám implementuji. A situace, kdy 99,999999% věcí mi vyhovuje tak, jako jsou ve standardu a zbytek si implementuji po svém považuji za pádný důvod, abych byl se standardem C++ spokojen.

Neříkám, že C++ je dokonalé, a že by se některé věci nedaly změnit k lepšímu. Ale na rozdíl od Vás jsem s C++ velmi spokojen. Ono je to totiž tak, že pokud budete psát Céčkovským způsobem (to jest způsobem myšlení ve strojovém kódu) v jakémkoli jiném jazyce, ať už C++, C#, Javě, Pythonu, Adě, či čemkoliv jiném, tak zjistíte, že nejlepší je Céčko. Já prostě v Céčku píšu tak, jak je přirozené pro Céčko, v C++ píšu tak, aby mi C++ posloužilo největší efektivitou a jak je pro C++ přirozené, v Javě píšu zpsůobem přirozeným pro Javu, v Pythonu píšu zase jinak, apod.. A jsem relativně s mnoha programovacími jazyky spokojen, i když taky sem tam brblám a neodpustím si poznámky hlavně na Javu.

[zde]

foo((typ)bar())

To by bylo fajn, ovšem 1) ještě jsem to (redundantní cast pro zvýšení čitelnosti) v C++ nikdy neviděl použít- vy ano? 2) to rovnou mohu použít

foo_typ(bar())

a nepotřebuju stinkin' C++.

Ad sizeof, abs, atd.. ano, fakticky jde o přetěžování, ovšem ohraničené speciální případy. Při čtení libovolného kódu v C si můžu být jistý že malloc(10) a malloc(10U) udělá tu samou věc, což C++ negarantuje, a já to považuju za jednoznačnou chybu, nikoliv "pokrok".

Navíc přetížení funkcí se v každém dynamickém jazyce dá zrealizovat, prostě zjistíte typy předaných parametrů a rozvětvíte kód podle zjištěných typů.

To je naprosto OK, protože pak to větvení JE VIDĚT. Kdežto v C++ stačí přehlédnout přetíženou verzi (což při bloated C++ headerech není problém), a kód dělá něco jiného než jak vypadá.

A zjistíte, že je portabilní interface k RTTI.

Už je to hodně dávno co jsem to používal, ale myslím že nebylo příliš kompletní, končilo někde u dynamického castování. Je to konečně použitelné? Jsou třídy konečně hodnotamí? Jdou srovnávat na ekvivalenci nebo pozici v hierarchii? Jdou konstruktory volat dynamicky? Pokud ne, je to stále nepoužitelné.

Ale zdůrazňuji, že mě standardní výjimky v C++ stačí víc, než dostatečně.

To je možné. Já bych ale chtěl každé smetí, které překladač přibalí, využívat podle svého uvážení, což bez standardního formátu, nebo *kompletního* API nelze. Pokud MSVC nabízí přístup k debug info, tak je to sice hezké, ale pouze pro windows. Když už C++ zavedlo runtime přístup k typovým informacím, a zpracování výjimek, měl být kompletní.

Céčkovský způsob není myšlení ve strojovém kódu, pouze méně zakrývá cenu každého řešení. Na tvorbu malého, bezpečného, spolehlivého a rychlého kódu je to stále ten nejlepší nástroj. Pokud chci vyšší efektivitu psaní, použiju Python, Perl nebo Javu, které věci jako výjimky nebo RTTI dělají pořádně, jsou výrazně přenositelnější, a nejsou přitom o moc pomalejší než ono C++.

[Miloslav Ponkrác]

Zkusme to jinak. Představte si, že budete mít někde v kódu napsáno foo(bar()). Je teď úplně jedno, jestli to bude v C, C++, Javě, C#, nebo jinde. Jak bez zjištění návratového typu funkce bar zjistíte, či bez zjištění, jaký typ bere parametr funkce foo co vlastně do funkce foo leze? Nezjistíte.

Přetěžování funkcí se píše tak, abyste nepotřeboval vědět, která z přetížených funkcí konkrétního jména byla volána. Tak se to alespoň dělá v projektech, kde se dodržuje štábní kultura. Pokud budu mít funkci vypis(x), pak mě stačí vědět, že prostě vypíše libovolný typ správným způsobem.

Ten Váš argument můžu klidně posunout. Budu mít výraz:

a = b + bar();

Tenhle výraz je pro mě nesrozumitelný do té doby, než budu vědět jakého typu je proměnná b a jaký typ vrací funkce bar(). Tedy Váš problém není jen s přetíženými funkcemi, ale obecně s jakýmikoli výrazy, a to dokonce i když přetížené funkce nejsou. Takže sorry, tohle pro mě není argument proti přetíženým funkcím.

Ano, možná malloc(10) a malloc(10U) udělá tu samou věc, ale já bych programátora, který by oba tyto případy použil nakopal do zadku s prominutím. Protože dobrý kompilátor minimálně vydá varování ohledně míchání signed a unsigned typů. Tak vidíte, i v C můžete použít věci, které nejsou košér, dokonce to přeložíte a nevidíte to jako vadu C. Jinak řečeno i v C existují věci, které lze použít špatně. Takový malloc(-11111) Vám třeba projde, ale udělá poněkud něco neočekávaného po převodu na unsigned hodnotu. A přesto to nevidíte jako chybu C. A stejné je to s přetíženými funkcemi, lze je použít špatně, ale při dobrém použití je to báječný prostředek, který značně přispívá k čitelnosti kódu a k efektivitě programu.

To větvení vidět normálně není. Protože normální je, že vidíte interface funkce a vnitřní implementace Vás nezajímá. Nebo vy snad koukáte do vnitřní implementace funkce fopen řekněme? Kolik programátorů se o to zajímá? A když máte projekt, který má třeba deset miliónů řádků kódu, máte čas se dívat do implementace každé funkce? A nebo dokonce běžný případ, když koupíte zkompilovanou knihovnu od komerční firmy a dostanete jen prototypy, jak získáte implementaci? A implementace Vás nemůže zajímat také proto, že se mění! Váš projekt ve verzi 1.0 může obsahovat funkci x(), kterou napsal kolega a funkce x() ve verzi 2.0 může být implementovaná úplně jinak! Spoléhání na implementaci je cesta k tomu, abyste si co nejdříve nabil čumák.

U RTTI uhýbáte. Nejdříve, že to není portabilní, že je to takové atd.. Ano, C++ má slabé RTTI a je to slabina C++, proč to zakrývat? Třídy v jistém smyslu hodnotami jsou, byť bez reflexe, protože každá třída má svoji metatřídu, tedy instanci třídy s informacemi o ní. Lze srovnávat na ekvivalenci a určovat, jestli jsou stejného typu. Konstruktory nelze přímo volat dynamicky a já říkám zaplať pánbůh. Protože tahle dynamičnost stojí určitou režii, a C++ je zaměřen především na rychlost. Navíc třída v C++ nemusí mít defaultní konstruktor, pokud to nemá smysl a pak by dynamické volání konstruktoru mělo dělat co? Zajímavé je, že Vám jde o efektivitu a doslova honíte mikrosekundy, ale jindy zase propagujete věci, které prostě méně efektivní jsou už z principu.

Já bych chtěl využívat každé smetí, které překladač přibalí podle svého uvážení. Teď jsem se musel zarazit, protože jsem se smíchy málem umlátil o stůl. Ukažte mi prosím Vás jazyk (včetně strojového kódu), který Vám toto splní. Podle mě ale C++ to plní podstatně lépe, než C. V C máte mnohem více věcí, které prostě podle vlastního uvážení používat nemůžete. Máte operátor+, který ale používat nemůžete. Máte přetěžování funkcí, které ale používat nemůžete. To jsou jen malé příklady. Na C++ si cením právě toho, že v tom "používat podle vlastního uvážení" je snad nejlepší jazyk na světě. Za dvacet let jsem poznal desítky jazyků a C++ zatím suverénně vede v tom, nakolik flexibilně a podle svého si můžu jeho věci používat. Dokonce je to i častý argument jeho odpůrců, že dává až moc velkou volnost. A Vy vytknete nedostatek v tom, v čem je nejlepší na světě! Jste srandista, opravdu.

Problém té kompletnosti, po které voláte u výjimek a u typových informací je jeden. Za prvné je to neefektivní. Pokud Vám tohle jazyk nabídne, stojí to nějakou režii a znovu říkám, že C++ je jazyk optimalizovaným na rychlost. U dynamických jazyků jsou tyhle věci zadarmo, protože fungují jinak.

Céčkový způsob je v podstatě myšlení ve strojovém kódu. Céčko, stejně jako stroják méně zakrývá cenu řešení, to je jim společné. Problém je, že ani C++ to nezakrývá, jediný problém je, že Vy C++ neumíte a tudíž je to pro Vás zakryté. Pro mě je řešení v C++ stejně průhledné jako řešení v C. Jediný rozdíl mezi C a C++ je ten, že v C jste nucen pracovat na nížší úrovni.

Pro tvorbu malého, rychlého, spolehlivého a bezpečného kódu je nejlepší C++. Nevidím naprosto žádný důvod, proč použít C kromě jediného důvodu a to je ten, že C++ není k dispozici.

Jinak Vám přeji hodně efektivního psaní, hlavně v tom Perlu. Hlavně v tom piště nějaký větší projekt, stačí slabých sto tisíc řádek. A až si dostatečně nabijete čumák, pak to sem přijďte napsat.

[zde]

Ach jo. Takhle se hádáme o ničem- každá (i špatná) featura může být za nějakých podmínek výhodou, vše nebezpečné může být štábní kulturou ohlídáno, apod. Oba jsme dost zkušení na to, abychom dokázali udělat díru do argumentů druhé strany, ad nauseum.. ale proč?

Víte co, naučte se ten Python. Je dosti možné že pak si sám zázračně uvědomíte, jak nemotorný a omezený "vysokoúrovňový" nástroj ten C++ vlastně je (byl).

[Miloslav Ponkrác]

Konečně jste na to kápnul. Každá featura může být dobrá i špatná. Jde o věc pohledu a konkrétní potřeby. Pokud budete zaujatý vůči C++, není to chyba C++, ale Vaše.

Mimochodem, v Pythonu jsem napsal docela dost komerčních věcí. Stále jsem při tom nepřestal mít rád C++. Od té doby hledám něco, co by bylo jako Python, ale bez těch Pythonovských nemotorností. Schází mi v Pythonu některé Céčkovské vychytávky, jako třeba to, že přiřazení je výrazem. Mnohdy musím zdroják dost zatemnit jen proto, že tuhle Céčkovou věc Python neumí. Knihovny v Pythonu je běs, je to každý pes jiná ves. A příšerná dokumentace, jedna z nejhorších, jaké jsem kdy u programovacího jazyka viděl. Ale přesto toho dost Pythonu zbývá na to, aby se v něm dalo slušně a pěkně programovat.

C++ a Python se srovnávat nedají. C++ je kompilovaný poměrně vysokoúrovňový jazyk, jehož výsledkem je čistý stroják a je zaměřený na rychlost. Python je dynamicky typovaný jazyk, který je mnohonásobně pomalejší, než C++.

Jen se Vám divím, že už se nepodíváte do zrcadla a nepřiznáte si, že tu nenávist k C++. Už jste do boje proti C++ vytáhnul asi pět jazyků. Chválil jste Céčko, že je efektivnější, než C++. Sice je to blbost, budiž, ale hlídal jste každou milisekundu. Pak z druhé strany vytáhnete Python, který naprosto popírá to, co jste vyzdvihoval, je to totiž pomalý jazyk jako prase. Chválil jste Céčko za nízkoúrovňovost, a za to, že zbytečně nezatemňuje jako C++, na druhé straně vytáhnete Python a chválíte ho za vysokoúrovňovost. Jděte už do kelu s tím Vaším srovnáváním jazyků, Vy jste jak ženská, které neví co chce. Prostě nenávidíte C++, tak nehledejte argumenty a jděte s tou argumentací do háje. Nikdo Vás v tom programovat nenutí.

[Miloslav Ponkrác]

Ano, to je IMHO ten pravý důvod, proč se tehdy jádro Linuxu nepsalo v C++, protože rozumné kompilátory vyhovující standardu tu jsou teprve několik roků.