Ideálny programovací jazyk

[Zabanovaný Anonymní Troll]

Me na CPP stve, a doted mi nikdo nevysvetlil proc to tak je, neco cemu se da rika zbastardizovani objektu. To se vam tak snazim psat tak, aby se alokovalo na stacku, jenze na stacku neni proste mozne udelat polymorfismus. Kdyz se o to pokusim, tak c++ zbastardizuje objekt do predka a vytvori bastarda. Uz nevim jak se tomu presne rika, ja tomu rikam bastardizace.

A dalsi vec co nechapu proc to C++ dela je, ze kdyz chci vyuzivat jen stacku, tak pokud vracim z nejake funkce objekt na stacku, tak C++ ten objekt veme a cely ho prekopiruje jinam - nechapu proc, dyt je to neefektivni.

Takze z toho duvodu moc nechapu vyhody psani na stacku. Mohl bych se toho drzet ledaze bych nepouzival OOP paradigma, ale to uz jsem zase ve sfere kockopsovani.

Dale me na C++ dost vytaci hlavickove soubory, to je proste z hlediska OOP paradigmatu totalni kockopsovina.

A uplne nejvic me stve, ze to neni ani poradne zaplacene, tak proc se s tim stvat.

[Reklama]

[Cikáda]

Dale me na C++ dost vytaci hlavickove soubory, to je proste z hlediska OOP paradigmatu totalni kockopsovina.

Proč? Buď píšu do hlavičkového "vše", takže je to "jedno". Nebo mám v hlavičkovém jen rozhraní a potom mi to přijde přehlednější... ale možná si jen nerozumíme.

[Kit]

A dalsi vec co nechapu proc to C++ dela je, ze kdyz chci vyuzivat jen stacku, tak pokud vracim z nejake funkce objekt na stacku, tak C++ ten objekt veme a cely ho prekopiruje jinam - nechapu proc, dyt je to neefektivni.

Ono to jinak ani nejde, protože při návratu je ten stack zlikvidován.

[alex6bbc]

Ja bych osobn e byl pro aby na stacku byly jen reference, tj. odkazy na adresy. Objekty, pole, cokoliv je vic nez typ se systemovou velikosti adresy (char, int32, int64) by uz musely byt na heapu a hlidane smart pointerem nebo referenci, zadne obludy na stacku. To jen k c++.

C++ uz nemam rad, mnohem radeji bych delal v Go. Smart pointery, template, STL, Boost, template SFINAE, = by melo byt automaticky move, hafo typu referenci, &, & &.

[Cikáda]

Ja bych osobn e byl pro aby na stacku byly jen reference, tj. odkazy na adresy. Objekty, pole, cokoliv je vic nez typ se systemovou velikosti adresy (char, int32, int64) by uz musely byt na heapu a hlidane smart pointerem nebo referenci, zadne obludy na stacku. To jen k c++.

To lze udělat, ale bude to nutně (a zbytečně) pomalejší. Taky by šlo proti filozofii C++.

[Reklama]

[Idris]

Ja bych osobn e byl pro aby na stacku byly jen reference, tj. odkazy na adresy. Objekty, pole, cokoliv je vic nez typ se systemovou velikosti adresy (char, int32, int64) by uz musely byt na heapu

Zrovna Go dává na zásobník kde co, a jak šlape - překladač sám pozná, co musí být na haldě, díky čemuž toho GC nemá typicky moc na práci. Zrovna tohle třeba Javě bolestně chybí.

[Idris]

Predstavte si že vytvárate nový programovací jazyk presne podľa vašich predstáv.

Jde o to, pro koho. Pro nepříliš zdatné programátory, tedy přes 95% IT audience? Ti mají Javu a PHP. Jinak mají smysl jen úzce specializované jazyky, v CERNu si třeba vytvořili speciální jazyk pro HPC. To ale není téma pro toto fórum.

Pokladat Javu za jazyk pro neprilis zdatne programatory

To byl Goslingův deklarovaný cíl. Až dospěješ, tak ti to dojde.

[nula]

A dalsi vec co nechapu proc to C++ dela je, ze kdyz chci vyuzivat jen stacku, tak pokud vracim z nejake funkce objekt na stacku, tak C++ ten objekt veme a cely ho prekopiruje jinam - nechapu proc, dyt je to neefektivni.

Pokud vracis objekt vytvoreny na stacku, tak se to nedeje, vetsina objektu se vytvari tam kde je potreba. Takze ze stacku se nic nekopiruje.

Dale me na C++ dost vytaci hlavickove soubory, to je proste z hlediska OOP paradigmatu totalni kockopsovina.

To je bohuzel z historickych duvodu a z duvodu kompatibility s C. Snad to moduly ted zmeni. Ted se to muselo ruzne obchazet.

A uplne nejvic me stve, ze to neni ani poradne zaplacene, tak proc se s tim stvat.

Zaplacene je to velmi dobre, pokud neco umis, pokud jsi standardni noob, tak ti samozrejme nikdo sypat zlato nebude.

[nula]

Ruční volání destruktorů nebo třeba zavírání souborů by mě už nebavilo. Proč bych to měl hlídat?

V cpp zadne rucni volani destruktoru neni potreba. Akorat lze presne zjistit kouknutim do kodu, kdy se tak stane.

Takže se zánikem posledního deskriptoru na objekt se automaticky zavolá jeho destruktor? Java se má co učit, neboť tohle neumí.

Ano, pokud se pouziva moderni cpp(od 11ky, i kdyz i drive byly smart pointry ale s problemama.) Samozrejme je to zpetne kompatibilni, takze kdyz se vylozene chces strilet do nohy a ignorujes guideliny, ktere radi nepouzivat stare konstrukce nutne z duvodu zpetne kompatibility, tak si tu nohu ustrelit porad muzes.

[Jiří Havel]

Me na CPP stve, a doted mi nikdo nevysvetlil proc to tak je, neco cemu se da rika zbastardizovani objektu. To se vam tak snazim psat tak, aby se alokovalo na stacku, jenze na stacku neni proste mozne udelat polymorfismus. Kdyz se o to pokusim, tak c++ zbastardizuje objekt do predka a vytvori bastarda. Uz nevim jak se tomu presne rika, ja tomu rikam bastardizace.

Říká se tomu slicing. Je to důsledek toho, že v kontextu kdy neznáš kompletní typ objektu, tak je hodně těžké ho kopírovat. C++ zvolilo jedno z možných omezených řešení, jiné jazyky volí jiná omezení. Dobré řešení AFAIK není.

Problém není polymorfismus ale právě kopírování. Kód :

Kód: [Vybrat]

void foo( const Base & );
//...
Derived aaa;
foo( aaa );
funguje ok bez jakékoliv "bastardizace". Problém nastává třeba u

Kód: [Vybrat]

Base foo()
{
    Derived temp;
    return temp;
}
V místě, kde foo volám, o typu Derived nevím vůbec nic. Může to být v modulu, který se kompiloval v době, kdy Derived ještě vůbec neexistoval. Aby volající kód mohl kopírovat neznámý odvozený typ, musel by mít k dispozici něco jako "virtuální kopírovací konstruktor" + podporu objektů neznámého typu na zásobníku. To druhé bohužel hodně omezí optimalizátor v rozletu.
Spousta jazyků to řeší stylem všechno je na heapu a vůbec nic se nekopíruje. V porovnání se zásobníkem je halda obecnější a pomalejší. A třeba v hard realtime systémech je dynamická alokace na haldě hodně velký problém. Takže C++ šlo cestou že to dovolí, protože to programátor občas potřebuje.

Dobrý zvyk v C++ je, že pokud píšu "interface" nebo spíš třídu s virtuálními metodami, tak zakážu kopírování abych si nemohl naběhnout na vidle.

[Zabanovaný Anonymní Troll]

Dobrý zvyk v C++ je, že pokud píšu "interface" nebo spíš třídu s virtuálními metodami, tak zakážu kopírování abych si nemohl naběhnout na vidle.

ja jsem to uplne 100% nepochopil, ale doptavat uz se nebudu, tohle co pisete to uz je proste fakt moc. Ja nikdy proste v C++ delat nechci, protoze to je hruza. To si to radeji napisu v C a budu delat polymorfismus pres pointry na funkce.

[gill]

Cim idealnejsi jazyk je tim vice se podoba lispu.

Chtel bych na nizke urovni videt kod pro kernel v lispu :-)
Kacirsky dotaz: jsou funkcionalni jazyky opravdu efektivnejsi? Mi se Lisp a dalsi libi, ale prakticky jsem je nevyuzil.

podivejte se treba na videa od baggers na Twitchi nebo YT. Programuje 3d grafiku v Common Lispu. https://www.youtube.com/channel/UCMV8p6Lb-bd6UZtTc_QD4zA. Zajimava je hlavne jeho produktivita prace oproti streamerum programujicim v C/C++.

[Jiří Havel]

ja jsem to uplne 100% nepochopil, ale doptavat uz se nebudu, tohle co pisete to uz je proste fakt moc. Ja nikdy proste v C++ delat nechci, protoze to je hruza. To si to radeji napisu v C a budu delat polymorfismus pres pointry na funkce.

Ale v C to přece vyjde na stejno. Pokud budu dělat polymorfismus Cčkovským stylem, tzn bázová struktura bude první položka té odvozené, tak jsou při kopírování té struktury úplně stejné problémy. Jenom to přetypování ukazatele z odvozené struktury na bázovou se musí napsat ručně. Pokud tu strukturu alokuju na haldě, tak je to stejně bezproblémové v C i C++. A pokud ji vytvořím na stacku, tak mi kód, který nic neví o odvozené struktuře, vyzobne a "zbastardizuje" tu strukturu i v čistém C. Zrovna tady přidává C++ jenom syntaktický cukr a principy z Cčka zůstávají.

[Zabanovaný Anonymní Troll]

ja jsem to uplne 100% nepochopil, ale doptavat uz se nebudu, tohle co pisete to uz je proste fakt moc. Ja nikdy proste v C++ delat nechci, protoze to je hruza. To si to radeji napisu v C a budu delat polymorfismus pres pointry na funkce.

Ale v C to přece vyjde na stejno. Pokud budu dělat polymorfismus Cčkovským stylem, tzn bázová struktura bude první položka té odvozené, tak jsou při kopírování té struktury úplně stejné problémy. Jenom to přetypování ukazatele z odvozené struktury na bázovou se musí napsat ručně. Pokud tu strukturu alokuju na haldě, tak je to stejně bezproblémové v C i C++. A pokud ji vytvořím na stacku, tak mi kód, který nic neví o odvozené struktuře, vyzobne a "zbastardizuje" tu strukturu i v čistém C. Zrovna tady přidává C++ jenom syntaktický cukr a principy z Cčka zůstávají.

To jsem ted uplne asi nepochopil, v C bych mel design takovy, ze polymorfismus budu delat jen  nad funkcemi, nikoliv nad strukturami. Nad strukturami navic asi uplne polymorfismus delat nepotrebuju.

Mimochodem jde v C udelat to, ze 1 hlavicka bude pro 2 ruzne implementace? Ze by pak hlavicka hrala roli interfacu (neplest prosim s OOP) k vicero implementacim?

[Idris]

Ruční volání destruktorů nebo třeba zavírání souborů by mě už nebavilo. Proč bych to měl hlídat?

V cpp zadne rucni volani destruktoru neni potreba. Akorat lze presne zjistit kouknutim do kodu, kdy se tak stane.

Takže se zánikem posledního deskriptoru na objekt se automaticky zavolá jeho destruktor?

Tohle je definice destruktoru, nedeterministický úklid dělá finalizér. Některé jazyky mají obojí.