Mám rád C++ (diskuse)

[Messa]

Už jsem si myslel, že si někdo dělá srandu - psát do blogu tolik kódu, který skoro nic nedělá

Jinak operator= bych asi deklaroval jako virtual.

[Messa]

A ještě const: CsBase& operator =(const CsBase& that);, to samé u kopírovacího konstruktoru, a také int GetX() const;.

[vogo]

na tom něco bude, zdálo se mi to trochu chudší, než to co jsem plodil v práci :)

[Jirka P]

Proboha, proč virtual? Je k tomu nějaký důvod, anebo jen přidáváte broky do brokovnice, kterou si následně ustřelíte nohu?

Jinak ten zápisek taky nechápu, když tam skoro žádný přetěžování není.

[grim]

možná proto, že "java" (nebo jiný podobný jazyk, který (neznám a) neumožňuje takové bezva věci, jako přetěžování operátorů.

Já už jsem si pomalu zvykl, nebo jsem spíš rezignoval. Proč se pořád rozčilovat...

[Messa]

Dobře. V tomto konkrétním případě je naprosto zbytečné a jinak vše závisí na tom, jaké chování je od programu očekáváno. Zda se třeba y má nechat bez povšimnutí, když instanci CsDerivate zkusíte přiřadit CsBase; v tom případě by se muselo doplnit něco jako CsDerivate::operator =(const CsBase& that) a tam už je virtual na místě; původně jsem si kód přečetl jen zběžně a myslel jsem si, že to tam opravdu je (kde by se vzalo to y už mě nějak nedocvaklo). Omlouvám se za zbrklost, pane střelče; možná bych také měl psát anonymně, abych si nedělal ostudu

[Jirka P]

Hodně jsem přemýšlel, zda mám psát tenhle příspěvek, abych se náhodou nedozvěděl něco, co by ublížílo mé naivní a dosud neposkvrněné duši

Zda se třeba y má nechat bez povšimnutí, když instanci CsDerivate zkusíte přiřadit CsBase;

Takže něco jako splicing naruby? Když na to máte nervy... Já, když už se splicingem nemůžu moc účinně bojovat, tak ho aspoň nepodporuju. A to nemluvím o tom, že splicing aspoň má šanci vytvořit nějaký smysluplný objekt, ale toto...

v tom případě by se muselo doplnit něco jako CsDerivate::operator =(const CsBase& that) a tam už je virtual na místě;

Ne. Jelikož jediné, co brání té vaší sémantice fungovat, je zastínění operátoru= z předka v potomkovi, stačí něco jako using CBase::operator=. Viz kód:

struct A
{
  int x;
};

struct B : public A
{
  using A::operator=;
  int y;
};

int main()
{
  A a1, a2;
  B b1, b2;
  a1=a2;
  b1=b2;
  a1=b1;
  b1=a1;
};

A brokovnice (v tomto případě spíš bazuka) je naládovaná...

Trocha teoretických keců, kterými to vysvětlím/zamlžím: Při programování v C++ se používá několik principů (nebo, chcete-li paradigmat). Jedním je "value semantics", dalším je objektové programování s polymorfismem. Operátor= přichází z prvního světa, virtuální funkce z druhého. Ty světy se samozřejmě mohou míchat, takže uděláte třeba knihovnu která používá principy obou, ale rozhodně ne tak že uděláte virtuální operátor=. Obecně, funkce, která má být polymorfní ve víc než jednom typu (speciálně: polymorfní binární operátor), je v C++ předem prohraný boj.

Ještě pro autora: věděl jste, že operator= se stejnou sémantikou vám kompilátor vygeneruje sám? A copy-constructor taky?

BTW: To střílení je odkaz na citát B. Stroustrupa. Vizte seznam citátů, tam to najdete

[Jirka P]

Ehm, s/splicing/slicing/g. Už mi ten linux leze na mozek

[Miloslav Ponkrác]

Řekl bych jinak, v C++ jde cokoliv, co autor zvládne. V krajním případě i virtuální operátor=. Když se to dobře napíše, funguje to a střílení nohy se nekoná, ale rozhodně se to musí napsat pak jinak, než se uvádí. Ba dokonce v případě, že chcete napsat velmi neprůstřelnou knihovnu, jejíž interface se bude chovat korektně ve 100% případů, je občas virtuální operátor= jediná možnost, jak si nepřiřadit volovinu zvenčí, pokud máte slabší chvilku.

Nicméně automatické generování operátoru = a copy construktoru (stejně tak jako default constructoru a destructoru) znám a neustále to musím vypínat.

Nechť lidi programují v C++ do té míry, kam zvládnou - pro někoho to znamená hodně se v C++ držet při zemi, pro jiného obrovský rozlet. Střílení do nohy se koná jen v případě, že nevíte co děláte v C++ - a je úplně jedno co konkrétně děláte a jaké techniky používáte.

[alblaho]

No, C++ je jistě super hackerský nástroj, ale podíl signál/šum v tvém kódu je opravdu žalostný. Škoda, že přetěžuješ zrovna operátor přiřazení, protože kdyby byl tenhle post o nadšeném sčítání, tak bych ti napsal ekvivalent nějak takto:

class Base:
    def __init__(self, x):
        self.x = x
    
    def __add__(self, that):
        self.x += that.x
        return self

Je to bez záruky, nicméně pointa je jasná. Čím míň kódu, tím líp

[Luboš Doležel (Doli)]

class Base
{
  Base(int x) : m_x(x) {}
  void operator+=(const Base& x) {
    m_x += x.m_x;
  }
  int m_x;
};

[Let_Me_Be]

Nekde ti tam chybi public :)

[alblaho]

Chtělo by se říct, žes mě dostal, ale není to pravda.

Tak zaprvé, v praxi bys tu metodu nepsal takhle inlinovaně, ale musel bys udělat hlavičkový soubor a implementaci.

Druhá věc je, že potřebuješ getter a setter (s triviální implementací), protože kdybys je tam přidal později, tak bys změnil rozhraní. V pythonu můžeš nechat věci public dokud to vyhovuje a přidat getter setter a property, která je bude volat - a přitom se ti rozhraní nezmění.

[Luboš Doležel (Doli)]

Tak zaprvé, v praxi bys tu metodu nepsal takhle inlinovaně, ale musel bys udělat hlavičkový soubor a implementaci.

Proč? Nemusím nic.

Druhá věc je, že potřebuješ getter a setter (s triviální implementací), protože kdybys je tam přidal později, tak bys změnil rozhraní.

a) Nepotřebuju. b) Jako setter by mohl fungovat i ten konstruktor

[Miloslav Ponkrác]

Python zase díky dynamickému typování vytváří vysoký podíl šum/signál v případě, že chci jednu metodu/funkce, která pro různé typy parametrů dělá pod stejným jménem odlišné věci. Tam kde ve statickém jazyku (pozor - nemluvím jen o C++) použiju overloading pro třeba sto různých typů parametrů, tam v Pythonu není moc šance, než zaplevelit zdroják mnoha ify.

Navíc nevýhoda Pythonu je jeho nestabilita - syntaxe se mění a ne zcela zpětně kompatibilně - není tu záruka ochrany práce. V C++ co napíšu podle standardu, to vždycky přeložím a vždy najdu kompilátor na běžných platformách, který nebude mít problém. Tato záruka u Pythonu není.

[alblaho]

No ideální je mít dokonalá rozhraní, takže metody pak fungují správně nezávisle na přesném typu parametru . No a pak tu jsou multimetody.

O tom, jak jste objevil a zavrhl Python jsem četl. Když jste spokojený s C++ a využíváte jeho objektivních výhod, tak prosím. Na druhou stranu musíte uznat, že stabilita Pythonu je o dost lepší než konkurence PHP nebo Ruby. Akorát Perl 5 je ještě stabilnější. Ano, ISO normu nemá žádný

Ale zase prakticky, napsat C++ kód (byť podle normy), který bude fungovat na různých překladačích a platformách, to není žádná prdel.

[Miloslav Ponkrác]

Dokonalá rozhraní, která fungují nezávisle na přesném typu parametru obecně neexistují, je to jen fikce, která ve skutečnosti znamená, že rozhraní funguje pro předem určený počet typů, které splňují x dalších podmínek a pokud tam pošlete jiný typ, může se stát naprosto cokoli.

Já C++ už tak moc nepoužívám, je poněkud víc jazyků. Dokonce i na ten Python si sahám, jen mu nesvěřuji nic jiného, než krátkodobé věci, které se pak zahodí. Na to je dobrý, a bez záruky stability syntaxe žádnému jazyku nic víc nesvěřím. Mluvím nikoli o stabilitě Pythonu z hlediska běhu, ale o stabilitě z hlediska záruky, že není možné napsat program v Pythonu tak, aby jste ho v příští verzi Pythonu vůbec spustili, a aby dělal stále to samé. Tato záruka stability syntaxe v C++ existuje, a je to jeden z důvodů, proč se C++ tak enormně rozšířilo.

Napsat C++ na 100% podle normy znamená, že bude fungovat všude na různých překladačích (kvalitních samozřejmě, o bahně se nemusíme bavit) a na všech platformách. To je velice jednoduché a žádný problém v tom není.

[alblaho]

Vždyť já jsem mluvil o syntaxi, případně o standardních knihovnách. PHP je známé tím, že se něco rozbije i při setinkových updatech. Naproti tomu Perl 5 AFAIK skutečně drží zpětnou kompatibilitu někdy od počátku devadesátých let. Vývoj Ruby je dost hektický a že při uvedení ruby 1.9 na tom neběželo RoR mluví za vše. Vývoj Pythonu je stabilní a předvídatelný, Python 2.0 je někdy z roku 2001 a přiznám se, že nevím, jestli je 2.5 úplně zpětně kompatibilní, ale čekal bych, že jo.

No a že se vám iniciativa Py3k nelíbí, tak to je pochopitelné, ale nic s tím neuděláme.

Napsat C++ na 100% podle normy znamená, že bude fungovat všude na různých překladačích (kvalitních samozřejmě, o bahně se nemusíme bavit) a na všech platformách. To je velice jednoduché a žádný problém v tom

No já nevím, třeba napsat kód, který bude mít problém s indiánovostí lze celkem snadno, ne? O tomhle už jsme se bavili, v diskuzích jste tvrdohlavý a jste určitě zkušenější programátor než já, takže vás nepřehádám. Ale zdá se mi, že si to moc malujete, i když se vám nezmění samotné C++, tak v reálu váš kód závisí na všelijakých knihovnách atd. Takže tvrzení "mám to ve std. C++, tak to mám navěky" mi přijde dost přitažené za vlasy. Zprovoznit starý kód nějaké úsilí zpravidla vyžaduje.

[Miloslav Ponkrác]

Ohledně syntaxi - zkuste to porovnat s jazyky, které si záruky berou za své a budete někde jinde. Souhlasím s tím ohledně PHP, Ruby, atd.. Nicméně skutečné záruky Python nedává. Neexistuje žádná záruka, že v příští verzi Pythonu to bude běžet. Neexistuje žádný dokument, kterého by se autor/autoři Pythonu měli a chtěli závazně držet v budoucích verzích Pythonu. A navíc mluvíte nikoli o Pythonu, ale o pouhé jediné implementaci Pythonu zvané CPython. Zkuste to rožšířit na IronPython, JPython, atd.. a v tu chvíli je na tom Python zcela jinde. Zatímco v C++ mám záruku, že pokud je kvaitní kompilátor je šuma fuk, kterým to přeložím. Mám na výběr mnoho různých implementací C++ a stále jsou tu lepší záruky ohledně funkčnosti mého kódu, než v případě Pythonu na jeho jedné jediné implementaci (CPythonu). A tyhle záruky nejsou jen u C++, ale dalších jazyků.

Ale v čem musím dát za pravdu, že oproti PHP, Ruby a pod.. je Python asi nejlépe veden a ten jazyk je skutečně dobrý. Já sám jsem vlastně v takové schizofrenní pozici - strašně se mi Python líbí až neskutečně moc jako jazyk. Přes všechny kritiky vůči němu mi přijde Python jako něco úžasného a dobrého. Vlastně jsem couvnul od něj až když jsem zjistil, že zpětná kompatibilita se v komunitě kolem autora Pythonu bere za zpátečnictví a za sprosté slovo. Z naprosto stejného důvodu jsem utekl od spousty technologií Microsoftu.

Ohledně druhého odstavce: Napsat kód, který bude mít s čímkoli problém lze snadno v jakémkoli jazyce. Klidně Vám vyseknu kód, který bude selhávat na endianity třeba v Javě, nebo Pythonu, nebo kdekoli jinde.

Napsat přenositelný program není snadné. Ono to není snadné v žádném jazyce, a C++ tomu bohužel nepomáhá ani to, že jeho standardní knihovna je dost malá a málokterý program v C++ nemusí sáhnout po něčem navíc. Takže pak potřebujete věci nad rámec standardu. Takže máte pravdu, že málokterý přenositelný program v C++ je prostě bez problémů při přenosu jinam. V tomhle je jednodušší použít ten Python, kde přenositelně napíšete jednodušeji (zase ale není záruka syntaxe), nebo Smalltalk, či jiné věci. I když s Vámi diskutuji, v tomhle Vám dávám za pravdu.

Moje tvrzení mám to ve standardním C++, mám to navěky platí. Jsem na to zvyklý, že pokud něco napíšu ve standardním jazyce, že na to opravdu nemusím sáhnout. Uváděl jsem tu, že mám přes 15 let staré zdrojáky v C psané pod dnes už nepoužívanými platformami, a já to bez problémů a bez jediné změny přeložím pod Linuxem a Windows - a ono to nejenom že chodí, ale dělá do puntíku to samé co kdysi. Stejně tak jakýkoli C++ zdroják, kde jsem vystačil se standardem, tak jsem nikdy při přechodu jinam přepisovat nemusel. Ale standard C++ tu není tak dlouho jako v případě C, ale i přes deset let staré kódy v C++ mi fungují aniž bych na ně sáhnul. Je to úžasné a opravdu to tak funguje - pokud znáte standard a držíte se ho. Tady ani trochu nepřeháním. A po těch letech jsou to betonově spolehlivé kódy, perfektně odladěné, a můžete se na ně spolehnout.

[alblaho]

Skutečné papírové záruky Python nedává. Ale zase na druhou stranu je to opensource, takže pokud bude poptávka po nějaké starší verzi, tak je slušná šance, že to někdo bude udržovat.

Jazyková kompatibilita CPythonu/Jythonu/Ironu je asi jako mezi dialekty SQL různých databází

No a když se nějaký dostatečně silný výrobce (třeba Microsoft) rozhodne ignorovat nějakou ISO normu, tak je to taky nepříjemné.

[Josef Kufner]

Skutečné papírové záruky Python nedává. Ale zase na druhou stranu je to opensource, takže pokud bude poptávka po nějaké starší verzi, tak je slušná šance, že to někdo bude udržovat.

Nebyl bych takový optimista. Loňskou verzi asi jo. Starší těžko. Tak jako tak je to zbytená komplikace, stráta času i peněz.

[zde]

> Tam kde ve statickém jazyku (pozor - nemluvím jen o C++) použiju overloading pro třeba sto různých typů parametrů

..což můžete samozřejmě použít i u dynamického jazyka. Dispatch na správnou metodu můžete dělat buď staticky jako u C++ (tj uvádět přetížené jméno), nebo si na to napsat vlastní dispatch (kód na jeden řádek).

class hovnocuc:
    def bla_int(self, i):
        print 'int', i
    def bla_long(self, l):
        print 'long', l
    def bla_str(self, s):
        print 'string', s
    def __call__(self, *arg):
        for i in arg:
            getattr(self, 'bla_%s' % type(i).__name__)(i)

h = hovnocuc()
h(1, 2L, 'pampers')

> tam v Pythonu není moc šance, než zaplevelit zdroják mnoha ify.

Mnoho ifů je hint, že funkci je vhodné rozdělit. To vás v té C++ nalejvárně neučili?

[Miloslav Ponkrác]

A kde máte implicitní typové konverze? Třeba funkce, která bere jako parametr třídu t, taky bere všechny její potomky, který může být třeba tisíce typů. Trochu Vám to skřípe. Stejně tak stačí jednou napsat funkci třeba funkce(double) a ona pobere, pokud nedefinuji nic dalšího vše od intů, longů až po float a double. Prostě Vaše řešení není ekvivalentem přetěžování funkcí ve staticky typovaných jazycích.

[Tom.š Ze.le.in]

CLOS vám taky není dost?

(defmethod foo (a b) (foo-generic))
(defmethod foo (a (b some-class))  (foo-for-some-class))
(defmethod foo ((a number) (b some-class))
  (foo-for-number-and-some-class))

Runtime overhead je, ale mimo vnitřní smyčky zanedbatelný (memoizace), a ještě snížitelný MOPem, a navíc tam většinou příslušný typ znám předem. Samozřejmě hierarchie typů je trochu jiná, takže integer není podmnožinou double, ale to je detail.

[Miloslav Ponkrác]

O LISPu si myslím jenom to nejlepší

[Michal Vyskočil]

A kde máte implicitní typové konverze? Třeba funkce, která bere jako parametr třídu t, taky bere všechny její potomky, který může být třeba tisíce typů.

Tak místo volání type prohledá atribut __bases__, což je seznam předků třídy? Ale co to říkám tak zkušenému programátorovi, jako jste vy. To už přece dávno víte

Trochu Vám to skřípe. Stejně tak stačí jednou napsat funkci třeba funkce(double) a ona pobere, pokud nedefinuji nic dalšího vše od intů, longů až po float a double. Prostě Vaše řešení není ekvivalentem přetěžování funkcí ve staticky typovaných jazycích.

Jasně, ona se totiž v Pythonu implicitní typová konverze nedá v žádném případě doprogramovat tak, aby program volal bla_double i pro inty, pokud neexistuje bla_int.

Navíc, zde napsal jenom náznak řešení. Pokud potřebujete kompletní ekvivalent typového systému z C++ v Pythonu, budete si ho muset napsat sám. Je samozřejmě pravda, že přidávat statické typování do dynamicky typového jazyka znamená psát kód, který v tom statickém nemusím, nicméně obráceně to platí zrovna tak. Prostě ohýbání jazyka k filozofii, kterou nemá implicitně v sobě, něco stojí. Ale to se týká libovolného jazyka, včetně C++.

[Tom.š Ze.le.in]

Ono je to malinko komplikovanější, bez ohledu na jazyk - pokud se má dělat dispatch na více parametrech (což může být i případ overloadingu), tak může být akceptovatelných funkcí více, a pak je třeba zavést na nich nějaké uspořádání - a nemusí být jednoznačné a jednoduché určit co je správně. Obdobně při volání funkce zděděné od více předků. Už si ani nepamatuju jak to řeší C++, pokud to nenutí programátora specifikovat ručně.

[spang]

Jaký smysl má dělat private proměnnou s get + set metodama, když ani v tom setu nedělá žádná kontrola nebo něco? Ji dám rovnou public ne?

[kozzi]

proc public? x je vnitrni promena te tridy a nevidim jediny duvod proc by mela byt public. by se tim narusilo zapouzdreni

[spang]

Tak mám místo jedné public proměnné dvě public metody a stejně si to může přečíst/změnit kdo chce jak chce. Zapouzdření jak noha.

[Heron]

Ehm? V budoucnu ten atribut nemusí být vůbec jeden, ale může se jednat třeba o složitý výpočet. V tvém případě bys při každé změně implementace dané třidy musel měnit i její klienty. Pokud to jednou (nejlépe hned) pořádně zapouzdříš, tak se změna implementace třidy vůbec nikoho nedotkne (pokud zachová původní kontrakt). Interface by se měl měnit minimálně. Jsem zvědav jak toho dosáhneš zveřejněním atributů.

[spang]

Pokud nebude stačit atribut a místo toho se rozhodnu něco počítat, tak se to bude muset změnit, to je jasné. Tou změnou hold pykám za to, že jsem si to pořádně nerozmyslel hned (ale není to snad taková hrůza). Kdybych psal knihovnu, tak souhlasím, že změny interface jsou nežádoucí, ale když píšu třídu pro vlastní použití...
Když si ke každé proměnné udělám getter a setter co vlastně nic nedělá, tak se tím celkem popírá celý smysl private proměnných, rovnou si můžu ušetřit práci s obcházením těch ochran a dát to public.

[Let_Me_Be]

Az napises neco vetsiho, tak prestanes zvatlat podobne blbosti. Nekolikadenni upravu zdrojaku si holt musi kazdy programator projit aby dospel.

Když si ke každé proměnné udělám getter a setter co vlastně nic nedělá, tak se tím celkem popírá celý smysl private proměnných, rovnou si můžu ušetřit práci s obcházením těch ochran a dát to public.

Zakladnim principem OOP je ze NIKDY nedovolis primy pristup k datovym castem tve tridy. Zase musis trochu dospet (prozit si to utrpeni) abys pochopil proc to tak je.

[spang]

Zakladnim principem OOP je ze NIKDY nedovolis primy pristup k datovym castem tve tridy. Zase musis trochu dospet (prozit si to utrpeni) abys pochopil proc to tak je.

Třeba v pythonu se bez private čehokoli (OK, jde to, ale...) přežít a objektově psát evidentně dá. A co třeba jazyky co podporují properties: k public property se přistupuje podobně přímo, jako k proměnné (navíc se tam dá dělat nějaká ta kontrola nebo výpočet). Tam už není žádný rozdíl (krom objemu kódu) mezi public proměnnou a private proměnnou s triviálními getter + setter a navíc se tam dá k public proměnné přidat kontrola bez změny interface. Pořád ta poučka platí?

[alblaho]

Přesně tak. Výhoda Pythonu je v tom, že nemusíš psát těch 90% getterů setterů, co mají triviální implementaci. A když potřebuješ netrivální implementaci, nasadíš tam property.

Nejhezčej to mají asi vyřešené v Ruby.

[Let_Me_Be]

A co třeba jazyky co podporují properties: k public property se přistupuje podobně přímo, jako k proměnné (navíc se tam dá dělat nějaká ta kontrola nebo výpočet). Tam už není žádný rozdíl (krom objemu kódu) mezi public proměnnou a private proměnnou s triviálními getter + setter a navíc se tam dá k public proměnné přidat kontrola bez změny interface.

WTF? Precetl jsem si to asi desetkrat ale porad nechapu co si tim chtel rict. Kde uz neni zadny rozdil mezi public promennou a private promennou? Kdyz mam property, tak prece zadnou public promennou nemam.

[Radek Miček]

Mam pocit, ze autor mel na mysli postup v Pythonu, kde je promenna napred public, a pak kdyz je to potreba, da se z ni udelat property - z vnejsiho sveta neni poznat zadny rozdil.

[spang]

Nejen v Pythonu -- třeba C# je C++ přecejen bližší a platí to taky.

[Radek Miček]

Pokud vim, napisu-li v C# promennou jako public, a pak z ni chci udelat property, tak kod, ktery tu promennou pouzival, musim znovu kompilovat - nebot v CLR je rozdil mezi property a promennou, nebo ne?

Mj. v C# 3.0 je to zjednoduseno viz http://www.voidspace.org.uk/python/articles/properties_and_csharp3.shtml.

[spang]

Kompilovat možná jo (to bych musel i v C++ při změně setteru, ne?), ale to vem čert, hlavně není třeba ten kód opravovat...

[spang]

Jednoduše: Navenek není rozdíl, mezi (a) public proměnnou a (b) private proměnnou + public property s triviálním getterem a setterem pro tu (private) proměnnou. Kdybych chtěl přidat kontrolu, můžu to stejně pohodlně udělat v obou případech. Proto nevidím důvod volit (b) a zajímá mě, jestli ty nějaký vidíš.

[Let_Me_Be]

Samozrejme ze navenek rozdil neni videt. To je take spravne (bohuzel C++ zatim neumi properties). Dulezite je co je uvnitr. Kontrolu v prvnim pripade samozrejme pridavat nemuzu, protoze neni kam.

[finc]

Udelate to jednou, dvakrat, trikrat.... a pak jiz to bude naprosto nezadouci samozrejmost. Nema smysl predvidat budoucnost, ale co kdyz skutecne setter bude neco kontrolovat? Pote prichazeji na radu 2 moznosti:

• 1. vytvorim setter, opravim to vsude, kde jsem dany atribut tridy volal naprimo (hrozna predstava), prepisu na volani setter
• 2. upravim setter

Zapouzdreni se netyka jen interface. To, ze dany kod budu volat jen ja sam jeste neznamena, ze ho za par tydnu zavolam dobre :)

K dobrym programatorskym praktikam patri fakt, ze co nemusi byt public, at jim NIKDY neni. Pridat se da vzdycky, ale odebrat, to je jiz ve hvezdach. Tyka se to jak knihovnich trid, rozhrani, tak i samotne implementace, ktera se vola naprimo.

P.S. Jak se popira cely smysl private, pokud k daneu atributu udelam setter ci getter, ktery jen ciste vraci a nastavuje?

[trekker.dk]

vytvorim setter, opravim to vsude, kde jsem dany atribut tridy volal naprimo

Na 99% to někde zapomeneš a pak se budeš divit...

[Luboš Doležel (Doli)]

A to ani nehrozí. Atribut se dá jako private a rekompiluje se všechen kód, který s třídou pracuje -> kompilátor to zarazí.

[trekker.dk]

Pravda, to mě nenapadlo.

[Michal Vyskočil]

proc public? x je vnitrni promena te tridy a nevidim jediny duvod proc by mela byt public. by se tim narusilo zapouzdreni

No ono se naopak vkládá otázka, proč by měla být proměnná třídy/instance vůbec kdy public. Chápu, že pro C++, kde je třída jenom struct s opačným implicitním nastavením práv, to asi nějaký smysl má, ale v takové Javě, která se inspirovala Smalltalkem, už ne.

Právě Smalltalk má asi nejrozumnější systém práv. Členské proměnné jsou jednoduše skryté a metody jsou veřejné. V Javě by se pravděpodobně hodily ještě protected/private pro metody (i když i bez nich se dá žít), ale nerozumím, jaký význam v něm mají public proměnné (leda na "machrování" s final prvky u immutable objektů jako String, nebo Array, což ohromně zvyšuje konzistenci jazyka).

[Let_Me_Be]

Obecne je public promenna blbost. Public konstantni promenna je uz mensi blbost. Ale v C++ by to kolidovalo se struct a taky cokoliv zakazovat v C++ je fuj.

[Miloslav Ponkrác]

To je právě odlišná filozofie jazyků. Třeba už jen to, že C++ má jako objekty možnost předávat hodnoty i reference (což v Javě nejde), nemusí si jako Java a Python hrát nekonzistentně na immutable objekty. Navíc všemu lze přiřadit v C++ atribut konstantní/nekonstatní, takže immutable slovo v C++ nemá význam.

Chápu, že Javisti by rádi javovskou sešněrovanost a nemožnost jiné, než jedné cesty tak typickou pro javovské programování přenesli do C++, ale neuvědomují si, že je to hovadina. C++ je jazyk, který má být MAXIMÁLNĚ EFEKTIVNÍ v tom, co z něj vyleze za binárku - a tudíž je to formule jedna, kde závodník (programátor) může řídit naprosto všechno, tedy i to co normální řidič ne. C++ je jazyk stvořený na rychlostní maratóny a na programy velmi skromné na konzumaci systémových prostředků, a na to, abyste měli naprosto vše pod kontrolou. Java je naopak jazyk, který předpokládá, že programátor nesmí mít rozlet, není dělaný na efektivitu a ani se o ní nesnaží (viz nenažranost běžných javovských desktop aplikací) a na maximální očesanost.

Hrozně se mi líbí lidi, co by jeden dva jazyky nejraději rozkopírovali do všech, aniž by jim došlo, že bohatost programovacích jazyků je tu proto, že každý má jiné zaměření a plní jiný účel a je určený k něčemu jinému.

[Filip Jirsák]

Nekonzistentní hraní si na immutable objekty říkáte objektům, u kterých nelze z vnějšku změnit jejich stav (protože nemají žádnou metodu, která by něco takového dělala)? Nebo to má ještě nějaký hlubší význam?

[Miloslav Ponkrác]

Immutable objekty jsou objekty, které za immutable prohlásíme - nic přesnějšího bez konkrétního jazyka nelze říct. Ono i změna stavu je věc o které se dá diskutovat.

Immutable objekty jsou objekty, které podle jazyka buď nemají metodu, která by měnila stav (cesta Javy), nebo k ní nejsou práva, nebo jí v daném kontextu nejde zavolat (cesta C++).

Ono také je možné v každém kontextu zdrojového kódu některé metody nepovolit (pro jistotu zde píšu, že nemluvím o žádný private, protected, public, ...), a pro určité úseky kódu povolit pouze tu množinu metod, která nemění stav (a i co to je neměnit stav umožňuje C++ poměrně dynamicky definovat podle potřeby) - a tím zcela zrušit nutnost nějakých zdvojených tříd do páru (immutable, normální) jako je třeba String a StringBuilder v Javě, nebo třeba tuple a list v Pythonu. Tyhle prasárny není potřeba v C++ dělat, neboť lze přesně určit, ve které části zdrojového kódu (zcela nezávisle na nějakém OOP) má daný objekt mít neměnný stav, a kde naopak ho možné měnit je.

[Filip Jirsák]

Tyhle prasárny není potřeba v C++ dělat, neboť lze přesně určit, ve které části zdrojového kódu (zcela nezávisle na nějakém OOP) má daný objekt mít neměnný stav, a kde naopak ho možné měnit je.

To už pak ale není moc OOP, když konstrukce OOP jsou prasárny a výhodou je, že něco můžete dělat zcela nezávisle na OOP. A nebo jsem to nepochopil. Jinak asi vždy záleží na kontextu – pokud objekt implementuje rozhraní bez metod pro změnu stavu, je v kontextu toho rozhraní immutable ale jinde může být měnitelný. Pokud vám to bezpečnostní model dovolí, můžete v Javě přes reflexi změnit i objekty, které žádnou metodu pro změnu neposkytují (ovšem k ničemu jinému než totálnímu rozkladu nějakého programu nebo knihovny to asi dobré není).

[Miloslav Ponkrác]

Proč to není OOP? Například if není moc OOP záležitost (neberu-li v úvahu Smalltalk, Ruby) a tvrdí někdo, že je if prasárna?

V C++ je prostě další dodatečný modifikátor typu, který určuje zda danou proměnnou je možné zmodifikovat, či nikoli - považuji to za nejjednodušší řešení, co snad jde. Stejně tak lze těchto modifikátorů použít několik - například určit, že proměnnou, ani objekt na který odkaz zmodifikovat nelze, nebo třeba že lze zmodifikovat proměnnou, ale už ne objekt, na který odkazuje a vůbec řadu dalších možností.

Jinak čisté OOP v reále existuje stejně zřídka jako Yeti v Praze. Snad možná kromě Smalltalku, který se v mainstreamu nepoužívá jsou všechny OOP špinavé, neúplné, a to včetně Javy, C#, a dalších. Je to proto, že navzdory siláckým řečem ohledně toho, že jen OOP a pouze OOP je super - se čisté 100%ní OOP neukazuje až tak moc praktické.

[Michal Vyskočil]

No já hlavně myslím, že pan Ponkrác buďto reagoval na něco jiného, nebo můj příspěvek vůbec nepochopil. Já si stěžoval jenom na nekonzistenci v případě, že zatímco immutable objekt má public final prvek, tak mutable klasickou metodu a další rozumné využití pro veřejné členské proměnné nevidím. Teda možná v pre 1.5 se tím nahrazovaly enumy.

Navíc kritizovat Javu a Python za to, že nemají hodnoty (OK, tohle je další ze záludností Javy, hodnoty primitivních typů tam jsou, ale v Pythonu skutečně ne) je hodně mimo. Stejně jak není C++ Javou, tak i Java není C++ (ať si margeting říká co chce).

[Miloslav Ponkrác]

Navíc kritizovat Javu a Python za to, že nemají hodnoty (OK, tohle je další ze záludností Javy, hodnoty primitivních typů tam jsou, ale v Pythonu skutečně ne) je hodně mimo.

Celé to začalo tím, že spousta lidí včetně Vás začíná přemýšlet nad C++ tak jako nad třeba Javou apod.. Java z hlediska objektů hodnoty nemá a neumí a nikdy neuměla. Python to samé. Smalltalk to samé.

Hlavní o čem jste psal bylo jednoduché - chtěl jste pro všechny jazyky sešněrovat systém práv k členským proměnným. Já k tomu nevidím důvod - klidně i v té Javě mohu vyrobit imitaci "struct" z C a používat proměnné přímo. Mimochodem, co jiného v Javě je objekt, než struktura s nějakými metodami?

Stejně jak není C++ Javou, tak i Java není C++ (ať si margeting říká co chce).

Tak, a teď aby to 99% diskutujících pochopilo.

[Heron]

A v momentě, když budeš vyžadovat nějakou kontrolu a doplníš gettery a settery, tak budeš měnit celý zdroják?

[spang]

Jistě, když bude třeba, proč probůh ne? Definovat si přebytečné věci "preventivně" mi přijde zvrácené. Radši zapřemýšlím než začnu vůbec psát.

[Luboš Doležel (Doli)]

Mně zase připadá zvrácené, aby byly proměnné třídy public.

[Let_Me_Be]

Ano psat prebytecne veci je jeden ze znaku dobreho programatora. Samozrejme je potreba rozlisovat prebytecne a prebytecne. Getery a Setery jsou z pohledu vysledne binarky zcela ekvivalentni s primym pristupem, takze neni zadny duvod je tam nedavat.

[Ladicek]

Mmm, proč? Nebo pro C++ neexistují pořádné nástroje pro refaktoring?

[s0]

unit testy, UAT, atd. (= a tak dále). Prostě čím míň do toho hrabeš, tím míň se s tím pak sereš. Zejména to oceníš v situacích, kdy změna jedné řádky kódu znamená vyplnit 42 formulářů a testovacích předpisů. Alespoň tak to někde funguje.

[Michal Vyskočil]

Smyslem všeho je potom vyplňovat formuláře? Vogoni by s tím pravděpodobně souhlasili

[s0]

snad nevynesu tajemství, ale jeden zásadní systém se to Vogon opravdu jmenuje ;)

[Ladicek]

Ale jo, já taky píšu gettery a settery rovnou (teda nepíšu, mačkám Alt+Insert, volím Getters and Setters, označuji všechny proměnné a mačkám Enter ). Jenom se mi nezdá ta šílená námaha s předěláváním veřejné proměnné, to za mne snadno může udělat IDE.

[Ladicek]

Teda formuláře nevyplní, to je pravda. Ovšem v takovém případě víc než kdy jindy platí, že nejlepší kód je žádný kód (Jdeme dělat dřevorubce do Kanady.)

[Miloslav Ponkrác]

Dotaz: Jak moc jste zkušený a zběhlý v C++, když se ptáte co jde a co ne? Já třeba když si stáhnu balík JDK od Sunu, žádný refaktoring tam nevidím. Ani žádné IDE.

Jinak pro Vaší informaci, zrovna teď jsem v C++ refaktoroval velký projekt, kde stejné identifikátory se vyskytovaly v mnoha souborech. A IDE to zvládlo na jedno kliknutí. Mé IDE pro C++ refaktoring umí. Takže v něčem děláte soudruhu z NDR chybu.

[Ladicek]

Ale houbeles. To předřečníci mluvili o tom, že se jim fakt nechce do celodenní práce, o které já vím, že ji může udělat IDE. A protože C++ nepoužívám, tak samozřejmě nevím, jaké refaktorovací nástroje pro ně jsou. Nikde jsem ale nenapsal, že nejsou.

[Ladicek]

Jenom se mi nezdá ta šílená námaha s předěláváním veřejné proměnné

Možná jste špatně pochopil tohle. Myslel jsem to tak: nezdá se mi, že předělat veřejnou proměnnou na soukromou + sadu přístupových metod je nějaká šílená námaha, je přece jasné, že tohle může udělat IDE.

[Miloslav Ponkrác]

Máte pravdu, nenapsal. Omlouvám se.

[Ladicek]

V pořádku. Já když jsem naposled viděl Visual Studio (žádné jiné C++ IDE neznám), tak se chlubili s tím, že konečně umějí Extract Method, takže jsem naivně předpokládal, že ty refaktoringy pro C++ ještě nebudou na takové úrovni, jako mi pro Javu nabízí IDEA Dobré vědět, že se pletu.

[alblaho]

Není nic odpornějšího než hromada vygenerovaného kódu, který nic nedělá který tam pak cloní. Fuj.

[Ladicek]

No jistě, já s tím souhlasím. Ale rozhodně se kvůli tomu nezblázním a nezačnu konvertovat produkční kód do Pythonu jenom proto, že mám na striktně izolovaných místech hromadu getterů a setterů, které momentálně nic nedělají.

[alblaho]

Jo? A jak té striktní izolace dosahuješ? Osmdesáti lomítkama?-)

Já prostě nemám rád to zaklínání tím IDE. Já používám Gedit, ty Ideu . Já nemačkám ctrl+space, ale rozmýšlím si, co píšu. Výhodou je, že když toho napíšu míň, nemusím toho tolik číst. Já vím, že jsi Lisper, tak nemá cenu ti o tom psát.

Stejně tak ten IDE refaktoring. Ono ve statických jazycích s příčetnou gramatikou (tedy Java, ale asi ne C++ to funguje hezky, do té doby, pokud máš celou codebase otevřenou najednou v tom IDE. Nebo dokud tam nemáš reflexi. Prostě se mi zdá, že obhajovat rozbourání intefacu tím, že to přece dvouma kliknutíma zrafaktoruju, není moc šťastné.

[Ladicek]

Jo? A jak té striktní izolace dosahuješ? Osmdesáti lomítkama?-)

Třeba tak, že mám celou definici třídy v jednom souboru

Já prostě nemám rád to zaklínání tím IDE. Já používám Gedit, ty Ideu . Já nemačkám ctrl+space, ale rozmýšlím si, co píšu.

Ne že bych já nerozmýšlel. Ale když mám rozmyšleno, ten přebytečný kód za mne namlátí editor sám, takže toho oba ve výsledku ručně napíšeme přibližně stejně.

Stejně tak ten IDE refaktoring. Ono ve statických jazycích s příčetnou gramatikou (tedy Java, ale asi ne C++ to funguje hezky, do té doby, pokud máš celou codebase otevřenou najednou v tom IDE. Nebo dokud tam nemáš reflexi. Prostě se mi zdá, že obhajovat rozbourání intefacu tím, že to přece dvouma kliknutíma zrafaktoruju, není moc šťastné.

Štastné to určitě není, naopak je to velmi nešťastné, proto přece ty gettery a settery generuju, i když možná trochu znepřehledňují zdroják té jedné třídy. Ale prostě považuju za nesmyslné ty řeči, že opravit to trvá celý den. Pravda, když to rozhraní používá někdo, nad kým nemám kontrolu, tak mi IDE z průseru nepomůže.

[Miloslav Ponkrác]

Ne že bych já nerozmýšlel. Ale když mám rozmyšleno, ten přebytečný kód za mne namlátí editor sám, takže toho oba ve výsledku ručně napíšeme přibližně stejně.

Mě jen nejde na rozum, proč někdo používá jazyk, který potřebuje, aby editor generoval kódy. Přeci dobře navržený jazyk má takovou syntaxi a takový syntaktický cukr, aby výraznější pomoc nějakého generátoru nepotřeboval. Mám pocit, že dobře navržený jazyk se pozná mimo jiné tak, že rozdíl efektivity programátora píšícího vše ručně a programátoru, kde mu editor v běžných sekvencí pomáhá generováním je přibližně stejná. Pokud je člověk s generátorem v IDE rychlejší, je to špatně navržená syntaxe programovacího jazyka.

[deda.jabko]

jasne -- Scheme rulez! (a CommonLisp taky) ;-]

[Radek Miček]

Ja myslim, ze Haskell rulez

[Ladicek]

Hm. Podle mne jazyk má v první řadě optimalizovat na čtení, až poté na psaní. Jak už jsem řekl výše, přebytečný kód se mi nijak nelíbí, ale jsem schopný s ním žít, protože mi ten život vývojové prostředí o dost usnadňuje. A pokud je nějaký kód přebytečný proto, že je to výhodné do budoucna a přitom to v současnosti prakticky nic nestojí (třeba ty gettery a settery), tak ho prostě napíšu.

Jo, uznávám, že nepoužívám ideální jazyk. Dokonce uznávám, že dost možná nepoužívám ani dobrý jazyk. Používám průměrný jazyk a znám hned několik lepších. Ale upřednostnit průměrný jazyk před nadprůměrným má v té pitomé komerční praxi taky jisté výhody.

[Miloslav Ponkrác]

Já bych řekl, že programovací jazyk se má především optimalizovat na programování.

Já nekritizuji žádný konkrétní jazyk, ale programovací jazyk, který by k efektivitě potřeboval generování kódu z IDE bych si dobrovolně nikdy nevybral. Takový jazyk je horší na čtení i psaní obvykle.

Ideální jazyk neexistuje, a protože existuje komerce píšu "dobrovolně nevybral", jinak pokud je potřeba píšu v leččems.

[Filip Jirsák]

Takže dobře navržený jazyk má pro jednu konstrukci (čtení/nastavení hodnoty) dva naprosto odlišné způsoby zápisu? Jednou jako „property“, pokud jde o jednoduchý případ, a podruhé přes „getter/setter“, pokud je to nějak složitější (kontrola práv, validace, výjimky, události…)? To se mi tedy moc nezdá…

[thingie]

Hlavně set metoda je zbytečná. A operátor = vlastně taky. Přepisovatelné proměnné? Pche.

[trekker.dk]

- A je to polymorfní? - Jo.
- Luminokinetické? - Jo.
- Fluorescenční? - Jo.
- A je to taky k něčemu dobrý? - Asi ne.

[finc]

Ty jsi nikdy nenapsal zbytecny kus kodu? Ja ano a kolikrat o tom ani nevim :D

[zde]

C++ je omyl. Bohužel stihl zapustit kořeny.

[Miloslav Ponkrác]

A čímpak byste C++ nahradil? Představte si, že chcete programovací jazyk, ze kterého po kompilaci vyleze program s efektivitou blízkou assembleru za použití high level věcí, kde můžete mít vše pod kontrolou do posledního detailu, pokud o to stojíte, a přitom má za dané situace nejnižší náklady na vývoj. Právě díky potřebě takového jazyka Stroustrup C++ stvořil, a žádný jiný jazyk v této oblasti, který by ho zastoupil neexistuje. Proto zapustil kořeny.

Můžeme se bavit o tom, zda v některých případech není vhodnější použít jiný jazyk, než C++, ale rozhodně náhrada za C++ není. C++ nemá konkurenci, a proto má budoucnost, a proto zakořenil.

[zde]

> A čímpak byste C++ nahradil? Představte si, že chcete programovací jazyk, ze kterého po kompilaci vyleze program s efektivitou blízkou assembleru

Slyšel jste už o C? To je něco jako C++ s tím rozdílem že je to portabilní a mnohem častěji to i funguje BTW to že splácaninu která JENOM pro své interní jazykové úchylnosti potřebuje megabajtovou libstdc++.so nazýváte "jazykem s efektivitou blízkou asembleru" považuji za velmi podařený vtip.

> za použití high level věcí, kde můžete mít vše pod kontrolou do posledního detailu, pokud o to stojíte,

"kontrola do detailu" sice není to co většina programátorů potřebuje, ale i tak nemáte pravdu. C++ spoustu věcí dělá po svém, a programátor mu to nijak nevymluví. Chcete si sami nějak rozumě pojmenovat globální symboly? Máte smůlu. Chcete volat destruktory objektů na stacku podle vlastního uvážení, a nikoliv na konci scope? Máte smůlu. Chcete raisovat výjimku v konstruktoru? Máte smůlu. Chcete ovládat layout VMT? Máte smůlu. Chcete určit, do kterého compile unitu se mají vygenerovat instance templatů a metadat? Máte smůlu. C++ si buď vše dělá po svém (a obvykle blbě), nebo na to zavádí různé neportabilní konstrukce.

> a přitom má za dané situace nejnižší náklady na vývoj.

Pokud byl někdo truhlík a celou codebase má v C++, tak je zjevné že z krátkodobého hlediska je opravdu nejlevnější zacpat nos a tu hromadu hnoje dál přehazovat vidlema. To ale nic neříká o tom jestli je to dobrý jazyk nebo ne.

> Právě díky potřebě takového jazyka Stroustrup C++ stvořil, a žádný jiný jazyk v této oblasti, který by ho zastoupil neexistuje. Proto zapustil kořeny.

Kdepak. Prostě jen bylo v módě "objektové programování", hodně lidí trochu umělo C, a Stroustrup toho využil. Hackeři samozřejmě věděli že OOP je pouze další paradigma, které souvisí s PROGRAMOVÁNÍM, a nikoliv přímo s JAZYKEM. Proto dál spokojeně používali osvědčené C, Lispy, Bashe, a Perly, a o C++ se příliš nezajímali. Nestihli tudíž s dostatečným předstihem varovat ty nešťastníky, kteří se chystali C++ naučit a používat, což později logicky vedlo ke katastrofě.

Dále Stroustrup použil známý špinavý trik, známý jako "Embrace, extend and extinguish"- namluvil všem že C++ je kompatibilní s C. Student pak nabyl dojmu, že když se naučí C++, bude umět i C, že jde o sázku na jistotu. Bohužel studium C++ mu mezitím nevratně poškodilo mozek, takže začal C++ featury vyžadovat. Stal se rukojmím, takže výrobci toolchainů, class libraries, a všech možných komponent museli nedobrovolně poskytovat i C++ binding. Kruh se uzavřel, a cesta zpátky neexistuje.

> C++ nemá konkurenci, a proto má budoucnost, a proto zakořenil.

BS. C++ je jednoznačně na ústupu (díky bohu).

[Miloslav Ponkrác]

Slyšel jste už o C?

C nesplňuje tu podmínku o nízké ceně vývoje. Stejný problém (od středně velkého rozsahu výše) napíšete v C++ několikanásobně rychleji (pro neznalé uvádím, že to znamená několikrát míň peněz vražených do vývoje). Navíc C přinese jen a jen nevýhody - a ani Vy sám nebudete schopen zdůvodnit, co C přinese navíc oproti C++ - ale řeknu to za Vás - přinese navíc spoustu problémů, dražší vývoj a jen nevýhody. Neexistuje žádná skutečná výhoda C oproti C++, nenajdete jí.

která JENOM pro své interní jazykové úchylnosti potřebuje megabajtovou libstdc++.so

Kde je problém? I kdyby potřebovala stomegabajtovou .so, kromě Vašich komplexů nevidím sebemenší potíž.

Pokud byl někdo truhlík a celou codebase má v C++, tak je zjevné že z krátkodobého hlediska je opravdu nejlevnější zacpat nos a tu hromadu hnoje dál přehazovat vidlema. To ale nic neříká o tom jestli je to dobrý jazyk nebo ne.

Argument by nebyl? A co ty lysohlávky přestat brát?

Kdepak. Prostě jen bylo v módě "objektové programování", hodně lidí trochu umělo C, a Stroustrup toho využil. Hackeři samozřejmě věděli že OOP je pouze další paradigma, které souvisí s PROGRAMOVÁNÍM, a nikoliv přímo s JAZYKEM. Proto dál spokojeně používali osvědčené C, Lispy, Bashe, a Perly, a o C++ se příliš nezajímali. Nestihli tudíž s dostatečným předstihem varovat ty nešťastníky, kteří se chystali C++ naučit a používat, což později logicky vedlo ke katastrofě.

Zase žádný argument, prostě nemáte co říct. Já bych Vám doporučoval nakoupit metrák česneku a potírat se jím, kdykoli slyšíte slovo C++. A v případě, že byste na C++ jen pomyslel, pak bych nasadil 20x otčenáš. A samozřejmě bych na Vašem místě vstoupil do politiky a usiloval o zákaz C++ přímo zákonodárně. Přeci, kdo jiný může spasit svět od zla C++, když ne Vy? Je jen na Vás jestli zachráníte svět od nezvratné zkázy, za kterým čeká jen spáleniště a měsíční krajina.

C++ je jednoznačně na ústupu (díky bohu).

C++ ustoupilo z pozic, kde je vhodnější použít high level jazyk. Nicméně, že tu s námi zůstane, to si buďte jistý. A rozhodně spíše C++ zabírá pozice Céčku, než cokoli jiného.

[Let_Me_Be]

Prosimte kasli na nej. U kazdeho clanku/zpravicce/blogpostu o C++ si musi lecit svoje mindarky.

Psat v dnesni dobe cokoliv v Cecku je hola pitomost a delaji to jenom ti, co se nebyli schopni naucit C++, nebo ti co pogramuji jednocipy.

[zde]

Myslím že pokud jde o vlastnosti jazyka, znám C++ zhruba stejně jako pan Ponkrác. Rozdíl je jenom v tom že on ho používat musí, a já nemusím. Nedivím se že má C++ rád. Člověk tíhne k tomu, že si na nevyhnutelné věci rychle zvyká. Ulehčuje to život. Když se někdo naučí mít rád atomovou bombu, proč by nemohl mít rád C++ ?

[Miloslav Ponkrác]

Já si mohu jazyk svobodně volit podle svého - a na low level věci jsem nenašel nic lepšího. Používal jsem jazyk C, pak jsem rád, dobrovolně a svobodně přešel na C++ a nikdy jsem nelitoval. Přemýšlím zkusit ještě Adu, ten jazyk vůbec není špatný.

[alblaho]

Ada je naprosto úžasný jazyk, jeho typový systém nemá konkurenci a na procedurální superspolehlivé programy je to super.

Ale je to neskutečně těžkopádné a "verbose", prostě milion slov. Ve výsledku je to hezky čitelné, to jo, ale napsat to dá fakt práci.

Druhá věc je objektový systém - ten je tam odporně domidlený, mlátí se to tam se systémem balíků, no fakt ošklivé. Nejsou tam rozhraní (ani vícenásobná dědičnost), což taky vede k problémům.

No a práce s řetězci je taky humus. Knihovní funkce používají statické stringy jako pole znaků, ale k běžné práci je lepší Unbounded_String, který je natahovací - takže ve výsledku pořád konvertujete.

Pokud bych psal něco s extrémními nároky na kvalitu (třeba soft do raketoplánu, nebo kritickou síťovou službu), tak klidně. Ale pro běžný aplikační soft je to neuvěřitelně těžkopádné.

Líbí se mi tam generický systém - z C++ templates mi běhá mráz po zádech, v Adě je to docela jednoduché a přitom výkonné.

[Miloslav Ponkrác]

Díky za skvělé informace, opravdu dík.

[trekker.dk]

Psat v dnesni dobe cokoliv v Cecku je hola pitomost a delaji to jenom ti, co se nebyli schopni naucit C++, nebo ti co pogramuji jednocipy.

A jádra.

[Let_Me_Be]

Tam bych take v dnesni dobe sahal spise po C++ oklestenem o vyjimky. Cecko je v Open Source projektech pouzivano prevazne z historickych duvodu (a take proto, porotoze se z nejakeho duvodu spousta lidi nedokaze naucit C++).

[Miloslav Ponkrác]

Já sice bych si vybral C++ s výjimkami, ale na to m nesejde. Céčko je používáno historicky, a také proto, že spousta lidí C++ nezvládá - třeba Linus Torvalds, který o něm napsal takové ptákoviny, že kdyby nebyl slavný, sklidil by posměch.

[elviin]

Linus Torvalds se uz tak extremne o C++ nevyjadruje, viz toto video.

[zde]

Spíš ho už přestalo bavit ztrácet tím čas.

[Miloslav Ponkrác]

Mě je úplně jedno, jak se Linus Torvalds vyjadřuje o C++, protože o něm neví nic a nazvládá ho. Jeho parketa je jinde, je odborník na jiné věci a jenom jeho nesoudnost ho nutí vyjadřovat se k věcem, kterým nerozumí. Je zbytečné ztrácet čas hledáním rozumů od někoho, kdo nezvládá danou věc.

Linuse Torvaldse uznávám, vážím si ho, v mnoha věcech hodně dokázal a je ho za co obdivovat. Skláním před ním klobouk, je to machr. Nicméně co se mi na něm nelíbí je jeho snaha kecat do věcí, kterým nerozumí ani za mák, a C++ je jednou z nich (a ne jedinou).

[trekker.dk]

Otázka je, co by ti C++ při programování jádra dalo navíc.

[Miloslav Ponkrác]

Minimálně toto:

1) Možnost OOP a lepšího uspořádání kódu. Právě, že kernel je přirozeně přímo dělán na OOP - v zásadě systémové prostředky počítače jsou přirozené objekty, ovladač se dá napsat pohodlně jako třída, atd..

2) Lepší architektura kódu, přehlednější kód, který se lépe upravuje.

3) Lepší spolupráce mnoha lidí na OS (což je pro vývoj OS typické) - díky objektům a namespaces nedochází ke konfliktům identifikátorů v rozsáhlých projektech, díky přístupovým právům v objektech kompilátor vychytá neoprávněné použití dat jinými programátory.

4) Možnost použití výjimek, protože kernel tak jako tak výjimky obsluhuje (různá přerušení), a proč to nezobecnit.

[trekker.dk]

ad 1) V jádře se OOP používá.

ad 2) To je vcelku subjektivní

ad 3) Nezdá se mi, že by k podobným problémům docházelo

[Miloslav Ponkrác]

ad 1) OOP se sice používá, ale je to pouze emulace skutečné OOP syntaxe.

ad 2) To jsou jen zkušenosti, byť to vypadá subjektiuvně.

ad 3) Dochází. V C potřebujete proscanovat celý projekt, abyste zjistili, zda daný (globální) identifikátor nepoužívá někde něco jiného. U většího projektu je to dost nepříjemné. A ohledně možnosti, že Vás kompilátor klepne přes prsty, když používáte co nemáte díky právům, to velmi omezuje možnost chyb a zrychluje vývoj.

Ještě k ad 3) Linux kernel tyto problémy zdánlivě nemá, protože neplatí vývoj. Kdyby jakákoli firma vyvíjela sw stejně efektivně jako se vyvíjí Linux kernel, dávno by zkrachovala. Poměr výkon/cena_vývoje, nebo kvalita/cena_vývoje, pokud bychom skutečně zpoplatnili cenu všech vývojářů nějakou standardní hodinovou taxou by byl u Linux kernelu velmi špatný. Proto také tyto problémy Linux kernel zdánlivě "nemá", protože se nemusí ohlížet na cenu vývoje, a tak spoustu hodin navíc, který stráví tisíce vývojářů řešením hledání chyb, který by v C++ odhalil při kompilaci díky právům a další výhody C++ je nijak netrápí. Vývojářům Linux kernelu je jedno, zda vyvíjí časově a nákladově efektivně - jestli vývojář na daném úkolu stráví sto hodin, nebo pět set - nikoho to netrápí. Proto bych Linux kernel a přínos jazyků hodnotil zde u Linuxu opatrně.

[Let_Me_Be]

1) ano, pouziva. Naprosto uchylnym a ujetym zpusobem.

Jinak jeste bych k 1) 2) a 3) pridal mnohem lepsi potencial generovani rychleho kodu vuci Cecku. Cecku proste chybi sablony a reference.

[zde]

..potencial generovani rychleho kodu.. Cecku proste chybi sablony a reference.

1) Šablony jsou jenom způsobem jak psát podobný kód jen jednou, a přitom držet typovou kontrolu. Ušetří tedy programátorovi trochu práce (resp před ním zakryjí code bloat, který jeho "elegantní" konstrukce vygeneruje, takže zmizí důležitá zpětná vazba a programátor se urve z řetězu), ovšem za žádných okolností kód neurychlí.

2) Reference jsou čistokrevný syntaktický cukr, jehož jediný efekt je že programátor méně často ťuká do klávesy '&'. Na výsledný kód to nemá nejmenší vliv, takže opět nemáte pravdu.

[Miloslav Ponkrác]

ad 1) Tedy dělat ze sebe vola takhle veřejně a psát takové nesmysly už chce odvahu. Omlouvám se za tuhle ostrou větu, ale ono to jinak nejde.

[zde]

Mirku, neomlouvej se. Úplně mi bude stačit když pro změnu budeš chvilku mluvit k věci.

[Let_Me_Be]

Boze to fakt nema cenu Ja nechapu jak ze se sebe nekdo muze delat takoveho idiota.

Na jednicku nebudu reagovat a pokud nevidis rozdil mezi konstatnim pointerem a referenci, tak se bez uz konecne nekam zahrabat.

[zde]

pokud nevidis rozdil mezi konstatnim pointerem a referenci, tak se bez uz konecne nekam zahrabat.

Na sémantické úrovni tam žádný rozdíl není, ergo to nemůže mít vliv na výkon.

[Miloslav Ponkrác]

Jsou tam minimálně dva rozdíly:

1) Reference nemůže změnit objekt, na který odkazuje.

2) Reference nemůže obsahovat neplatný pointer.

Tím kompilátor může optimalizovat o krapítek víc, než v případě pointerů. Například vyhnout se testu na NULL, protože reference tuto hodnotu vnitřně nesmí obsahovat. Stejně tak i ta konstantnost jisté možnosti optimalizací také umožňuje.

[zde]

1) Zřejmě jste chtěl říct, že reference je konstantní, tj ukazuje na stále stejný objekt. To konstantní pointer taky.

2) Reference být nevalidní (obsahovat NULL) zjevně může, protože test na její nenulovost se evidentně vyhodnocuje (g++4.1.1 -O3) teprve za runtime.

int hovnocuc(int &a) {
  return &a ? a : 0;
}

00000000 <_Z8hovnocucRi>:
   0:   55                      push   %ebp
   1:   31 c0                   xor    %eax,%eax
   3:   89 e5                   mov    %esp,%ebp
   5:   8b 55 08                mov    0x8(%ebp),%edx
   8:   85 d2                   test   %edx,%edx
   a:   74 02                   je     e <_Z8hovnocucRi+0xe>
   c:   8b 02                   mov    (%edx),%eax
   e:   5d                      pop    %ebp
   f:   c3                      ret

[Miloslav Ponkrác]

Chtěl bych Vás upozornit na rozdíl mezi slovy "C++" a "g++". To, že něco špatně dělá g++, neznamená, že to pšatně dělají všechny C++ kompilátory. Mimochodem, gcc a g++ špatně optimalizují z hlediska efektivity výsledného zdrojového kódu, takže jestli můžu poprosit, buď předveďte výsledek z kvalitně optimalizujícího kompilátoru, nebo u gcc like věcí o optimaizaci nemluvte, není to moc na místě.

[zde]

No, aspoň jsem se konečně dočkal upřesnění toho, co "považujete za plevy". Když je G++ pleva, co podle vás plevou není, překládá to C++ zdrojáky, a produkuje ten "správný" certified by Ponkrác (tm) kód? Mimochodem, tenhle přístup (C++ jako takové je kewlultrašpica, za všechno špatné můžou jenom jeho chybné implementace) mi připomíná argumentaci kovaných komunistů. :) :) :)

[Let_Me_Be]

const je v Cecku ciste semanticka zalezitost. Reference je identita coz umoznuje uplne jinou uroven optimalizaci. To ze na to nektere kompilatory dlabou je jina vec.

[zde]

Můžete mi upřesnit rozdíl mezi "identitou" a referencí? Dobře, mám C++ funkci, která bere referenci. Jestli dělá cokoliv jen trochu komplikovaného (tj volá libovolnou non-pure funkci, nebo dereferuje pointer na objekt stejného typu, jako je ten argument), musí nutně počítat s tím že díky aliasingu modifikuje ten argument- takže NEMŮŽE optimalizovat o nic víc než kdyby dostala obyčejný konstantní pointer. Prostě v C i C++ je pointer a identita jedna a ta samá věc.

[happy barney]

int * a = (int *) 1234;
int &b = *a;
b++;

zaujímavé ... segfault ako vyšitý

[Miloslav Ponkrác]

A tohle v C taky neprojde dobře:

#include <stdio.h>
#include <string.h>

int main()
{
  void* ptr = printf;
  memset(ptr, 0, 100000);
  return 0;  
}

Dotaz: Co chcete dokázat?

[happy barney]

to bola reakcia na:
2) Reference nemůže obsahovat neplatný pointer.

[Miloslav Ponkrác]

Nemůže, pokud jí tam hackersky nedodáte. Podle normy C++ dokonce nesmí, a pokud se rozhodnete stůj co stůj do reference neplatný pointer dostat, pak je chování neurčeno. Kompilátor v klidu může počítat s tím, že reference obsahuje vnitřně vždy platný pointer na platný objekt a optimalizovat podle tohoto faktu.

Když budete chtít, program si rozbouráte vždycky. Vždycky jde přepsat třeba kód funkce main, nebo alespoň zásobník procesu či threadu. Vždycky jde náhodně přepisovat lokální proměnné o tři funkce na call stacku výše, či cokoli dalšího. Nicméně kompilátor ani program to nevychytá.

[alblaho]

No tak přepište main v Javě.

Já jsem Vás odhalil. Vy nejste programátor, vy jste bürokrat. Ono je hezké, že v normě je napsané, že reference musí být vždy platné. Nicméně dokud budou v C++ i obyčejné pointery, tak jazyk v praxi nic takového nezaručí.

[Miloslav Ponkrác]

Ale ony v praxi jsou vždy platné. Není důvod, proč by tomu mělo být jinak.

[happy barney]

jeden by sa našiel: nemeckí programátori

[zde]

Kompilátor v klidu může počítat s tím, že reference obsahuje vnitřně vždy platný pointer na platný objekt a optimalizovat podle tohoto faktu.

Mimochodem, od kdy dělá překladač implicitní testy na neplatné pointery? Jsem myslel že segfaulty generuje CPU případně MMU, a to úplně zadarmo...

[zde]

Nemůže, pokud jí tam hackersky nedodáte. Podle normy C++ dokonce nesmí, a pokud se rozhodnete stůj co stůj do reference neplatný pointer dostat, pak je chování neurčeno.

Píšete nesmysly. NULL reference vznikne úplně snadno, žádný "hackerský" zásah není potřeba. Třeba tohle chybně naprogramované procházení linked listu. Když se uvnitř funkce hovnocuc přečte ukazatel na další node, nedělá se ŽÁDNÁ kontrola jestli je validní, a klidně se to pošle jako reference do další iterace.

struct node { node *next; };
void hovnocuc(node &arg) {
    hovnocuc(*arg.next);
}

00000000 <_Z8hovnocucR4node>:
   0:   55                      push   %ebp
   1:   89 e5                   mov    %esp,%ebp
   3:   83 ec 04                sub    $0x4,%esp
   6:   8b 45 08                mov    0x8(%ebp),%eax
   9:   8b 00                   mov    (%eax),%eax
   b:   89 04 24                mov    %eax,(%esp)
   e:   e8 fc ff ff ff          call   f <_Z8hovnocucR4node+0xf>
  13:   c9                      leave
  14:   c3                      ret

A netvrďte mi že je to tím že G++ je "pleva". Dělat early check na NULL pointer je krajně neefektivní, a pochybuju že to jakýkoliv C++ překladač bude dělat. To že je to idiotský jazyk ještě neznamená, že implementace dělají jen idioti.

Kompilátor v klidu může počítat s tím, že reference obsahuje vnitřně vždy platný pointer na platný objekt a optimalizovat podle tohoto faktu.

Ja vidíte, nemůže.

[trekker.dk]

A na druhou stranu má C++ zase nevýhody; například jsem u něj narazil na různě omezená přetypování ukazatelů.

[Miloslav Ponkrác]

Což je obrovská výhoda snižující možnost zavlečení obtížně hledatelných chyb.

V C++ jinak můžete přetypovat ukazatele na co chcete stejně jako v C. V tom není C++ omezeno. Jediná změna je, že automaticky se nepřetypovává void* na jakýkoli jiný typ - ale lze mu to přikázat zápisem. A tuto změnu vnímám jen a jen pozitivně, protože se tím drasticky omezuje možnost chyb, které můžete týden hledat, než na ní přijdete.

[trekker.dk]

Což je obrovská výhoda snižující možnost zavlečení obtížně hledatelných chyb.

To je asi pravda, nicméně pokud vím, že tohle přetypování udělat můžu a ušetří to kód/velikost binárky/čas CPU, ale překladač mi ho zakáže, tak se budu vcelku oprávněně rozčilovat. Zvlášť ve chvíli, kdy pracuju na obsluze přerušení a chci ji udělat co nejefektivněji.

V C++ jinak můžete přetypovat ukazatele na co chcete stejně jako v C.

Narazil jsem na nějaké přetypování, které šlo v C, ale když jsem to převedl do C++, tak překladač házel chybu. Pamatuju si, že v tom byly zapletené ukazatele, ale o co přesně šlo, to bych musel dohledat.

[Let_Me_Be]

Narazil jsem na nějaké přetypování, které šlo v C, ale když jsem to převedl do C++, tak překladač házel chybu. Pamatuju si, že v tom byly zapletené ukazatele, ale o co přesně šlo, to bych musel dohledat.

To bych opravdu chtel videt. Ceckove pretypovani by rozhodne melo fungovat zcela identicky v C++. Obcas je nutne pouzit kombinaci pretypovani, ale rozhodne neexistuje nic, co by neslo pretypovat.

[Miloslav Ponkrác]

Pokud přetypování můžete udělat v C, můžete ho udělat i v C++. Navíc přetypování ukazatelů ani v C, ani v C++ nemění velikost binárky, ani čas CPU (bavíme se o statickém přetypování neobjektových typů, nebo objektových typů bez vícenásobné dědičnosti).

Překladač Vám žádné možné přetypování ani v C ani v C++ nezakáže, pokud mu to ve zdrojovém kódu předepíšete. Výsledný kód / velikost binárky / čas CPU - tyto parametry lezou z C a C++ zdrojového kódu zcela shodně ve stejných číslech.

[trekker.dk]

Překladač Vám žádné možné přetypování ani v C ani v C++ nezakáže, pokud mu to ve zdrojovém kódu předepíšete.

V tom případě jsem si tu hlášku, co začínala Error, asi špatně vyložil. Podotýkám, že ten zdroják v C přeložit šel, pak jsem přejmenoval .c na .cpp a pustil na to překladač C++. Nic víc, ale prostě se nepřeložilo.

[happy barney]

C++ oproti C má viac rezervovaných kľúčových slov, je možné i to, že definícia typu obsahovala jedno z týchto slov. (bez konkrétnej chybovej hlášky či príkladu je zbytočné sa o tom baviť)

[zde]

Taky si myslím, že když funkční "C" zdroják nešel přeložit pod C++, nebylo to vinou toho že C++ nepovolilo nějaké explicitní přetypování. Mě obvykle C++ dostane tím že nepovoluje implicitní "int" jako návratovou hodnotu nebo jako typy argumentů, a že nerozlišuje namespace pro "struct/union/enum/typedef". Předělat kód z "C" do "C++" je ale obvykle docela snadné. Naopak je to mnohem horší :(

[Miloslav Ponkrác]

Pokud potřebujete aby kompilátor doplnil za Vás implicitní int návratovou hodnotu a jste líný si tam to int napsat ručně, tak jste prase.

Jinak ve starších C kompilátorech se dalo narazit tak, že on nerozlišovat ani položky struct/union mezi strukturami, takže při definice

struct a
{
  int x;
};

struct b
{
  int x;
};

došlo k chybě při překladu, protože položka x byla deklarována ve dvou strukturách, a kompilátor měl všechny položky struktur v jednom namspace bez ohledu na tom, v jaké struktuře leží.

Ono se vůbec v C dělaly v kompilátoru takové prasárny, jen aby se ušetřil a zjednoudšil kompilátor, že byste se divil. Blbé je, že vypuštěného čerta už do krabice nezavřeš, a řada platform má kompilátory C takové kvality, že by člověk zvracel. Jde zejména o minoritnější platformy, jako méně používané jednočipové procesory, či podobně.

Stejně tak jako napsat kód:

struct a
{
//...
};

union a
{
//...
};

který v C projde je znakem programátorského prasete a osobně můžu říci, že jsem se s tímto typem prasečiny ještě nesetkal za cca 20 let, co mi prošly rukama C kódy od obrovského množství lidí. Ale musím říci, že jednou jsem dostal do ruky C kódy, které měly cca 50 KB a luštil jsem je 14 dní, než jsem pochopil co dělají, ale to byla extrémní výjimka. Ten člověk byl světoznámý tím, že je prase, a že jeho kódy jsou read only. Mimochodem je to Čech. Jeho kódy jsou betonově spolehlivé, ale neudržovatelné.

[Filip Jirsák]

Mě jen nejde na rozum, proč někdo používá jazyk, který potřebuje, aby editor generoval kódy. Přeci dobře navržený jazyk má takovou syntaxi a takový syntaktický cukr, aby výraznější pomoc nějakého generátoru nepotřeboval. Mám pocit, že dobře navržený jazyk se pozná mimo jiné tak, že rozdíl efektivity programátora píšícího vše ručně a programátoru, kde mu editor v běžných sekvencí pomáhá generováním je přibližně stejná. Pokud je člověk s generátorem v IDE rychlejší, je to špatně navržená syntaxe programovacího jazyka.

Pokud potřebujete aby kompilátor doplnil za Vás implicitní int návratovou hodnotu a jste líný si tam to int napsat ručně, tak jste prase.

Tak správně je syntaxe, kde programátor píše co nejmíň a není žádný kód, který může automaticky vygenerovat editor, zároveň má programátor napsat co nejvíc, aby si kompilátor nemusel nic domýšlet. Nejsou to trochu protichůdné požadavky?

[Miloslav Ponkrác]

Tak správně je syntaxe, kde programátor píše co nejmíň

a není žádný kód, který může automaticky vygenerovat editor

Tato dvě tvrzení se vzájemně neimplikují, a Vy jste na této implikaci založil celý závěr. Já tvrdím, že syntaxe má být taková, abyste psal do zdrojového kódu pouze užitečné informace, přičemž to nutně neznamená, že programátor píše co nejmíň.

Důležité je, že IDE generátor je hlupák a nic kreativního, ani inovativního nevymyslí - tudíž pokud programovací jazyk něco takového do zápisu vyžaduje, pak je to vítězství byrokracie a formy nad účelem jazyka.

A hlavně jsem napsal, že pokud je zkušený programátor v jazyce J výrazně rychlejší za pomoci IDE generátoru, než při ručním psaní bez něj, pak je to špatná syntaxe jazyka J.

Nezdá se mi, že užitečná informace - to jest trvání kompilátoru na uvedení návratové hodnoty funkce - která umožní ušetřit hodiny času následně na zjišťování, proč mi program jede špatně abych následně zjistil, že funkce vrací jinou návratovou hodnotu, než chci, a protože jsem jí ve čtyři ráno zapomněl předepsat (to už moc nevidím) a kompilátor to sežral - je věc, která by odporovala mému tvrzení o výkonnosti jazyka.

[Filip Jirsák]

IDE generátor vygeneruje nějaký default. To se vám nelíbí. Zrušení defaultů je nesmysl (těžko zakážete, že nějaká konstrukce se bude používat nějakým typickým způsobem), takže zbývá varianta, že si default domyslí kompilátor. A to se vám taky nelíbí.

Buď jazyk něco po programátorovi striktně vyžaduje napsat (typ návratové hodnoty funkce, implementaci setteru) – takhle to dělá třeba Java, a pak zákonitě IDE nabízí podporu pro vygenerování typických případů. Nebo to nevyžaduje, použije nějaký default (jako C u návratového typu funkce nebo Python u setterů) – pak ale hrozí chyby spočívající v tom, že jsem někde default zapomněl přepsat. Jaká je třetí cesta, která by se zřejmě líbila vám, mi není jasné.

[Miloslav Ponkrác]

Vygenerování defaultu není věc, která by výrazně urychlila vývoj oproti ručnímu psaní - nemáte-li blbý jazyk.

Java bohužel nepotřebuje IDE generování proto, že by vyžadovala typ návratové hodnoty, ale proto, že je tak omezená a očesaná, že pro efektivitu programování v Javě je IDE generování životní nutnost. Java je případ, kdy se stále všechno emuluje pomocí omezených syntaktických prostředků Javy.

Znovu říkám, návratový typ funkce typu int - tedy čtyři písmena i s mezerou napíšu pod půl sekundy, a těchto půl sekundy není nic, co by mě zpomalilo. Děláte z prdu kuličku, abych to řekl natvrdo.

Pokud postavíte svá tvrzení na tom, že musíte psát slovo int u některých funkcí, pak si asi neporozumíme. V tom případě bych debatu vzdal pod heslem moudřejší ustoupí.

[Filip Jirsák]

Takže efektivita jazyka pro programátora záleží na tom, jak krátká má klíčová slova? V tom případě musí být Perl přímo geniálně efektivní jazyk.

[Miloslav Ponkrác]

Nasazuji pro tento thread variantu moudřejší ustoupí. Tohle nemá smysl.

Poslední informace: Vezměte jazyk J a cílem naprogramovat netriviální program P. Programujte v něm za a) s IDE generátorem a za b) ve stejném jazyce J stejný program programujte bez IDE generování zdrojáku. Pokud se časy a) a b) výrazně liší pro stejně zkušeného programátora ve prospěch výrazně nižšího času při variantě a), pak tvrdím, že jde o špatně navrženou syntaxi.

Jinak toto je má poslední reakce na tento thread, jak už jsem psal.

[happy barney]

lol, prečo spomínate Perl ako príklad všetkoho zlého? ) Veď základné kľúčové slová má rovnaké ako C/C++/Java. Chcelo by to trochu znalostí pred kritizovaním

ale inak máte pravdu, je to efektívny jazyk

[Filip Jirsák]

Nepřipomínám Perl jako příklad všeho špatného. Připomínám Perl jako jazyk, který dokonale zužitkovává všechna písmenka, která lze najít na klávesnici a blízkém okolí, což je jeden ze způsobů, jak minimalizovat počet znaků programu. Protože tady někdo psal něco o tom, že když programátor stiskne 4 klávesy a jsou z toho 4 znaky v programu, je to jazyk s dobrou syntaxí, kdežto když z těch 4 úhozů vzniknou dva řádky, má ten jazyk špatnou syntaxi.

[Tom.š Ze.le.in]

Jenže nejde jen o psaní, ale i o čtení. Pokud jsou perlovské čtyři znaky srozumitelné, tak to znamená že na stejné ploše obrazovky při stejném rozlišení vidím mnohem větší kontext. Někomu to vyhovuje.

[zde]

jste líný si tam to int napsat ručně, tak jste prase.

Mě se to naopak hrozně líbí. Když se neobtěžujete uvádět typy argumentů ani návratových hodnot, vypadá "C" kód úžasně kompaktní, a na první pohled to připomíná nějaký dynamicky typovaný jazyk. Je hrozná škoda že se C++ této vlastnosti vzdalo.

Úplně nejvíc kewl by bylo nepoužívat v deklaracích nic jiného než int, a když je něco pointer, přetypovat to teprve těsně před dereferencí. Ale na to jsem malé prase, a hlavně sizeof(int) je bohužel občas na pointer příliš malý :/

[alblaho]

Od té doby, co jsem přešel na Linux a otevřený soft, tak žasnu, kolik aplikačního kódu je napsaného v plain C. Dokud jsem byl na Windows, myslel jsem si, že všechen rychlý kód je v C++, protože komu by se s tím chtělo psát v něčem tak primitivním jako C.

Asi to souvisí s tím, že C je celkem hezký minimalistický jazyk - vynikající přenositelný assembler. Naproti tomu C++ je neskutečně mocná a komplikovaná bestie, kterou musí programátor zkrotit.

Chápu lidi, co trvají na plain C. Ale psát v plain C objektově, je IMHO dost přes ruku. Proto když už musím něco udělat lowlevelově, šáhnu raději po C++.

Škoda, že se neprosadilo ObjectiveC, je to opravdu výkonné a přitom docela jednoduché a opravdově objektově orientované.

[cocoa]

Souhlas, Objective-C rulezz ;)
http://developer.apple.com/leopard/overview/tools.html
http://developer.apple.com/leopard/overview/objectivec2.html

[Miloslav Ponkrác]

Ono je to hlavně tím, že Unix si všechno dělal sám a součástí Unixu a jeden z vývojových kroků Unixu bylo stvoření jazyka C. Jeho účelem nebylo nic většího, než být přenositelným assemblerem pro přenos operačního systému a jednoduchých utilitek. Nicméně, že návrh jazyka C se povedl je fakt.

Já taky chápu, že se někomu líbí plain C a nic proti tomu nemám - pokud mě tedy nenutí na tomto spolupracovat a nechají mě žít.

Objective C není moc výkonné, je to pomalý jazyk už z principu. Je to proto, že převzalo smalltalkovskou filozofii, kdy metody se volají nikoli adresou, ale jménem! To jest, pokud třeba voláte metodu s názvem "vytiskni_to", pak ObjectiveC za běhu sáhne do hašovací tabulky názvů metod, najde řetězec s názvem metody, přeloží jí na adresu a pak teprve zavolá. Že to je signifikantně pomalejší, než volání metod adresou, nebo přes tabulku virtuálních metod je nabíledni. Proto také ani Apple, který prosazuje ObjectiveC horem dolem nemá ani pomyšlení v něm psát systémové věci, je to prostě pouze high level úroveň. Na systémové věci a tam kde jde o rychlost a efektivitu je ObjectiveC hodně špatná volba.

[zde]

Je to proto, že převzalo smalltalkovskou filozofii, kdy metody se volají nikoli adresou, ale jménem! To jest, pokud třeba voláte metodu s názvem "vytiskni_to", pak ObjectiveC za běhu sáhne do hašovací tabulky názvů metod, najde řetězec s názvem metody, přeloží jí na adresu a pak teprve zavolá. Že to je signifikantně pomalejší, než volání metod adresou, nebo přes tabulku virtuálních metod je nabíledni.

Trochu rádio Jerevan... Sice v podstatě máte pravdu, ale ve skutečnosti je to úplně jinak.... Selektory jsou v dynamických jazycích internalizovány, takže v hashi se nehledají řetězce, ale jejich integerové tagy. Navíc se používají inline cache, takže lookup je (v případě že na straně callera je cache hit, což je hodně často) díky lepší lokalitě (cílová adresa přímo v instrukčním proudu) o dost rychlejší než indexování VMT. Dále současné CPU (co je mi známo) neumějí predikovat nepřímá volání, takže každé volání virtuální metody v C++ znamená pipeline stall..

http://citeseer.ist.psu.edu/hlzle91optimizing.html

http://citeseer.ist.psu.edu/hlzle94adaptive.html

[Miloslav Ponkrác]

No tak se ještě dozvím, že ObjectiveC a dynamické jazyky jsou rychlejší, než ručně stroják - abych tak shrnul dojmy z toho co píšete. Máte tam tolika bludů, že nebudu ani reagovat.

[zde]

Dále současné CPU (co je mi známo) neumějí predikovat nepřímá volání

Tak je to pravda jen částečně. Pentium Mobile a Core2 už mají plnohodnotný BTB pro nepřímé skoky, který umí predikovat až 36 různých target adres. Starší x86 procesory od Intelu a všechny od AMD si pamatují pouze poslední target, a když na nepřímý skok přijdou poprvé, predikují že se skočí ihned na následující adresu (tj téměř vždy blbě).

[alblaho]

Hele, já znám ObjC jen z vlaku. Svého času jsem v jedné internetové konferenci byl jedním člověkem, že ObjC rychlé je. Většinu věcí odedře C, objektovost je dodána opravdu jen přes to zasílání zpráv. A určitě to mají dobře zoptimalizované.

Na systémové věci nevím, ale na aplikační SW je to určitě mnohem lepší než Java/Python/whatever a IMHO jen o fous za C++.

[Miloslav Ponkrác]

ObjC je určitě pomalejší, než C++, a to významně. I když je to dobře zoptimalizované, je to zkrátka pomalejší, protože je tam velká režie volání zpráv, je tam režie garbage collectoru (sice jen reference counter, ale to je skoro ten nejpomalejší a nejméně efektivní garbage collector co existuje).

A v čem je to lepší na aplikační sw, než třeba Python? S polovičními možnostmi oproti Pythonu, protože ObjectiveC je napůl staticky typované C a napůl dynamicky typované objekty a tenhle chameleón se navíc musí překompilovávat, tedy rychlost vývoje zejméně větších projektů je rozhodně nižší, než při vývoji v Pythonu? Navíc s nevýhodou překompilovat pokaždé znovu pro každou platformu, zatímco Python stačí spustit platformově nezávsle?

IMHO ObjectiveC a C++ se nedá srovnávat - jsou to naprosto odlišné cesty. ObjectiveC šla cestou dynamických objektů a zasílání zpráv ála Smalltalk, zatímco C++ šla cestou plně staticky typovaného jazyka včetně objektů. ObjectiveC šla cestou minimalizace zásahů do Céčka, takže ObjectiveC je v podstatě jenom Céčko s několika klíčovými slovy navíc, zatímco C++ šlo cestou doplnění plné syntaxe.

Na něco je lepší to a na něco ono, prostě ObjectiveC je dynamicky typované v "duck typing" stylu, C++ je staticky typovaný jazyk s plnou typovou kontrolou kompilátoru.

[alblaho]

Ať je ObjC pomalé jak chce, tak bude vždycky dvacetkrát rychlejší než Python, protože tam má zasílání zpráv stejný overhead a jinak je to bytecode interpreter oproti strojáku.

Jestli to má poloviční možnosti oproti Pythonu bych taky netvrdil, protože to má poctivý objektový model ze ST, nikoliv jeho statickou napodobeninu jako v C++.

Navíc ObjC je opravdu jen nadmnožina céčka, takže v místě kde by vás ten runtime brzdil se na něj prostě vykašlete u uděláte to "plain". Tohle jde v Pythonu přes nativní moduly a je to pěkně přes ruku.

Prostě si myslím, že ObjC je pro psaní desktopových aplikací mimořádně vhodný prostředek. Taky v tom bylo napsané nejlepší desktopové prostředí své doby (NeXT Step), dnes evolvované (a dle některých částečně zprasené) do MacOS X. Je to nativní kód (ne jako Python), nepotřebuje to JIT a zahřívání (jako Java).

http://shootout.alioth.debian.org/sandbox/benchmark.php?test=all&lang=objc&lang2=gpp

[Miloslav Ponkrác]

Ať je ObjC pomalé jak chce, tak bude vždycky dvacetkrát rychlejší než Python

Problém je jinde - mluvilo se tu o ObjC jako jazyku na roveň C/C++, tedy systémové programování, a tam, kde jde o rychlost - a tam není vhodné ani ObjC, ani Python.

ObjC je možná o krapítek rychlejší, než Python (ale zcela určitě ne 20x, ba dokonce ani ne 5x), ale otázka je, proč si vůbec ObjC vybrat, když mi nejde o max. rychlost? Proč si vybrat křížence C s jeho kompilací, nepřenostitelností, bez dobré standardní knihovny - kromě nadšení tedy? Proč nevybrat plnohodnotný high level dynamický jazyk, který bude plně dynamicky postaven se vším komfortem?

Jestli to má poloviční možnosti oproti Pythonu bych taky netvrdil, protože to má poctivý objektový model ze ST, nikoliv jeho statickou napodobeninu jako v C++.

Má to poloviční možnosti oproti Pythonu, poctivý objektový model ze ST to taky nemá. V ST je třeba i blok kódu objektem, kde to vidíte v ObjC? V ST je objektem úplně všechno, což se v ObjC ani vzdáleně nepodařilo docílit, abychom si ujasnili pozice. Ohledně statické napodobeniny raději nekomentuji, protože pravděpodobně jste si neuvědomil, že staticky typované jazyky mají své místo, a proto existují, ale porovnávalo se s Pythonem, nikoli s C++.

Navíc ObjC je opravdu jen nadmnožina céčka, takže v místě kde by vás ten runtime brzdil se na něj prostě vykašlete u uděláte to "plain". Tohle jde v Pythonu přes nativní moduly a je to pěkně přes ruku.

No právě - ObjC je prostě jen zflikovaná nadstavba nad C. A znovu říkám, že v oblasti, kde se ObjC i Python používá potřeba "plain" věcí je prakticky nula, nebo něco blízké nule. A na systémové a efektivní programování se ObjC nehodí, jak už jsme si vysvětlili výše díky jeho pomalosti.

Prostě si myslím, že ObjC je pro psaní desktopových aplikací mimořádně vhodný prostředek.

Já tohle nadšení nesdílím. Jazyk, který nemá standardní knihovnu je špatný jazyk pro desktop aplikace. U programování desktopových aplikací často daleko větší roli, než kvalita jazyka hraje kvalita standardních knihoven. A zde ObjC je značně nedokonalý - standardní knihovnu nemá, používá se jako náhrada x možností.

Taky v tom bylo napsané nejlepší desktopové prostředí své doby (NeXT Step), dnes evolvované (a dle některých částečně zprasené) do MacOS X.

Ono i ruchadlo byl nejlepší orací stroj své doby. A koňský potah nejlepší formule jedna své doby. NextStep byl zajisté dobrý systém, ovšem na počítačích velmi pomalý. Právě tady se natvrdo projevilo, že výhoda "nativního kódu" v pojetí ObjC je na velké kulové, protože zase tak moc rychle to ObjC neběží.

Je to nativní kód (ne jako Python), nepotřebuje to JIT a zahřívání (jako Java).

Nativní kód, který v sobě obsahuje high level prvky z jazyků ala Python, nebo Smalltalk, a tím běžící řádově pomaleji, než skutečný nativní kód.

Závěr: Nemám nic proti ObjC, nicméně nevidím důvod, proč bych ho měl dnes používat osobně já (možná se mýlím, a netvrdím, že jsem objektivní). Skutečné plně dynamické jazyky mi nabízejí srovnatelný výkon, portabilitu (což ObjC nenabízí ani náhodou), rozsáhlou a užitečnou standardní knihovnu (což ObjC nemá), navíc tyto jazyky navlastní a nedrží jejich vývoj pod pokličkou komerční firma jakožto neomezený a nikým nehlídaný vládce jako je to v případě ObjC a Apple. ObjC mi nenabízí rychlost nativního kódu (má velmi vysokou režii), ani efektivitu a komfort vývoje dynamických jazyků (musím kompilovat a linkovat, nemůže rovnou pouštět a jet jako v Pythonu, či alespoň vypustit linkování jako v Javě).

[alblaho]

Ondřeje Čadu na Vás. Ten je stejně tvrdý diskutér, stejně zkušený jako vy, a v ObjC napsal mraky kódu.

Nemám věcné argumenty, o ObjC mám jen povědomí. Nicméně můj dojem je, že přeháníte stejně jako s nestabilním Pythonem a úžasně přenositelným C++.

[Miloslav Ponkrác]

Ondřej Čada je rozumný chlap. Četl jsem jeho názory a líbí se mi. Dokonce rovnou píše, že se mu C++ nelíbí, ale na druhé straně není fanatik a pochopil, že byly věci, kde C++ byla nejlepší volba (například toto psal o Symbianu, kde napsal, že vzhledem ke slabému hw byla volba C++ to nejlepší, co šlo, protože jiný objektový jazyk by prostě byl příliš pomalý).

Líbí se mi jeho nadšení do ObjC, ale on je plus mínus v reále. Nesnaží se z ObjC dělat co není.

Jinak řekněte mi konkrétně kde přeháním? Kde jsou tedy záruky na Python, že kód který napíši dnes v Pythonu podle nějakých závazných pravidel (kde taková pravidla pro Python existují?), bude běhat v příštích verzích Pythonu a bude ten kód dělat stále to stejné? Tyto záruky existují pro C, C++, Adu, Fortran, a řadu dalších jazyků.

Ohledně přenositelnosti C++ je naprostá pravda, že kód zcela v souladu se standardním C++ je přenositelný na jakýkoli kvalitní (C++ standard compliant) kompilátor. A pokud nebudete používat machine dependent věci, pak zcela přenostitelný bez čárky změny. Dokažte mi opak, stačí jediný příklad, kdy to neplatí a odvolám.

Na druhé straně jsem napsal zcela natvrdo, že většina programů pouze se standardem C++ nestačí a pohaněl jsem C++ za jeho slabou standardní knihovnu, která je mínusem.

[alblaho]

Tím přeháněním jsem to myslel jen tak, že máte v podstatě pravdu, ale ve vnímání důsledků těch faktů se lišíme. Třeba ISO norma je úhelný kámen až v okamžiku, kdy ji všechny překladače ve vesmíru implementují

O Symbianu vím celkem prd, ale tuším, že je v C++ a má i C++ api. Pasovat na to ObjC by asi chtělo už hodně nadšení.

Naopak v Masoxu je králem programátor, který nativně používá Cacao.

[Miloslav Ponkrác]

ISO norma je od toho, že se jí hlavně pokusí všechny kompilátory v budoucnu splnit. Ale ono jak kdy - třeba zkuste si napsat kompilátor Ady a nesplnit normu a v tu chvíli jdete k soudu. Jazyk, který 100% nesplňuje normu Ady, a nebo má nějaké rozšíření navíc oproti normě Ady - nesmíte nazvat Adou.

Symbian je v C++ hlavně proto, že na 8 MHz procesoru s řádově stovkami KB paměti by bylo ObjC nepoužitelné pro svojí pomalost. Což byl tehdejší luxusní hw pro přenositelné přístroje té doby. Zatímco C++ je i na tomto hw velice efektivní - naprosto stejně, jako byste to napsal v čistém C, ale s luxusem OOP a dalšího.

MacOS se zkrátka snaží, aby vše bylo v ObjC, ale otázkou je, jak je to pak s přenositelnými programy, třeba programy, které mají verzi nejen pro MacOS, ale třeba i pro Windows - pak velmi pochybuji o použitelnosti ObjC. Třeba by mě zajímalo, jak to dělá takový Adobe. Možná pomalu na Mac asi postupně kašle, nevím.

[Miloslav Ponkrác]

Možná bych měl ještě doplnit, že u ObjC jsou právní a licenční problémy s knihovnami, na které vlastní (pokud se něco nezměnilo) práva Apple. Ale nějakou dobu už jsme situaci nesledoval.

[petris]

To jste to prestal sledovat uz nekdy v minulem tisicileti, protoze open source implementace zacala vznikat nekdu v 95.

[Miloslav Ponkrác]

Trochu jsem propátral a zjistil jsem, že je situace ještě horší. ObjectiveC žádnou standardní objektovou knihovnu nemá, a každý si používá co se mu zlíbí. Takže nic moc situace.

Jinak k té pomalosti ObjectiveC co se diskutovalo výše:

Because Objective-C uses dynamic runtime typing and because all method calls are function calls (or, in some cases, syscalls), many common performance optimizations cannot be applied to Objective-C methods (for example: inlining, constant propagation, interprocedural optimizations, and scalar replacement of aggregates). This limits the performance of Objective-C abstractions relative to similar abstractions in languages such as C++. Proponents of Objective-C claim that it should not be used for low level abstraction in the way that C++ or Java are used, because Objective-C is known to have a high runtime cost.

[Sinuhet]

Chcete si sami nějak rozumě pojmenovat globální symboly? Máte smůlu.

Zajimave... Jaka jsou omezeni na globalni jmena oproti lokalnim?

Chcete volat destruktory objektů na stacku podle vlastního uvážení, a nikoliv na konci scope? Máte smůlu.

My ne. Tu maji leda tak ti, co nevedi, jak se to dela.

Chcete raisovat výjimku v konstruktoru? Máte smůlu.

Poslouchaj, zde, voni budou asi vesela kopa, zejo?

Chcete ovládat layout VMT? Máte smůlu.

Zrejme byste koukal, co v C++ jde udelat. Pravda, primo s VMT sachovat prilis nemuzete, ale muzete si napsat vlastni a slusne to obalit, takze vam to v onom kritickem miste ani nebude tak vycuhovat, ve zbytku si vystacite se standardni implementaci.

Chcete určit, do kterého compile unitu se mají vygenerovat instance templatů a metadat? Máte smůlu.

To fakt nema cenu. Videl jste vubec nekej C++ kod z min nez peti kilometru?

[Miloslav Ponkrác]

Ale on prý zná C++ stejně dobře jako já Tedy nikdy jsem o sobě netvrdil, že umím C++ na výbornou, ale na rozdíl od něho jsem v tom C++ i něco napsal.

[zde]

Zajimave... Jaka jsou omezeni na globalni jmena oproti lokalnim?

Přirozeně že žádná, ale já nemluvil o C++ jménech, ale o jménech public symbolů, tedy tom smetí co vidíte když se podíváte na assembly, které C++ překladače generují (čti blejou), a nad kterými nemá programátor žádnou kontrolu. Díky tomu je téměř nemožné rozumně volat C++ kód z assembleru.

My ne. Tu maji leda tak ti, co nevedi, jak se to dela.

V tomto bodě jsem se mýlil. Destruktory pro objekty na stacku lze opravdu volat explicitně, a nový objekt lze vytvořit na místě, kde byl ten starý (pomocí úchylnosti jménem placement new). Ovšem i tak je to pěkně pošahaný. S tímhle můžu jen souhlasit.

When a programing language doesn't support some necessary operation, one shouldn't simply add new syntax for that specific operation. Instead, one should ask, "How can I ammend the language to make this operation implementable in a standard library?" The answer may be a much simpler, cleaner, and more powerful set of mechanisms than the one tailored for a specific problem.

C++ needed a way to perform type-safe memory allocation. Such a scheme could have been implemented entirely as a library function, given the right support. Such support might have included ways to infer whether classes have destructors at compile time, support for calling constructors directly and even taking their addresses, and more. These features might even have been useful in more contexts than memory allocation.

Instead, Stroustrup introduced operator new, a disgusting piece of syntax inadequate for the job. After many complaints, new's functionality was finally extended to include per-class operator new[] and placement new, still an imperfect solution.

Poslouchaj, zde, voni budou asi vesela kopa, zejo?

Slyšeli už o házení perel sviním?

To fakt nema cenu. Videl jste vubec nekej C++ kod z min nez peti kilometru?

Argumentíček by nebyl? Tak někdy příště, až se líp vyhajaj, ju?

[Miloslav Ponkrác]

Pardon, nehledají oni problémy kde nejsou?

Přirozeně že žádná, ale já nemluvil o C++ jménech, ale o jménech public symbolů, tedy tom smetí co vidíte když se podíváte na assembly, které C++ překladače generují (čti blejou), a nad kterými nemá programátor žádnou kontrolu. Díky tomu je téměř nemožné rozumně volat C++ kód z assembleru.

Jména public symbolů jsou naprosto v pořádku. Jen pro Vaší informaci, psal jsem assembler, který běžně volal C++ kód včetně objektů a není v tom naprosto žádný problém. Jinak to, že co překladače generují za jména do linkeru samozřejmě do jisté míry oblivňovat můžete, ale to by se pán musel obtěžovat kromě nadávání na C++ v tom taky občas něco napsat.

---

Se zbytkem se budu jenom opakovat - doporučuji vydat pár dokumentů o tom, že C++ je špatné, nejlépe stejně "skvěle" argumentované, jak tu píšete. Ideálně, když použijete pseudonym, protože zesměšnit se pod pravým jmenem je docela hloupé.

[zde]

Jen pro Vaší informaci, psal jsem assembler, který běžně volal C++ kód včetně objektů a není v tom naprosto žádný problém.

Jistě. Nepsal jsem že je to vyloučené, jen velmi obtížné a nepříjemné. Jsou lidé kteří rádi pojídají výkaly, nebo si dávají kolíčky na prádlo na varlata nebo bradavky. Jsou i lidé kterým nevadí používat v assembleru 100+ znakové symboly z C++, a každé dva roky na nich dělat search/replace, protože C++ mezitím změnilo ABI. Takže si to užívejte- sice se vám divím ale fakt mi to nevadí.

[Let_Me_Be]

Aha, a extern C ti nic nerika, co? Prosimte zalez uz nekam.

[zde]

Ono mi extern "C" nějak pomůže, když potřebuju z "C" nebo assembleru volat funkci která je uprostřed nějaké C++ knihovny? Odkdy, chlapče?

[happy barney]

ano, pomôže presne nato totiž bola táto konštrukcia vymyslená

[zde]

Nikoliv. extern "C" je k tomu, aby C++ mohlo volat funkce, napsané v "C" nebo assembleru, a souhlasím že k tomuto účelu slouží docela dobře. Opačný směr však možný není, a to ani v případě že skutečně máte přístup k tomu C++ zdrojáku a můžete ho rekompilovat. Extern "C" nejde (viz příklad) použít na přetížené funkce, a už vůbec ne na metadata (C++ se totiž tváří že žádná metadata neexistují, proto logicky nemůže mít programátor nad nimi žádnou kontrolu, ani je udělat extern "C"). Třeba následující kód je (bez extern "C") ok, s ním ho však nepřeložíte.

extern "C" {

class A { int x; };
class B { int y; };

int hovnocuc(A a);
int hovnocuc(B b);

}

error: declaration of C function ‘int hovnocuc(B)’ conflicts with
error: previous declaration ‘int hovnocuc(A)’ here

[happy barney]

hmm ... tak niekto tu neporozumel extern "C" ono je tu z opačného dôvodu ... aby C (a akýkoľvek iný jazyk) mohol volať knižničné funkcie písané v C++. Teoreticky to môžete zvládnuť aj sám bez extern "C", ale volať funkciu s manglovaným menom ručne ...

[zde]

ale volať funkciu s manglovaným menom ručne ...

No, pan Ponkrác to zjevně dělá.. a nedivil bych se kdyby rád a s nasazením .-)

[Let_Me_Be]

Ano, pise to zcela logickou chybu, protoze cecko nepodporuje pretezovani funkci, proto nemuzes mit dve funkce se stejnym nazvem. Celkem necekane, ze?

[zde]

Ano, pise to zcela logickou chybu, protoze cecko nepodporuje pretezovani funkci, proto nemuzes mit dve funkce se stejnym nazvem. Celkem necekane, ze?

Ty jsi fakt legrační. Napíšu že udělat z C++ kódu extern "C", abych jej mohl volat z C, nejde. Ty mi pak napíšeš Aha, a extern C ti nic nerika, co? Prosimte zalez uz nekam. Uvedu proto konkrétní příklad, kdy extern "C" použít nejde. A ty mi k tomu ironicky napíšeš napíšeš Celkem necekane, ze? Fakt funny :) :) :) Příště prosím trochu konzistence, ano?

[Let_Me_Be]

Přirozeně že žádná, ale já nemluvil o C++ jménech, ale o jménech public symbolů, tedy tom smetí co vidíte když se podíváte na assembly, které C++ překladače generují (čti blejou), a nad kterými nemá programátor žádnou kontrolu. Díky tomu je téměř nemožné rozumně volat C++ kód z assembleru.

Prosimte, nauc se alespon ty nejzakladnejsi zaklady a pak neco komentuj. Vetsi blbosti jsem fakt v zivote necetl.

[zde]

Vetsi blbosti jsem fakt v zivote necetl.

Tvoje dojmy mě vážně nezajímají.

[Messa]

Mě osobně v C vadí nejvíc to, že pokud se člověk snaží o OOP, tak jsou názvy "metod" strašně dlouhé a dědičnost je řešena skutečně vtipně (různé kontroly typu jsou opět na programátorovi, jazyk nepomůže). I některé další věci musí programátor vždy dělat sám, např. inicializaci a destrukci. Takže mi spíš přijde divné, proč se někdo snaží v C o něco, s čím by mu C++ výrazně pomohlo.

Na druhou stranu mám nejisté pochybnosti o kompatibilitě binárního kódu generovaného z C++. Někde jsem četl, že ABI vyjímek není standardizováno. Také by mě zajímalo, jestli by nenastaly nějaké problémy v binární spolupráci různých prostředí (např. nějakého nativního kódu a skriptovacího jazyka, třeba i implementovaného v C++ místo v C); sem má představivost moc nesahá. (Mě stačí už jen to, na co všechno se musí myslet při psaní knihovny v C++, na co se třeba při psaní knihovny v Pythonu myslet vůbec nemusí.)

[Miloslav Ponkrác]

Na druhou stranu mám nejisté pochybnosti o kompatibilitě binárního kódu generovaného z C++.

To je velice jednoduché, objektové moduly z různých kompilátorů spolu kompatibiliní nejsou a nejspíš ani nepůjdou slinkovat.

Ale stejně tak obecně není zaručeno, že půjdou slinkovat moduly z různých C kompilátorů do chodícího programu, ani tam není kompatibilita zaručena.

Někde jsem četl, že ABI vyjímek není standardizováno.

Není, a ani nemůže být. Na každé platformě je to totiž nutné výjimky implmenetovat totálně odlišně.

Také by mě zajímalo, jestli by nenastaly nějaké problémy v binární spolupráci různých prostředí (např. nějakého nativního kódu a skriptovacího jazyka, třeba i implementovaného v C++ místo v C)

Co je to binární spolupráce?

[zde]

není zaručeno, že půjdou slinkovat moduly z různých C kompilátorů

Zaručeno nemáte ani že zítra vyjde slunce, ale ještě jsem neviděl že by volání normální cdecl funkce nějak záviselo na použitém překladači. Naproti tomu každé Ceee flus flus je zcela izolovaný systém, do kterého se nedá nízkoúrovňově sáhnout aniž byste tím dráždil belzebuba.

Není, a ani nemůže být. Na každé platformě je to totiž nutné výjimky implmenetovat totálně odlišně.

To máte pravdu, ale v rámci jedné platformy by standard existovat měl, a neexistuje.

[Miloslav Ponkrác]

ještě jsem neviděl že by volání normální cdecl funkce nějak záviselo na použitém překladači

Samozřejmě, že závisí. Už jenom proto, že každý kompilátor má jiné interní funkce, například násobení, nebo dělení 64 bitových čísel na 32 bitové x86 platformě vyžaduje, aby kompilátor do C kódu umístil volání externí funkce z runtime knihovny. A při pokusu slinkovat takový kód z různých překladačů C samozřejmě tvrdě narazíte. Řadu operací kompilátor nahrazuje voláním interních funkcí runtime knihovny - a obecně ani C modul není přenositelný mezi C kompilátory.

Těch situací, kdy C kompilátor umísťuje do výsledného strojáku volání interních funkcí bez Vašeho vědomí je celá řada - a takový C modul - i když je to obyčejná cdecl funkce selže při pokusu přenést jej na jiný kompilátor.

Naproti tomu každé Ceee flus flus je zcela izolovaný systém, do kterého se nedá nízkoúrovňově sáhnout aniž byste tím dráždil belzebuba.

Ne, Vy s Vašimi znalostmi C++ to opravdu raději nedělejte.

To máte pravdu, ale v rámci jedné platformy by standard existovat měl, a neexistuje.

A hlavním důvodem je efektivita. Věci se neustále vylepšují - první pokusy o výjimky byly obludné - bylo to neefektivní, pomalé a interní tabulky dat pro obsluhu výjimek byly někdy i větší, než užitečný kód. Dnes se postupným uplatňováním nápadů a evolucí došlo k tomu, že výjimky jsou natolik efektivní, že pokud ošetřujete chyby výjimkami, je běh kód většinou rychlejší, než když je nepoužijete. Dnešní kompilátory implementují výjimky rychle, efektivně, a interní data k jejich obsluze jsou zanedbatelná a nestojí za řeč.

Zkrátka došlo se k vynikajícímu výsledku. Pokud byste chtěl někde něco standardizovat a zakonzervovat, zakonzervujete něco horší a špatného. Navíc procesory se vyvíjejí, postupně kompilátor může využívat další možnosti novějších procesorů - a zakonzervovat to standardem by nebylo to pravé ořechové.

Low level úroveň zkrátka standardizovaná moc být nemůže.

[zde]

například násobení, nebo dělení 64 bitových čísel na 32 bitové x86 platformě vyžaduje, aby kompilátor do C kódu umístil volání externí funkce z runtime knihovny.

Pravda. 64bit násobení a shifty se sice inlinují, ale pro 64bit dělení se volá "C" runtime, a každý překladač má svou vlastní verzi. Ovšem 1) jde o zřídka užívaný corner case 2) s velkou pravděpodobností se ty dvě runtime funkce od různých překladačů budou jmenovat různě, takže stačí přilinkovat obě runtime knihovny. Nijak to ovšem nesouvisí s volací konvencí normálních cdecl funkcí, takže mi není jasné proč to vytahujete.

obecně ani C modul není přenositelný mezi C kompilátory.

Je přenosný nesrovnatelně lépe než C++ modul.

Věci se neustále vylepšují.. Zkrátka došlo se k vynikajícímu výsledku.

Pokud je stav špatný, je třeba jej změnit a v tom případě nemá cenu jej standardizovat. Pokud je stav vynikající, tuto omluvu už nelze použít. Takže si prosím vyberte, oboje současně nelze.

Low level úroveň zkrátka standardizovaná moc být nemůže.

Ten standard je ovšem potřeba. Třeba pro efektivní implementaci garbage collectoru. Nebo pro implementaci transparentní perzistence. Nebo fungující reflexi. Nebo dynamickou kompilaci. A spoustu dalších věcí..

[Miloslav Ponkrác]

Ovšem 1) jde o zřídka užívaný corner case 2) s velkou pravděpodobností se ty dvě runtime funkce od různých překladačů budou jmenovat různě, takže stačí přilinkovat obě runtime knihovny.

Myslím, že je hlavně jasné, že nikdo Vám nezaručí, že C moduly budou mezi kompilátory přenositelné. A to kvůli řadě případů, nejenom práce s 64 bitovými čísly, narazíte daleko častěji. A linkování dvou runtime knihoven dvou různých C kompilátorů mi prosím předvěďte v praxi, já už jsem se hrozně dlouho nezasmál, a u tohodle se nařehtám jako hrom.

Je přenosný nesrovnatelně lépe než C++ modul.

1) C nedává žádné záruky na přenositelnost mezi kompilátory.

2) C++ nedává žádné záruky na přenositelnost mezi kompilátory.

Zbytek je hackování.

Pokud je stav špatný, je třeba jej změnit a v tom případě nemá cenu jej standardizovat. Pokud je stav vynikající, tuto omluvu už nelze použít. Takže si prosím vyberte, oboje současně nelze.

Není potřeba vše standardizovat. Nebo standardizuje třeba někdo, jak bude vypadat implementace printf v Céčku třeba? Nestandardizuje, a nikdo to nepotřebuje. Stačí standartizovat chování a interface funkce printf - a víc není potřeba. A stejné je to s výjimkami - API, tedy syntaxe je standardizována.

Nechcete náhodu ještě připsat do standardu, jakou sekvenci strojových instrukcí na x86 platformě má vyplodit určitý Céčkový kód? Zakažte tím možnost udělat optimálnější kód C kompilátorem. Prostě to není žádná omluva, tady blbnete na kvadrát Vy.

Ten standard je ovšem potřeba. Třeba pro efektivní implementaci garbage collectoru. Nebo pro implementaci transparentní perzistence. Nebo fungující reflexi. Nebo dynamickou kompilaci. A spoustu dalších věcí..

Není. Garbage collectory se stále zlepšují, a stále se hledají nové a nové algoritmy, jak zlepšit jejich chování zejména pro multithreadové programy, a to první gc vzniknul uričitě minimálně před mnoha desítkami let. Stále není hotovo, a stále se nenašlo nic, co by se neukázalo jako možné vylepšit. Zbytek vezměte analogicky.

[Miloslav Ponkrác]

Mě osobně v C vadí nejvíc to, že pokud se člověk snaží o OOP, tak jsou názvy "metod" strašně dlouhé

Což ale naráží na limitu standardu Céčka. Staré C snad zaručovalo pouze použití prvních šesti znaků identifikátoru (proto jsou názvy standardních C funkcí velmi krátké), ANSI norma tuším (z hlavy nevím přesně) max. 32 znaků. Pokud máte delší identifikátory, už jste v nestandardních oblastech Céčka. Není zaručeno, že kompilátor rozliší dva názvy funkcí, které se liší na 33. znaku.