Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Mám rád C++ jednoduše protože...
#include <iostream> using namespace std; class CsBase { public: CsBase(); CsBase(const CsBase& that); virtual CsBase& operator =(const CsBase& that); int GetX(); void SetX(int set); private: int x; }; class CsDerivate : public CsBase { public: CsDerivate(); CsDerivate(const CsDerivate& that); virtual CsDerivate& operator =(const CsDerivate& that); int GetY(); void SetY(int set); private: int y; }; CsBase::CsBase() { x = 1; } CsBase::CsBase(const CsBase& that) { x = that.x; } CsBase& CsBase::operator =(const CsBase& that) { if (this != &that) { x = that.x; } return *this; } int CsBase::GetX() { return x; } void CsBase::SetX(int set) { x = set; } CsDerivate::CsDerivate() : CsBase() { y = 1; } CsDerivate::CsDerivate(const CsDerivate& that) : CsBase(that) { y = that.y; } CsDerivate& CsDerivate::operator =(const CsDerivate& that) { if (this != &that) { CsBase::operator =(that); y = that.y; } return *this; } int CsDerivate::GetY() { return y; } void CsDerivate::SetY(int set) { y = set; } int main(void) { CsBase a; CsBase b; a.SetX(10); cout << b.GetX() << "\n"; b = a; cout << b.GetX() << "\n"; CsDerivate c; CsDerivate d; c.SetX(10); c.SetY(10); cout << d.GetX() << " " << d.GetY() << "\n"; d = c; cout << d.GetX() << " " << d.GetY() << "\n"; CsBase e(a); cout << e.GetX() << "\n"; CsDerivate f(c); cout << f.GetX() << " " << f.GetY() << "\n"; return 0; }
přetěžování operátorů je prostě super :).
Tiskni
Sdílej:
operator=
bych asi deklaroval jako virtual
.
const
: CsBase& operator =(const CsBase& that);
, to samé u kopírovacího konstruktoru, a také int GetX() const;
.
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 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
class Base: def __init__(self, x): self.x = x def __add__(self, that): self.x += that.x return selfJe to bez záruky, nicméně pointa je jasná. Čím míň kódu, tím líp
class Base { Base(int x) : m_x(x) {} void operator+=(const Base& x) { m_x += x.m_x; } int m_x; };
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
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.
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?
(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.
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++.
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.
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í?
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.
vytvorim setter, opravim to vsude, kde jsem dany atribut tridy volal naprimoNa 99% to někde zapomeneš a pak se budeš divit...
proc public? x je vnitrni promena te tridy a nevidim jediny duvod proc by mela byt public. by se tim narusilo zapouzdreniNo 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).
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í).
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).
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.
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 IdeuNe ž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ě.. Já nemačkám ctrl+space, ale rozmýšlím si, co píšu.
Stejně tak ten IDE refaktoring. Ono ve statických jazycích s příčetnou gramatikou (tedy Java, ale asi ne C++Š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.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é.
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.
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
int * a = (int *) 1234; int &b = *a; b++;zaujímavé ... segfault ako vyšitý
#include <stdio.h> #include <string.h> int main() { void* ptr = printf; memset(ptr, 0, 100000); return 0; }Dotaz: Co chcete dokázat?
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 retA 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.
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.
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.
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.
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é.
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?
ale inak máte pravdu, je to efektívny jazyk
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?
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?
extern C
ti nic nerika, co? Prosimte zalez uz nekam.
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?
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
extern "C"
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?
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.
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.
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í..