Hříchy mládí

13.7.2013 18:22 | Přečteno: 1600×

Při procházení starých zdrojových kódů se občas narazí na pěkná zvěrstva.

#ifndef XDBOBJECT_H
#define XDBOBJECT_H

template< class T> inline T &XObject(void *ptr) {
   return **(T **) ((char *) ptr + sizeof(void *));
}

template< class T> inline const T &XObject(const void *ptr) {
   return **(T **) ((const char *) ptr + sizeof(void *));
}

#endif // XDBOBJECT_H

       

Komentáře

[rufuss]

Lol...

[Jozin]

jo, taky jsem to delal, ze sem zo tim #endif psal v komentari k cemu to patri, ale rada kompilatoru rvala, tak sem to po case nechal.

[David Watzke]

O to tam asi nešlo ale když už o tom mluvíš, tak kterým kompilátorům to vadí? Nikdy jsem nenarazil na problém.

[jekub]

mám dojem že msc kolem verze 1.6 eště v dosu. Nebo možná Borland, tam se to muselo tuším explicitně povolit.

[Sten]

Vadí to novějším kompilátorům, pokud to není komentář, ale je to #endif XDBOBJECT_H

Některé starší kompilátory (a nejspíš MSVC stále) tohle berou jako legitimní, zatímco třeba novější GCC řve, že se mu to vůbec nelíbí.

[Bystroushaak]

Co to je?

[jekub]

Potřeboval jsem se dostat k private věcem a úpravou .h bych porušil licenci.

[homer]

Pokud je tam explicitne uvedeny private a nespoleha se na defaultni viditelnost tak se to da celkem snadno resit pomoci:

#define private public
#include "x.h"

[__dark__]

Nebo

#define class struct

v implicitnim pripade, fuj:)

[homer]

Pravda, ale tahle verze muze rozbit nejaky kod.

Napr pokud nekdo pouziva u sablon class misto typename, tak zmena na struct nebude fungovat.

A i kdyz dusledne pouziva typename, tak treba v tomhle pripade se class nevyhne:

template<template<typename T> class U> struct X { };

[homer]

jinak jeste bych doplnil, ze to ze v c++ neni mozny se nejak rozume dostat k private atributum povazuju za chybu jazyka.

Osobne radsi private promenny nejak vhodne oznacim (treba podtrzitkem na zacatku), cimz rikam pristup na vlastni nebezpeci, ale pokud to chces risknout tak ti v tom nebudu branit.

Programatori nejsou hlupaci (nebo by nemeli byt) a snazit se je takhle kontrolovat stejne nikam nevede...

[Miloslav Ponkrác]

Já považuji za chybu jazyka, pokud:

a) V programovacím jazyce je možné k privátním atributům nějak přímo dostat.

b) Pokud má programovací jazyk navržená práva tak jednoduše, že je nutné sem tam zveřejňovat privátní věci (jako Java).

Pokud je třeba přistupovat k privátním atributům v C++, jedná se o špatný návrh interface či API a někdo to nenavrhl dobře.

Privátní věci jsou privátní proto, že se k nim nemá nikdo dostat. Politicko korektní významy slova „privátní“ v Orwellovském smyslu a nebo ve smysl americké špionážní definici slova soukromí – by v programovacím jazyce neměla co dělat.

A ano, jazyk by měl programátory kontrolovat a rozumně omezovat. Patří to do popisu práce programovacích jazyků.

Omezení přístupu k různým identifikátorům jen na určitá místa je nedílnou součástí všech jazyků od počátku. Je to součástí strategie, které říká, že program, kde všechny identifikátory jsou přístupné globálně + hloupý programátor, který nerespektuje omezení viditelnosti identifikátorů a hackuje nad nimi a vytváří špagetový systém vazeb v programu obvykle nevytvoří funkční a bezchybný program. I když se většina programátorů kasá, že jsou chytří, jejich mozek je zoufale zrazuje. Zatímco kompilátor nemá problém udržet přehled nad miliardou identifikátorů, lidský mozek selhává už u pár desítek či stovek. A pak šlus.

Programátoři jsou hloupí, protože jsou lidé a mají jen lidský mozek.

[dumblob]

Let the flame begin!

A ano, jazyk by měl programátory kontrolovat

To ano (kontrolovat ve smyslu pomahat).

a rozumně omezovat. Patří to do popisu práce programovacích jazyků.

To ani nahodou - jeste jsem nevidel problem z realneho sveta programovani (kde je neomezene casove okno), ktery by sel resit pri zachovani omezovani jazykem (tedy bez ruznych hacku).

[Miloslav Ponkrác]

V čem jazyk programátorovi pomáhá, když nedokáže vynutit ani private?

On Vám někdo brání psát programy bez jediného slova private?

---

„To ani nahodou - jeste jsem nevidel problem z realneho sveta programovani (kde je neomezene casove okno), ktery by sel resit pri zachovani omezovani jazykem (tedy bez ruznych hacku).“

To, že jste prase, a nejste schopen čistě napsat žádný program, tím bych se moc nechlubil. Nehažte své handicapy na jazyk, je to Vaše chyba.

Protože já i stovky dalších lidí co znám nemáme problém psát při zachování omezování jazykem v C++.

Pokud si špatně zvolíte API a interface, pak v jakémkoli jazyce budete muset hackovat. Je to ovšem chyba Vaše, nikoli jazyka.

[dumblob]

V čem jazyk programátorovi pomáhá, když nedokáže vynutit ani private?

Prave tim nevynucovanim

On Vám někdo brání psát programy bez jediného slova private?

Mne ne, ale dost casto se pouziti techto ficur jazyka uci uplne spatne a s vysledky se myslim setkavate i Vy. Tvurci jazyku se temi ficurami chlubi, povazuji tyhle "zbytecnosti" za must-have atd. Zacinajici programatori tedy nabudou dojmu, ze pouziti techto ficur je neco spravneho, ba dokonce bezpodminecneho a narvou to pak vsude -> fail.

Btw co se praseni tyce, uz jsme videl nekolik ekvivalentnich programu nebo dokonce primo prepisu z jednodussich jazyku (napr. Python) do tech slozitejsich (napr. C++) a mira praseni byla v obou stejna - troufam si tedy tvrdit, ze na praseni tyto omezujici vlastnosti jazyka nemaji vliv (nebo opravdu margialni).

[Miloslav Ponkrác]

„Mne ne, ale dost casto se pouziti techto ficur jazyka uci uplne spatne a s vysledky se myslim setkavate i Vy. Tvurci jazyku se temi ficurami chlubi, povazuji tyhle "zbytecnosti" za must-have atd. Zacinajici programatori tedy nabudou dojmu, ze pouziti techto ficur je neco spravneho, ba dokonce bezpodminecneho a narvou to pak vsude -> fail.“

Pak je to ovšem chyba učitelů a chyba programátorů, že něco špatně používají.

Zkuste špatně používat kyanid draselný, nebo methyalkohol či se koupat v kyselině sírové a uvidíte, že příroda a realita je plná featur, které příroda dokáže velmi drsně vynucovat. A hacky moc nepomáhají.

Jednoduše člověk, který se nedokáže přizpůsobit základním vlastnostem reality, ztratil základní životaschopnost – totiž schopnost přizpůsobit se prostředí. Podle Darwina by měl vyhynout.

A ano, použití omezování viditelnosti identifikátorů je must-have, naprosto základní featura, kterou by se programátoři měli naučit mezi prvními. Pravidlo, že žádný identifikátor nebude viditelný dále, než je nutné je naprosto základní pravidlo programátora, který chce napsat něco většího, než hello world program. V týmu je pak takové pravidlo otázkou toho, zda program bude stát X peněz, nebo miliónkrát X peněz.

Použití private, a jeho důsledné vynucování u některých jazyků je dar z nebes. Je to obrovská pomoc programátorovi od velkého Manitoua.

---

„Btw co se praseni tyce, uz jsme videl nekolik ekvivalentnich programu nebo dokonce primo prepisu z jednodussich jazyku (napr. Python) do tech slozitejsich (napr. C++) a mira praseni byla v obou stejna - troufam si tedy tvrdit, ze na praseni tyto omezujici“

Možná byste se měl dívat na kódy mistrů a lidí, kteří umí programovat. A to pokud možno i v cílovém jazyku, do kterého přepisují.

Podívejte, já Vám tento příspěvek přeložím do angličtiny nebo francouzštiny, případně němčiny – ale všechny tři překlady nebudou za mnoho stát. Říká to něco o tom, jak kvalitní vyjadřovací schopnost má angličtina, němčina nebo francouzština? Ani náhodou.

Pokud se učíte od hochštaplerů, pak Vaše závěry moc platné nebudou.

Učte se od mistrů, ne od neumětelů.

Víc k tomu nemám co říct.

[dumblob]

Pak je to ovšem chyba učitelů a chyba programátorů, že něco špatně používají.

Nesouhlasim, protoze pokud je nekde neco navic, tak je to z meho pohledu zbytecne.

Zkuste špatně používat kyanid draselný, nebo methyalkohol či se koupat v kyselině sírové a uvidíte, že příroda a realita je plná featur, které příroda dokáže velmi drsně vynucovat. A hacky moc nepomáhají.

Toto neni vynucovani, ale presne to co pozaduji. Tedy aby me jazyk neomezoval (priroda mi dovoli nevhodne pouzivat vami uvedene latky).

Možná byste se měl dívat na kódy mistrů a lidí, kteří umí programovat. A to pokud možno i v cílovém jazyku, do kterého přepisují.

Vetsinou mi to neni doprano - asi sedim v realnem svete a ne v izolovane soustave mezi dvema borci, kteri si tresou spolecne rukou jaky krasny jazyk si sami pro sebe vytvorili.

Podívejte, já Vám tento příspěvek přeložím do angličtiny nebo francouzštiny, případně němčiny – ale všechny tři překlady nebudou za mnoho stát. Říká to něco o tom, jak kvalitní vyjadřovací schopnost má angličtina, němčina nebo francouzština? Ani náhodou.

Domnivam se, ze u programovaciho jazyka vubec nezalezi na jeho vyjadrovacich schopnostech at uz jsou jakekoliv, ale na jeho realne pouzitelnosti (tuto vsak zrejme definuji jinak nez Vy).

[Miloslav Ponkrác]

„Toto neni vynucovani, ale presne to co pozaduji. Tedy aby me jazyk neomezoval (priroda mi dovoli nevhodne pouzivat vami uvedene latky).“

Jazyk Vás neomezuje. Jazyk Vám dovolí nepoužívat klíčové slovo private. Nechápu, na co si stěžujete?

„Vetsinou mi to neni doprano - asi sedim v realnem svete a ne v izolovane soustave mezi dvema borci, kteri si tresou spolecne rukou jaky krasny jazyk si sami pro sebe vytvorili.“

I já sedám v reálném světě. A věřte, že v reálném světě jsou mistři (vedle dalších lidí). Existují mistrovští houslisté, mistrovští programátoři, atd. pro všechny obory.

„Domnivam se, ze u programovaciho jazyka vubec nezalezi na jeho vyjadrovacich schopnostech at uz jsou jakekoliv, ale na jeho realne pouzitelnosti (tuto vsak zrejme definuji jinak nez Vy).“

Jako vata je tento odstavec dobrý. Jinak v něm nevidím jediný argument k tématu.

[dumblob]

Jazyk Vás neomezuje. Jazyk Vám dovolí nepoužívat klíčové slovo private. Nechápu, na co si stěžujete?

Jazyk umi zbytecnost -> programator ji zbytecne pouziva -> ja z toho mam problem, ktery musim resit -> jsem omezovan jazykem (protoze ten problem musim resit v tom jazyku, kde to je nejake hnusne hackovani)

I já sedám v reálném světě. A věřte, že v reálném světě jsou mistři (vedle dalších lidí). Existují mistrovští houslisté, mistrovští programátoři, atd. pro všechny obory.

Prirovnanim z realneho non-IT sveta bych se v pripade IT vyhnul. V tomto pripade je mylne proto, ze kod tu s nami je nezmeneny mnoho let a meni se pouze pozadavky (kde pozadavek neni subjektivniho charakteru), kdezto na dobre zahraneho Bacha nebo na dobre repovanou skladbu se pozadavky opravdu nemeni! Podstatnych rozdilu by se samozrejme naslo vice...

Jako vata je tento odstavec dobrý. Jinak v něm nevidím jediný argument k tématu.

Tedy znovu - jazyk s malym poctem omezeni je realne mnohem pouzitelnejsi nez jazyk s vetsim poctem omezeni.

[Filip Svoboda]

Ochrana privatnich clenu neni zbytecnost, je to dobra vlastnost.

Kdyz programator napise: private int x; tak muze psat dalsi kod s predpokladem, ze mimo jeho tridu mu nikdo nikdy z vnejsku hodnotu te promenne x nemuze modifikovat, a to ani chybou, hackem, proste nijak. To je presne to co chtel a proto tam taky to private napsal.

Kdyz pise private i na promenny ktery by se mohli hodit z vnejsku tak zbytecne skryva mozne funkce/nastaveni pred okolnim svetem, kdyz nepise private nikde tak riskuje rozbyti vnitrniho datoveho modelu nejakym vnejsim kodem (a to mnohdy jen v prazvlastni konstalaci podminek - a coz tezko ladi)

[pavlix]

Užitečnost oddělení veřejných a privátních členů tu pokud vím nikdo nezpochybňoval. Nicméně chápat to jako bezpodmínečnou ochranu proti úmyslnému přístupu, tedy mimojiné ochranu proti debugování a testování, to mi přijde značně extremistické, náboženské, netechnické a neužitečné.

[pavlix]

Samé moudře znějící argumenty, za kterými se podle mě ve skutečnosti skrývá notná dávka hulení. Ve skutečnosti jsem po delší době došel ke stejnému závěru, tedy že je pro život jednodušší private nevynucovat, nýbrž označovat a tedy příležitostné uživatele private věcí nebuzerovat, nýbrž spoléhat na to, že vědí, co dělají. Asi to není dostatečně enterprisy a nefunguje to dobře s cvičenými opicemi, ale to jde naštěstí mimo mé zkušenosti.

Typicky narážím na to, že pro účely testování či debugování potřebuju API, které bych ve skutečném programu nikdy neměl a nesměl použít. Je možnost žít s tím, co je a řešit problém složitější cestou. Nebo je možné privátní API použít. Pak je ale lepší, když má pro to jazyk přímou podporu.

Speciální označení by mělo průměrně inteligentního člověka trknout dostatečně. Pokud ne, tak by mělo dojít na warningy/errory, které se dají explicitně vypnout.

[dumblob]

+1

[Miloslav Ponkrác]

Jestliže programátoři vědí, co dělají, pak bych zkrouhnul u kompilátorů fázi syntaktické kontroly – to je jenom buzerování programátora. Stejně tak bych vyhodil fázi testování a ladění programu. A vyhodil testery. Programátoři to tedy udělají bez chyby a vědí co dělají.

Zvláštní, já programuji 25 let, a dozvídám se, co věcí najednou nejde.

Jakýkoli jazyk má přímou podporu pro cokoli. Není třeba hackovat žádné private. Jaké si to uděláte, takové to máte.

Hackování jazyka jako běžnou formu programování beru jako podřezávání si větve na které sedíte. On jazyk není Váš nepřítel, není to terorista, je to pomocník. Nemusíte se snažit ho přeprat, stačí ho využít se vším čím vám pomáhá.

Ale děláte mi radost. Kdysi jsem si myslel, že jsem starý a mladí mě převálcují. Bylo mi divné, že v posledních 10 letech si mě najímají lidé na to, abych jim udělal analýzu, interface, a další. Prý to té dnešní generaci svěřovat nechtějí, protože jsou prasata a když něco navrhnout, musí se to po prá letech předělávat, hackovat, prasit a stejně to drhne.

Prosím abyste dál udržovali stejné názory. Budu rád za maximum zakázek. Nejhorší je, když by mladí programátoři dělali věci správně, to bych byl v ….

A tím končím k této debatě.

[pavlix]

Snůška stařeckých keců, argument k věci ani jeden.

[Miloslav Ponkrác]

Argument je jednoduchý.

Pavlix a dumblob se kasají, jak nejlepší je hackovat si vlastní jazyk, ve kterém píši. Přeji jim hodně štěstí. Nicméně rozhodně nedoporučuji napodobovat.

Tisíce jiných lidí dělají to samé co pavlix a dumblob, a dělají to jinak. Pochopili, že odkrývat identifikátory všem, pokud jazyk obsahuje nástroj na jejich skrytí – tedy na možnost ohlídání, že to někdo buď a) z nepozornosti, b) s prasáckými choutkami ačkoli to nepotřebuje – pak ho s radostí využijí, protože jim šetří práci, čas a peníze.

Jistě, čas od času se vyskytne nutnost něco ohackovat, ovšem velmi zřídka. Asi tak jednou za několik let.

Programovací jazyk je od toho, aby pomáhal. Nikdo nikoho nenutí používat klíčová slova, která nechce.

Programátoři na celém světě se snaží, aby kompilátor byl maximálně restriktivní a programovací jazyk obsahoval co nejvíce nástrojů na kontrolu jejich kódu. Všichni programátoři, s výjimkou pavlixe a dumbloba tak nějak vědí, že ladění a debugování je dost dlouhá fáze, a že chyby v programu jsou spíše pravidlem nebo výjimkou. Jejich odchytávání zabere dost času. Pouze velmi nesebekritičtí programátoři si věří natolik, že si myslí, že chyby dělat nebudou. Kromě pavlixe a dumbloba jsem za svůj život žádné jiné nepoznal, a je možné že několik se jich ještě najde.

Jinak řečeno, pokud nepíšete jednorázový program, vyplatí se psaní programu směřovat spíše s tím, aby byl co nejčitelnější a co nejudržovatelnější, než k rychlosti psaní. Obvykle se delší programy déle ladí, debugují a testují, než píší.

Možná se budete divit, ale třeba v Linux kernelu se našly chyby, které tam byly řadu let. Těžko můžete podceňovat programátory kernelu, že programují špatně. Škoda, že na kernelu neprogramuje pavlix a dumblog, protože ti jsou tak chytří, že jako programátoři by si ohlídali, že chyba by ani nevznikla, natož aby tam byla několik let.

Není lepšího léku, než napsat a udržovat rozsáhlý program.

[dumblob]

Škoda, že na kernelu neprogramuje pavlix a dumblog, protože ti jsou tak chytří, že jako programátoři by si ohlídali, že chyba by ani nevznikla, natož aby tam byla několik let.

Za pavlixe mluvit nemuzu, ale osobne jsem uz do kernelu hrabnul a hodlam v tom pokracovat (zatim to neni ve vanilce, ale delam na tom). Takze se teste, bude v nem mnohem vice chyb, ktere se budou hledat radu let.

[Miloslav Ponkrác]

To děláte dobře. Protože oni vám to budou vracet k přepracování tak dlouho, dokud budete zastávat filozofii psaní kódu, kterou jste tu prezentoval.

Nakonec se to naučíte správně, nebo to vzdáte.

[dumblob]

Uvidime za par mesicu, jestli uz prvni zadost odmitnou (a z jakeho duvodu ).

[homer]

To ze programatori nedelaji chyby tady rikas jenom ty. Ostatni nic takovyho nerekli.

Zrovna tak nikdo nerika ze bys mel bezne pristupovat k private atributum. Proto to specialni pojmenovani. Aby bylo jasny ze je to na vlastni nebezpeci, a pokud mozno se tomu vyhnout.

Ale kdyz uz k tomu z nejakyho duvodu pristoupit potrebujes, tak typni si jak tam udelas min chyb:

1. kdyz mas nejakou rozumnou moznost jak to obejit

2. kdyz je jazyk naprosto striktni a ty musis delat hacky jako autor blogu, nebo jako to co navrhujes dole...

[pavlix]

Jsem rád, že jiní takové problémy se čtením nemají. Rád bych ještě podtrhnul to, že přístup k privátnímu API by měl být skutečně vyhrazen jen zvláštním situacím, mezi které řadím například ladění a testování.

[dumblob]

+1

Radeji to zopakuji:

Přístup k privátnímu API by měl být skutečně vyhrazen jen zvláštním situacím, mezi které řadím například ladění a testování.

[pavlix]

Až budeš reagovat na to, co skutečně tvrdíme a ne ze sebe sypat tohle, možná bude mít diskuze nějaký smysl.

Obvykle se delší programy déle ladí, debugují a testují, než píší.

Což podtrhnuje můj výše uvedený názor, že je dobré mit k testování a ladění co nejlepší prostředky a nemuset kvůli tomu vymýšlet nějaké speciální hacky. Popravdě řečeno mám pocit, že mé komentáře čteš pozpátku nebo vzůru nohama, jinak bys z nich těžko mohl odvodit téměř přesný opak toho, co se v nich píše.

Možná se budete divit, ale třeba v Linux kernelu se našly chyby, které tam byly řadu let. Těžko můžete podceňovat programátory kernelu, že programují špatně. Škoda, že na kernelu neprogramuje pavlix a dumblog, protože ti jsou tak chytří, že jako programátoři by si ohlídali, že chyba by ani nevznikla, natož aby tam byla několik let.

Zajímavé větné konstrukce. V oblasti sítí jsem několik takových chyb hlásil a další čekají, až budu mít čas je pořádně ověřit. Důkazů, že (někteří) programátoři kernelu (někdy) programují špatně a výsledky jejich práce se dostanou do upstreamu, je v tom síťovém kódu víc než dost. A nejedná se zdaleka jen o nějaká přehlédnutí, jsou to i zásadní návrhové chyby.

Ale to je na dlouhé povídání a s aplikačním programováním, kde se běžně používají cizí knihovny, to nemá nic moc společného.

[Gilhad]

Jakýkoli jazyk má přímou podporu pro cokoli.

No ja bych treba velice nerad zkousel resit nejake interrupty, real-time veci ci cokoli low-level napriklad v KARLOVI. Nejak mi tam ta prima podpora pro cokoli prijde ponekud nedostacujici ...

[Bystroushaak]

Pokud je třeba přistupovat k privátním atributům v C++, jedná se o špatný návrh interface či API a někdo to nenavrhl dobře.

Ano. Ale co dělat, když už se dostanu před takový kód?

[Miloslav Ponkrác]

Obalit ho vlastním rozhraním, kde přístupy uděláte dobře.

V nejhorším s tím, že obejdete a hacknete jednu věc, ale co nejčístěji, viz můj kód níže.

Ve vlastním zájmu si nebudete ve svém kódu kálet pod vlastní židli.

[homer]

Tak nevim jestli si tady z nas delas srandu...

Netvrd me ze nevidis ze tenhle tvuj kod;

struct ShadowAStruct
{
void** virtual_function_table; 
...

je 100x vetsi prasarna nez vypnuti private (napr. pomoci #define).

Pri zmenach v ty knihone bych musel presne synchronizovat i tuhle strukturu. A pravdepodobnost ze nekde pribude promenna a cely se to posune je mnohem vetsi nez pravdepodobnost nejaky zasadni zmeny kvuli ktery se zmeni funkce toho private atributu.

Navic kdyz to prelozim jinym prekladacem tak se to muze cely rozsipat...

[Miloslav Ponkrác]

1) Nejčistější je nemít private tam, kde k tomu chcete přistupovat zvenčí.

2) Pokud k tomu chcete přistupovat zvenčí, a je tam private, pak existuje jakž takž čisté klíčové slovo friend, kterým udělíte práva na přístup k private jen tam, kde je to třeba.

3) Jestli si myslíte, že jakýkoli hackovací kód se nemusí znovu zkontrolovat při změnách knihovny, tedy i ten, který popisuje autor v článku, pak nemám slov.

4) Jakýkoli hackovací kód přeložený jiným překladačem může fungovat jinak, i ten co napsal autor článku.

5) Vypnutí private pomocí #define nevypíná globálně private. Už jen proto, že private je výchozí stav pro class. Tedy private jsou i věci, které nemají klíčové slovo private.

Jinak řečeno, když si pokálíte vlastní nohy tím, že chcete obejít private, pak žádné řešení není ideální kromě:

1) Změny aby cílový kód nepotřeboval lézt do private.

2) Změny interface, aby private nebylo private.

3) Nebo přidání metody třídy, který vrací hodnotu privátního členu.

4) A dalších.

[homer]

1) Nejčistější je nemít private tam, kde k tomu chcete přistupovat zvenčí.

Jak tohle pomuze nekomu kdo se dostane ke kodu kde uz private je? Treba autor blogu.

2) Pokud k tomu chcete přistupovat zvenčí, a je tam private, pak existuje jakž takž čisté klíčové slovo friend, kterým udělíte práva na přístup k private jen tam, kde je to třeba.

jo a kdyby bylo mozne deklarovat friend i mimo tridu tak by to dost resilo.

3) Jestli si myslíte, že jakýkoli hackovací kód se nemusí znovu zkontrolovat při změnách knihovny, tedy i ten, který popisuje autor v článku, pak nemám slov.

uz zase si domejslis neco co ostatni nerekli...

4) Jakýkoli hackovací kód přeložený jiným překladačem může fungovat jinak, i ten co napsal autor článku.

Jak me muze prosta zmena private na public zpusobit ze to nekde bude fungovat a jinde ne? Prosil bych o konkretni priklad.

5) Vypnutí private pomocí #define nevypíná globálně private. Už jen proto, že private je výchozí stav pro class. Tedy private jsou i věci, které nemají klíčové slovo private.

to sam zminuju uz v prvnim prispevku...

[dumblob]

jo a kdyby bylo mozne deklarovat friend i mimo tridu tak by to dost resilo.

Tedka jak chteji zrychlit vydavani novych specifikaci C++, tak se mozna dozijeme toho, ze tam budou nastroje na omezovani a zaroven nastroje na ruseni techto omezeni (a tyto budou mit zase nejaka omezeni...) .

[jekub]

Tak to by mne jak nepřítele maker nenapadlo. Dobré.

[Bystroushaak]

Potřeboval jsem se dostat k private věcem a úpravou .h bych porušil licenci.

Heh, to bych z toho nevyčetl. Přibližně jsem pochopil co to dělá, ale ušel mi smysl :)

[Miloslav Ponkrác]

A kdyby chtěl programátor dělat tato přetypování čistě a jasně v kódu, napsal by:

---

struct ShadowAStruct

{

void** virtual_function_table;

int first_private_param;

char second_private_param;

};

---

inline ShadowAStruct * ConvertToShadowStruct(A * ptr)

{

return reinterpret_class<ShadowAStruct*>(ptr);

};

---

A bylo by jasno i po 10 letech, co kouzlí v kódu.

[jekub]

nechapu

[dolik.rce]

Jo, taky jsem zamlada psal obskurni pretypovani bez dokumentacnich komentaru vysvetlujicich o co tam jde...