Odpověď na názor

Odpovídáte na názor ke článku Skrytá úskalí vícenásobné dědičnosti v C++.

  • 8. 5. 2012 12:11

    Ondřej Novák (neregistrovaný)

    Tomáši, myslím si, že o tom to není. C++ samozřejmě interface má, jenže to má v obecnější formě. Zatímco interface se třeba v javě chápe jako další jazykový nástroj, v C++ je interface jen o tom, že programátor dodrží nějaké směrnice ..."štábní kulturu" ... (například všechny metody jsou abstraktní). Vícenásobná dědičnost je pak obecnou verzí implements ... jaký je rozdíl mezi extends a implements? Kromě toho, že jde o technickou záležitost v jazyce Java, tak vlastně žádný. Ano, jistě, pro sebe si můžeme definovat nějakou interpretaci použití nástrojů, že jako extends dědí, zatímco implements pouze implementuje rozhraní, ale to samé si lze udělat v C++. Já si například všechny interfacy označuju písmenem I na začátku. Pokud tedy někam napíšu "class A: public IFoo", pak ekvivalentní zápis v Javě je "class A implements Foo". Význam technických prostředků si samozřejmě vždycky musí udělat programátor. Klidně mohu dědění chápat jako spojování struktur, jazyk to umožňuje, ale kolegové mi nejspíš nebudou rozumět ... mimochodem, krásným příkladem je objektové prostředí v neobjektovém jazyce javascript, i tam je to spíš o těch směrnicích a štábní kultuře. Sám jazyk tomu moc nepomáhá.

    V článku jsem se snažil poukázat na to, že tahle vícenásobná dědičnost může přinést nějaké skryté úskalí, ale není to evidentně chyba jazyka jako takového, ale spíš implementace (v tom má pan Ponkrác pravdu). Microsoftí implementace je z tohoto pohledu určitě horší, protože vícenásobná dědičnost nafukuje objekty. GCC to dělá správně, tak to má být. Stejně jako v Javě, ani zde vícenásobnou dědičnost nijak "nepocítíme", dokud tedy nezačneme dědit jednu třídu (implementovat jedno rozhraní) vícekrát. To je ale už jiná kapitola, kterou všichni "hledači diamantů" znají.