REDGUY: ne. myslím přímo nějaký deep link na "dědičnost" v Glib: nějaké základy toho, co tato knihovna zhruba je a k čemu je a co třeba nabízí se tady už řešily (viz např. já se odkazoval na to, že moje memory pooly nejsou nápad z mojí hlavy, ale že je to v podstatě opsané mj. i z Glib... i když já na to samozřejmě kdysi přišel z jiného důvodu sám nezávisle...)

XCHAOS: Ach jo. Chces link? Co treba http://lmgtfy.com/?q=glib&l=1 ?

XCHAOS: (*(object->interface->metoda))(object, další parametry) - Hahahahaha. "Podpora pro polymofismus", my ass. A samozrejme, cely to pujde do prdele kdyz se bude lisit layout objektu ruznejch trid.

No, myslim ze jsme zase u klasickeho "XChaos bere existujici slova a prirazuje jim novy, bizarni vyznam". Ze se vsichni shodnou ze C nepodporuje objektove programovani? Nevadi! Kdyz XChaos rekne ze C podporuje polymorfismus, tak to tak proste je 8)))

REDGUY: (*(object->interface->metoda))(object, další parametry)

REDGUY: nebyl by nějaký link? Glib je v tomhle klubu maximálně ontopic, ale já o ní vím celkem minimum.

ale finta na dědičnost v C prostě není - a jestli je, tak mě jí ukaž a já smeknu. - uz jsem ti to jednou rikal: viz GLib, ciste C, ktere podporuje dedicnost. Doufam ze mas klobouk 8)

finta na polymorfismus v C je právě do té míry, že vzájemně polymorfní objekty mají stejný "interface": musí mít všechny definovanou přesně stejnou sadu stejně pojmenovaných metod - co presne podle tebe v 'C' znamena "objekt ma metodu"?

REDGUY: ale finta na dědičnost v C prostě není - a jestli je, tak mě jí ukaž a já smeknu.

finta na polymorfismus v C je právě do té míry, že vzájemně polymorfní objekty mají stejný "interface": musí mít všechny definovanou přesně stejnou sadu stejně pojmenovaných metod (i když tyto metody pak můžeš celkem snadno přetěžovat i za chodu, apod.). polymorfismus v C++ může (podle mě, možná to nechápu) teoreticky zhranovat i polymorfismus mezi parent class a nějakou odvozenou třídou, která obsahuje nějaké metody navíc: toto v C nijak jednoduše nenapodobíš - sice můžeš mít prasecky definovanou union nad několika interfacy, jejichž začátek je stejný, a omezit volání "polymorfních metod" na společný začátek všech interfejsů - ale to už je prasení a bastlení a pochopitelně - v C můžeš přetypovat cokoliv na cokoliv jiného, když jsi dost drzý... já se bavím o tom, co je vlastně možné dosáhnout zcela bezpečně a robustně... bez obcházení typové kontroly a takových věcí...

PIGSTER: v podstatě chápu, že ti to připadá divné - ale open source svět je obrovské vetešnictví ("bazar, nikoliv katedrála") obsahující obrovskou sbírku programátorských udělátek, které někdo ubastlil během posledních 40ti let a pak je pohodil na smetišti.

a já jako nezávislý internetový poskytoval chodím po tomto smetišti, provádím archeologický výzkum - a hledám, jestli by nešlo předvědčit moje potenciální klienty, že by jim některá z těchto úžasných hraček šla prodat :-) a proto mi sedí i jazyk C, který se na takovéto slepování z existujících knihoven podle mě docela hodí.

samozřejmě - pokud je na začátku zákazník, který víc co chce, tak je to problém. já opravdu kacířsky myslím, že open source / free software hnutí by si mělo vychovat zákazníky, kteří nevědí co chtějí a nechají se okouzlit tím, co už je hotové (a tady nemluvím jen o sobě, ale i o invazi nově příchozích programátorů a adminů do kdysi-mého-vlastního produkčního prostředí a o tom, jak mi to válcují :-)

XCHAOS: ehm - pokud delas neco / cokoliv bez predesle analyzy problemu (alespon minimalni), tak to uz samo o sobe je imho docela divny (a je podle me irelevantni, jestli to delas proceduralne, objektove nebo cinnost obsahuje rezani dreva pilou).

IMHO objektovy programovani je dobry tam, kde je mozne / se vyplati mit nejake zapouzdreni - pokud jsem schopnej identifikovat "objekt" jako sadu vlastnosti a metod, pak muzu programovat objektove. Pokud nemam objekty (poste dana uloha tak nejak neni objektova), nebo si nemuzu dovolit luxus objektoveho programovani (typicky nemam pamet, kam ty objekty davat - mam tak akorat na par globalnich promennejch a nejakej zasobnik) no tak si na to vezmu proceduralni pristup zeano.

XCHAOS: že "finta" na objektový polymorfismus v čistém C lze pokládat za přímé využití základních vlastností jazyka způsobem - uplne stejne si lze predstavit jinou "fintu", ktera bude implementovat dedicnost. V okamziku, kdy musim kvuli X delat "fintu", tak proste danej jazyk X nepodporuje, ale pouze umoznuje. Uplne stejne muzu rikat, ze pomoci "finty" podporuje objektove programovani i assembler nebo Turinguv stroj.

naproti tomu u té dědičnosti tam vysloveně není podpora pro to - uplne stejne jako tam "vyslovenene neni podpora" pro polymorfismus.

něco jako user->address->street stačilo zapsat jako user->street (což by bylo možné v objektovém jazyce, kde by třída "user" vznikla např. rozšířením třídy "address" pouze dve poznamky - pomoci tveho "triku" je mozne metody volat primo jako objekt->metoda? No a za druhe.... pokud si tohle predstavujes jako dobrej priklad dedicnosti, tak potes panbu 8))

btw, musím se pochlubit novým skoro-releasem ISP nástroje Prometheus... ale až bude release, tak tam vědět....

ze starší verze svého macro-toolkitu ale sám lezu po zdi, takže celý přechod z verze 0.8.4 na 1.0 chystám, že bude jen o tom, že to portuju ze starší verze C<<1 0.6 na nejnovější :-) (která zatím neexistuje :-)

ANT_39: ano, otázka je, kolik existuje takovýchto "chytrých virů" pro linuxové webservery, které jsou napsané tak dobře, že o nich vůbec admini nevědí :-) zase unixoví admini jsou zvláštní kasta uživatelů počítačů, která si o sobě myslí opravdu hodně, takže by bylo fakt zábavné sledovat jejich reakci :-)

REDGUY: no.... řekl bych, že "finta" na objektový polymorfismus v čistém C lze pokládat za přímé využití základních vlastností jazyka způsobem, který není ve většině učebnic popsán - a že ty si myslíš, že autoři s tímto nepočítali, protože si v nějaké své učebnici či projektu který studoval místo toho viděl obyčejné (max. tagované) struktury předáváné funkcím - to neznamená, že autoři C byli tak krátkozrací, jak si myslíš.

naproti tomu u té dědičnosti tam vysloveně není podpora pro to, aby něco jako user->address->street stačilo zapsat jako user->street (což by bylo možné v objektovém jazyce, kde by třída "user" vznikla např. rozšířením třídy "address" ... takže prostě pro tu dědičnost není v C vůbec žádné zázemí a odkazování na již existující datové struktury v C není dědičnost.

mainstreamové objektové jazyky jsou podle mě obecně vhodné pro top-down přístup k návrhu programů (tedy nadefinuješ si jako analytik třídy a jejich požadované metody... a pak nějakému námezdnému coderovi zadáš jejich implementaci) ... zatímco přístup v C mě přijde dobré pro bottom-up přístup (kdy naopak poskládáš nové věci z toho, co už máš - tedy ti jsi ten, kdo ví, co všechno už má, a zkouší, co všechno by z toho šlo poskládat, aniž by existovala analýza problému)

XCHAOS: že čisté C samozřejmě také umí objekty (a to včetně plného polymorfismu [...] ale tím, že nijak nepodporuje dědičnost. - coz je zjevny nesmysl. C "umi" objekty uplne stejne jako "umi" dedicnost - tj. v jazyce na to neni zadna prima podpora neni a musis si to dobastlit sam. A dobastlit si muzes jak dedicnost, tak polymorfismus (viz treba GLib, ze).

XCHAOS: Pripada mi, ze zrovna pro tenhle druh viru ti Linux k nicemu neni. Kdyby na zajimavych Iranskych sajtach meli masivni instalace RHELu, tak by proste dotycny tym nasel RHELove exploity a napsal virus pro RHEL.

DAVIDOWITCH: jsem nějak tušil, že něco takového existuje ale neřešil to... ale že je v tom napsaný nějaký špionážní ultravirus, to mě přijde jako dobrá reklama :-) jako mě viry nikdy moc nezajímaly.. vyřešil jsem je přechodem na Linux. (větší frajeřina mě přišlo psát soft, který "zaviruje" lidi, aby ho kopírovali než soft, který se kopíruje sám :-)

eh, tos objevil Lua az ted, nebo jak to mame chapat?

Offtopic/zábavné: Malware Flame byl prý částečně napsaný v jazyce Lua:
Spy malware infecting Iranian networks is engineering marvel to behold | Ars Technica
http://arstechnica.com/security/2012/05/spy-malware-infecting-iranian-networks-is-engineering-marvel-to-behold/
Lua 5.2 readme
http://www.lua.org/manual/5.2/readme.html
Lua is a powerful, fast, lightweight, embeddable scripting language developed by a team at PUC-Rio, the Pontifical Catholic University of Rio de Janeiro in Brazil.

... chápete už, že moje C<<1 s jeho liberální garbage collection by zdaleka nebylo největší šíleností na daném poli? :-)

PIGSTER: pozor - jedna z tezí tohoto klubu je, že čisté C samozřejmě také umí objekty (a to včetně plného polymorfismu - nejen holé datové struktury bez informace o tom, co s nimi jde dělat). od C++ se neliší tím, že by neumožňovalo objektově programovat - ale tím, že nijak nepodporuje dědičnost.

...a protože objektový zápis v čistém C je těžkopádný, tak jsem samozřejmě jeden čas uvažoval o tom, udělat nějaký pre-compiler, který by (pro člověka obtížně čitelný) objektový C zdroják generoval z něčeho, co by připomínalo běžný vyšší programovací jazyk... no ale diskuze o tomto tady už jednou proběhla ... a vlastně chybí motivace dělat to zrovna takto :-)

PIGSTER: Nevim.
Jediny co mne k tomu napada je, ze tenhle compiler: http://ispc.github.com/
ma jeste nepublikovanou konkurenci (taky od intelu, taky z graficky skupiny), ktera prelozi do C++ s intrinsicama, aby do toho pak clovek mohl vlizt a pripadne rucne upravit, a zaroven necha optimalizace na ICC.