• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    XCHAOSANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API
    /* Toto je klub především pro lidi, pro které je programování jednou z mnoha massive multiplayer online počítačových her, které lze hrát.
        V tomto klubu hrozí sémantická hereze a nezdravě vysoký obsah syntaktického cukru. Nevhodné pro algoritmické diabetiky.
        Od účastníků debaty se předpokládá automaticky přístup k instalovanému GNU C: sudo apt-get install build-essential
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    C (programovací jazyk)#C99 Heslo na české Wikipedii
    Jazyk C - Základy praktického programování V Praze 2oo7 pro SSPŠ Tomáš Harvie Mudruňka a kolektiv - jak si programování v C představuje většina lidí
    http://stevenkobes.com/ctest.html C Programming Puzzlers - nepouštějte se do flamewars v tomhle klubu, pokud neuhodnete aspoň polovinu správně!
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    http://en.wikipedia.org/wiki/C99 C99 is a modern dialect of the C programming language.
    http://cprogramminglanguage.net/ C programming language
    http://cprogramminglanguage.net/c-programming-language-tutorial.aspx C programming language - úvod
    http://en.wikipedia.org/wiki/Criticism_of_the_C_programming_language C makes it easy to shoot yourself in the foot. (ještě že ne do hlavy...)
    http://en.wikipedia.org/wiki/C_preprocessor
    http://gcc.gnu.org/onlinedocs/gcc/Variadic-Macros.html C99 makra s proměnným počtem argumentů - __VA_ARGS__
    http://gcc.gnu.org/onlinedocs/gcc/ GNU C Compiler
    http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Optimize-Options.html
    http://bellard.org/tcc/ Tiny C Compiler - prý C99 compliant (min. umí __VA_ARGS__) - vhodný pro skriptování v C - umí #!/usr/bin/tcc -run
    http://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest - pokud jste neviděli tohle, tak jste ještě neviděli opravdu nečitelný C zdroják
    http://bellard.org/otcc/ Obfuscated Tiny C Compiler - z tohohle vtípku vznikl Tiny C compiler
    http://en.wikipedia.org/wiki/ANSI_C Jak se střelit do nohy standardizovaným způsobem.
    http://eli-project.sourceforge.net/c_html/c.html ANSI C Specification
    http://www.lysator.liu.se/c/ Různý ANSI C bordel
    http://www.cs.rit.edu/~ats/books/ooc.pdf Object Oriented Programming with ANSI-C - a pak že to nejde
    http://en.wikipedia.org/wiki/Longjmp co jsou to setjmp()/longjmp() knihovní funkce (pro všechny, podle kterých to bez C++ try { } catch() ... nejde)
    http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/dcdc710c27f47c72 C neumí správně počítat (?)
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    http://www.fastcgi.com/ FastCGI is simple because it is actually CGI with only a few extensions.
    http://www.metalshell.com/source_code/18/Mysql_Select.html How to do a simple connection and select with mysql
    http://xmlsoft.org/ The XML C parser and toolkit of Gnome
    http://curl.haxx.se/libcurl/ libcurl - the multiprotocol file transfer library
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    https://dev.arachne.cz/svn/cll1h SVN/Trac jazyka C<<1 (user-friendly nadstavba nad ANSI C99 - ve stylu JQuery vs. JavaScript)
    Benchmark iterace a serializace stringů v různých jazycích vs. v C
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
        moderátor se velice zhruba řídí zvyklostmi moderace, která kdysi platila v řadě konferencí sítě FidoNet ... C != 0xdead */
    rozbalit záhlaví
    FLEGMA
    FLEGMA --- ---
    JANFROG:
    Kdyz uz jsme u tech zavadejicich vyroku:
    napriklad (muj oblibeny a v mnoha smerech prukopnicky :-) Self ma pouze delegovani a jen velmi tezko lze zpochybnit, ze to je OO jazyk.

    Ehm, otevrel jsem si dokument Self Power of Simplicity z roku 1987 a cituji:
    In SELF too, everything is an object. But, instead
    of a class pointer, a SELF object contains named slots which may store either state
    or behavior. If an object receives a message and it has no matching slot, the search
    continues via a parent pointer. This is how SELF implements inheritance. Inheritance
    in SELF allows objects to share behavior, which in turn allows the
    programmer to alter the behavior of many objects with a single change.


    Prototypes combine inheritance and instantiation to provide a framework that is simpler and more flexible than most object-oriented languages. Slots unite variables and procedures into a single construct. This permits the inheritance hierarchy to take over the function of lexical scoping in conventional languages.


    Nebo handbook k poslednimu releasu:
    Parent slots can be omitted from an object’s full
    name, since the slots in a parent are visible in the child via inheritance.


    Nebo z paperu "Inheritance and encapsulation in SELF":
    We believe there are two reasons to include inheritance in a dynamically typed language like SELF: malleability a reusability. Inheritance allows the behaviour common to set of objects to be factored into a single shared object...

    Inheritance encourages the reuse of code and data by allowing the programmer to write new abstractions in terms of existing abstractions. Programmers need only write the differences from existing code when defining new abstractions, the rest of the code may be shared among the old abstraction and
    the new abstraction. Improvements to one abstraction automatically propagate to every abstraction that shares the behaviour, further amplifying programmers power.


    Lepe bych to nenapsal aneb krasna definice dedicnosti jakozto principu.


    The common theme in malleability and reusability is sharing: one object is
    shared by other objects, promoting malleability and providing for reusability.
    Inheritance is just a declarative way of specifying which objects are shared by
    which other objects. One guiding principle of our design for inheritance in SELF,
    then, is that an object’s parents are treated as shared subparts of the object.


    atd. atd.

    Jiny typ dedicnosti, stale vsak dedicnost - to ze se misto volani metod/funkci nebo pristupu k atributum/fieldum parent tridy deleguje zprava parent objektu + to ze jde sdilet parent sloty je jen odlisnost v implementaci dedicnosti. Uz jen to, jak casto se pouziva v te specifikaci slovo parent na vysvetleni parent-child vztahu je dost vymluvne... Kdyz se vratim k pozadavku dedicnosti jako zakladnimu kriteriu OOP, tak plati dokonce i pro prukopniky/exoty jako Self, jako bonus k tomu maji stejny nazor na zakladni principy OOP prekvapive i autori ucebnic OOP programovani, nastesti v tom nejsem sam :-)

    Ze se v nasi pri na jedne strane objevil jako podpurny argument umirajici, archaicky a temer nepouzivany jazyk s nejakou roli v historii garbage collectoru a JITu a nulovou roli v soucasnosti je vec druha. A ano, existuji i objektove jazyky, kde nejsou atributy a pouziva je mene nez 1% programatoru. Muzeme je tedy s klidem nazvat mrtvou/slepou vyvojovou vetvi, za 20 let o nich mozna ? bude jednoradkova zminka na wikipedii - historii pisi vitezove ;-)
    FLEGMA
    FLEGMA --- ---
    JANFROG:
    Zapouzdreni jak ho chapu ja je podmnozinou loose coupling, tedy maximalni nezavislosti software komponent na sobe.
    Zaroven je take podminkou izolace komponent - kdyz budu mit vsechny atributy public a tak k nim pristupovat z ostatnich trid, tezko muzu vubec zacit uvazovat loose coupling a modularni architekture. Lisi se granularitou - zapouzdreni na urovni objektu, loose coupling je obecnejsi a muze byt na ruznych urovnich architektury.

    Bez dedeni se v celku bez vetsich problemu obejdes
    Nejdriv jsem ti chtel napsat, ze substituce dedeni kompozici a delegovanim povede ke spouste zbytecneho kodu navic (kopirovaci konstruktory + delegujici metody) + priklady, kdy se v jave bez dedeni urcite neobejdu, ale ted koukam, ze ten tvuj Self ma pro kopirovani vlastnosti objektu primo zabudovanou podporu diky prototypovani, zajimave.

    Takze slevuju: nektere jazyky mimo mainstream (krome Javascriptu, ten je rozsireny dost) splnuji kriteria OOP jazyka i bez klasickeho dedeni trid (class inheritance), protoze maji jine mechanismy na sdileni spolecne funkcionality :-) Zaroven mam ale pravdu, protoze pojem dedicnosti, resp. prototypove dedicnosti (prototype inheritance) se pouziva i pro Self...
    XCHAOS
    XCHAOS --- ---
    KEYMASTER: mno, většinou lidi přijmou nějaký programátorský styl (viz např. ten JS) předtím, než si vůbec uvědomí, že k nějakému přetěžování dochází. každopádně je to hezký příklad rozdíly mezi diskuzními fóry a sociálními sítěmi, protože to má z Twitteru - a tam to prostě retweetli ti, kterým se to líbilo a já byl jeden z nich a pak to zase další retweetli pro mě. tady je z toho celodenní debata.

    mno aspoň oceňuju, že si skoro jako jediný odpověděl na vtip vtipem a ne mínusem :-) (i když to jistě ještě můžeš dohnat)

    REDGUY: dobře - C je assembler původně optimalizovaný pro platformu, která dnes už neexistuje. původní C pro PDP-11 (nebo co to bylo) mapovalo každou instrukci jazyka na tuším právě jednu instrukci assembleru (nebo později dvě nebo něco - četl jsem něco v tomhle smyslu).

    to ale nutně neznamená, že ten assembler na který se to mapovalo, byl nutně špatný, nebo že filosofie C je špatná na platformě, která by přidala třeba pět nových aritmetických operátorů a k tomu několik na dané platformě nativních implementací funkcí typu memcpy() pomocí jediné ASM instrukce, apod.

    UETOYO: eh? to je snad samozřejmé, ne? otázka je, jestli něčemu pomůže, že '+' je v jiných jazycích jednou aritmetika a jednou řetězení. ať už se mi přetěžování líbí nebo ne (mě se když už líbí 3 * '-' == '---', ale přežiju bez toho), tak je z řady hledisek dobré, že věci, které nejsou aritmetická operace se tak netváří. nějaký fuzzy operátor by se mi líbil - ale jen když chci, aby to bylo fuzzy. Kdyby javascript psali Češi, pravděpodobně zahrne porovnávání stringů s diakritikou bez diakritiky (což je SUPER funkce, mimochodem - ale prostě hned v prvním examplu bych vysvětlil rozdíl mezi identitou objektu - tedy druhý objekt je pointerem/referencí na druhou, přesnou podobností (stejná sekvence bytů na různých adresách v paměti) a přibližnou rovností (která je sice dost možná nejžádanější funkcí, ale potřebuju předem vědět, do čeho jdu)

    např. skvělá věc C je, že vím, že operátor prostě nealokuje paměť (jestli se nic nezměnilo :-) což je dobrý důvod neřetězit stringy operátorem. to ten vtip ani neřešil.

    FLEGMA:
    JANFROG: heleďte, já tomu zas tolik nerozumím :-) ale pokud se obloukem vrátíme k tématu - teda jaký styl programování v C se dá dnes pokládat za korektní, bezpečný a všeobecně srozumitelný - tak nebudu proti.

    celkem i uznávám, že ANSI C objekty nejsou "opravdové objekty", ať už se kolem toho vymyslí jakýkoli syntaktický cukr navíc. otázka je, jestli to nakonec nejsou lepší objekty, než opravdové :-) každopádně poptávka po "něčem mezi C a C++" rozhodně existuje: spousta projektů v C++ využívá rozšíření velmi opatrně a umírněně, a je spousta pokusů vydat se od C jiným směrem, než k C++ (např. http://dlang.org/ - viptné je, že kde já si ve svém diaklektu C - t.č. u ledu - z Pascalu vypůjčil konstrukci program {}, tam oni si vypůjčili funkci writeln() :-) )

    mě by se v C líbilo několik věcí, na které jsem si zvykl v Pythonu. díky tomu, že tuším něco málo o tom "jak to funguje uvnitř" (jakkoliv je ta představa na dnes běžných HW platformách nepřesná) tak je mi jasné, co z toho by bylo zcela proti filosofii C a co by naopak šlo implementovat jednoduše. C je např. prakticky připravné na Python style immutable stringy - viz funkce asprintf(). Některé věci by to zpomalilo, ale tvrdím, že jediné bezpečné null-terminated stringy jsou právě immutable stringy, a že pokud se neprogramují nějaké hyper-super-optimalizace stringů (databázový engine, kernel), tak by v nějaké "učebnici C pro 21.století" měly být immutable stringy asi uvedené jako řešení pro začátečníky (místo nešťastné srtcpy()/strcat() rodiny funkcí)
    JANFROG
    JANFROG --- ---
    Uplne nejzakladnejsi principy OO jsou: dedeni,zapouzdreni, polymorfie a tyhle fundamenty nejsou navzajem zamenitelne.
    To je pomerne silne tvrzeni a - dle meho nazoru - nespravne.
    Zapouzdreni je dusledek pozadavku polymorfismu.
    Bez dedeni se v celku bez vetsich problemu obejdes - napriklad (muj oblibeny a v mnoha smerech prukopnicky :-) Self ma pouze delegovani a jen velmi tezko lze zpochybnit, ze to je OO jazyk.
    FLEGMA
    FLEGMA --- ---
    XCHAOS: Mno tvuj popis zapouzdreni je docela nepresny. Predevsim je dulezite zapouzdreni implementace (tj. metody/funkce), zapouzdreni atributu beru jako samozrejmost.

    "pokud striktně dodržíš tohle tzv. "zapouzdření" a s objektem pracuješ jen pomocí API, tak je ti úplně fuk, že jazyk nemá k dispozici dědění" Ne ! Uplne nejzakladnejsi principy OO jsou: dedeni,zapouzdreni, polymorfie a tyhle fundamenty nejsou navzajem zamenitelne. Takze nevim, jak jsi prisel na to, ze si vystacis se zapouzdrenim (a pripadne delegaci).
    KEYMASTER
    KEYMASTER --- ---
    on někdo zase používá JS jako straw man argument proti slabýmu typování?

    No musím uznat že je to osvěžující změna proti klasickýmu "přetěžování operátorů by se mělo zakázat protože ~ jde přetížit na insert_anal_probe(LPANUSW recipient, LONGLONG _IN_ probe)" ;)
    REDGUY
    REDGUY --- ---
    XCHAOS: použiju C, když pokládám za důležité přesně chápat, co můj program udělá - coz je mylna predstava a ani nemusim delat vtipy o tvejch schopnostech. V dobe L1, L2 a L3 cachi, samostatnejch cache pro instrukce a data, prefetchingu, branch predikce, hyperthreadingu, virtualizace, vyraznejch rozdilu mezi jednotlivejma generace procesoru, superoptimalizujicich prekladacu, multiprocesoru s NUMA pameti a kdovi cim jeste jen naprosty minimum programamtoru "presne chape" co jejich program dela. A pokud ti nejde o low-level performancni detaily (ktery navic skoro urcite nepotrebujes) ale o funkci, tak "presne chapat co program dela" ti umozni jakejkoliv pricetnej jazyk. A nektery ti v tom dokonce budou velmi napomocne, misto aby ti hazely klacky pod nohy tak jako C.


    XCHAOS: jako ilustrace, proč se v C pomocí + neřetězí stringy, to bylo myslím výmluvné - ne, nebylo, protoze s tim to vubec nesouvisi. Ilustruje to, ze operator plus v javascriptu ma mizernej design. Dokonce to neni ani obecna ilustrace problemu s polymorfismem, protoze takovej python pouziva '+' pro retezeni stringu taky. A co myslis, ma podobny problemy?
    XCHAOS
    XCHAOS --- ---
    UETOYO: hmm, u operací počítajících s bitovou logikou.. možná. ale jako ilustrace, proč se v C pomocí + neřetězí stringy, to bylo myslím výmluvné...
    XCHAOS
    XCHAOS --- ---
    UETOYO: ne, napsal jsem "použiju C, když pokládám za důležité přesně chápat, co můj program udělá". nic víc, nic míň.
    XCHAOS
    XCHAOS --- ---
    UETOYO: podívej, to máš asi jako debatu o systemd (BTW, je napsaný v C, BTW, sám ho už na dvou desktopech používám a BTW ... chápu vyděšenou reakci jeho odpůrců)

    tenhle klub není - kupodivu o hateování C++ (proto jsem ostatně uvedl příklad s JavaScriptem...který spíš napovídá, jak je tam vyhodnocování výrazů implementováno a jaké triky používá) - ale měl by být o tom, že si lidi programující v C budou nějak vyměňovat zkušenosti o tom, jaké programátorské styly (či možná "dialekty") C jsou ještě vzájemně srozumitelné a jaké už ne (protože i mě samotného při procházení C zdrojáků FOSS překvapilo, co všechno je vlastně občas možné napsat!). a co je případně v dnešní éře "best practice" (což nebyla ještě před pár lety, v éře epických buffer overunů různých microsoftích serverových aplikací, apod., za tak hloupá otázka... asi jsme dnes už jinde, než když tenhle klub vznikl)

    věřím, že abstrakce, kterou nabízí C++, je úžasná... na mě je ale její velká část prostě moc složitá. Sorry. možná, kdybych s tím přišel do styku už na základce, tak bych si zvykl. nevím, těžké říct...
    XCHAOS
    XCHAOS --- ---
    UETOYO: tak to nebylo myšlené. já se zabývám spíše konkrétními, ehm... alkorytmy (tím chci říct, že smyslem tohoto klubu mělo, aby spolu pražští codeři v C občas zašli na pivo, a ne nekončící trolling)
    XCHAOS
    XCHAOS --- ---
    UETOYO: asi. já tam dostal kdysi ban. tak vznikl tento klub :-)
    XCHAOS
    XCHAOS --- ---
    UETOYO: mno. pravdu máme možná oba:
    Encapsulation (object-oriented programming) - Wikipedia, the free encyclopedia
    http://en.wikipedia.org/wiki/Encapsulation_%28object-oriented_programming%29

    já mluvil o tom druhém ze dvou významů, který uvádí wiki. ale nevylučuju, že jsem ho možná špatně pochopil :-) v podstatě, že všechna data v objektu jsou "private" a máš jen metody, to je určitá extrémní forma zapouzdření.

    hele, já o tom v tomhle klubu moc flejmovat nechci. My Céčkaři sice objekty umíme, ale většinou dokážeme zdůvodnit, proč je na to či ono nepotřebujeme :-)
    XCHAOS
    XCHAOS --- ---
    REDGUY: podívej... svůj přístup ke kritice zlepšuju úměrně tomu, jak se zkvalitňuje ta kritka.

    každopádně vznik nového C++ klubu (ačkoliv je to už třetí C/C++ klub na NYXu) v zásadě vítám. už je samotná skutečnost, že všechny lukrativní nabídky jsou zásadně C/C++ a žádná jen "ANSI C", mě donutila jen jsem si nemohl odpustit předvést, že nejzdatnější trollové se shromažďují ze všech těch třech klubů právě v tomhle :-)
    REDGUY
    REDGUY --- ---
    XCHAOS: Jestli chces, abych ti automaticky kazdej minus zduvodnoval, zlepsi svuj pristup ke kritice od ostatnich. Jestli chces abych ti zduvodnil aspon tu a tam nejakej, no, co treba se zeptat? Prej je to dobrej zpusob jak se neco dozvedet, urcite lepsi nez fnukani ze "je mi to houby platné, když zdůvodnění neznám" 8)
    XCHAOS
    XCHAOS --- ---
    UETOYO: zapouzdření (pokud se v těch OOP pojmech jako převážně-ne-OO programátor dobře orientuju) je, že nikdy nepřiřazuješ hodnoty přímo "slotům" (jestli se tomu tak ještě říká, prostě "member variables" struktury či objektu), ale vždy voláš nějaké funkce, tvořící AP (výhodou pak je, že objekty se stejným API se stávají třeba i meziprocesově nebo síťově transparentními, apod.)

    příklad: místo obj->hodnota = něco pak voláš zásadně metodu setHodnota(obj, něco) - případně, v tečkové C++/JavaScript konvenci obj.setHodnota(něco)

    pokud striktně dodržíš tohle tzv. "zapouzdření" a s objektem pracuješ jen pomocí API, tak je ti úplně fuk, že jazyk nemá k dispozici dědění. a ještě můžeš klidně povídat s objektem, který sídlí v části paměti (nebo klidně i v paměti na jiném počítači), kam tvůj proces nemá přístup. nevýhodou je určitá režie navíc (compiler by snad mohl funkce, neprovádějící nic jiného,než přímé přiřazení, nějak inlineovat, ale to už spadá do kategorie esoterických optimalizací v compileru, na které se nejde spoléhat).

    pozor, netvrdím, že jsem někdy napsal nějakou objektovou knihovnu,která by něco striktně zapouzdřila!!! :-) (spíš naopak - zběsile generuju - nebo spíš než jsem zesenilněl, tak jsem generoval - tuny nezapouzdřeného kódu, je to vždycky jedna šipečka za zdruhou :-) ale nikdy nevzdám přemýšlení o tom, jak by se asi v C mělo programovat správně :-)
    XCHAOS
    XCHAOS --- ---
    REDGUY: no, to je dobré vědět, že to máš zdůvodněné... ale je mi to houby platné, když zdůvodnění neznám.

    standardní string.h (resp. libc neimplementuje) definuje jen minium opravdu bezpečných nástrojů pro práci se stringy - funkce asprintf() ( viz http://linux.die.net/man/3/asprintf ) je pro mě (po 20ti letech generování chyb v C) asi jediná, které bych dnes důvěřoval. přesto budu mít větší důvěru k nějaké funkci na konkatenaci (či formátování) stringů, kterou si sám zavolám.. a nebudu čekat, jak se narrow artificial intelligence nebo možná fuzzy logic (česky oboje: umělá demence) interpreteru rozhodne můj původní záměr, ehm... interpretovat :-)
    REDGUY
    REDGUY --- ---
    XCHAOS: To je taky nepravda. Kazdy minus, ktery jsi ode me dostal v tomhle a podobnych klubech ma fakticke zduvodneni. Pokud si myslis, ze minusu tvoje prispevky jen tak, protoze jsi XChaos, tak se mylis.
    XCHAOS
    XCHAOS --- ---
    REDGUY: chápu. tvé minusy nevyžadují žádné zdůvodnění :)
    XCHAOS
    XCHAOS --- ---
    UETOYO: tak mě to přišlo jako zajímavost. technicky vzato je tu offtopic, ale tenhle klub je tak nějak o sebeutvrzování těch, kteří C pořád používají, proč to vlastně dělají. jak podobné věci dopadnou např. v C++ když se použije nějaké pokročilé přetížení operátorů s autodetekcí, zda string náhodou nevypadá jako číslo... to si netroufám vůbec odhadovat, například.
    REDGUY
    REDGUY --- ---
    XCHAOS: Predpokladas spatne.
    XCHAOS
    XCHAOS --- ---
    předpokládám, že když mi ids REDGUY a GOSHEWAN za poznámku
    [ XCHAOS @ ANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API ]
    dali oba palec dolů, tak že se jim podobné aritmetické kejkle v dynamicky typovaných jazycích líbí? (to je určitě důležité info prokaždého, kdo by s nimi třeba na nějakém projektu někdy chtěl spolupracovat :-)
    XCHAOS
    XCHAOS --- ---
    UETOYO: jestli za jedinou formu "objektovosti" pokládáš dědičnost... JavaScript má tzv. prototyping, což je takový eufemismus pro copy+paste kódu na úrovni runtime (pokud to chápu dobře). na Ansi C objekty si nicméně sáhnout nenechám, protože tenhle přístup k objektovosti je vlastně čistší, než dědičnost (mj. je tam samozřejmostí úplné zapouzdření, protože případné objekty, ze kterých "dědíš", jsou v odvozené struktuře/objektu zahrnuté jako naprosto nezávislé entity)

    i když syntax čistého C bohužel nenabízí pro ten "druhý" objektový přístup zrovna user-friendly API, tak můj pocit je, že takový přístup je čistší (např. parent class, ze které moje třída něco zdědila, pak klidně zabírá paměť i když jí třeba nepotřebuju a potřeboval jsem zdědit jen API/metody kvůli dosažení polymorfismu - nejsem přeborník na OOP, dobrý navržená asi parent class, ze které dědím, tohle asi řeší, ale to je právě to...)

    spoustu přístupů OOP se každopádně dědění netýká (námatkou polymorfismus, konstruktory, destruktury...), v současnosti to vypadá, že "pravdu" má ten, kdo dokáže na vývoj pomocí své technologie sehnat víc peněz a vytvořit pro daný jazyk víc pracovních míst :-) takže pro ty je zde nový klub
    [ C++ (11+) ]
    ... tam určitě najdeš spřízněné duše (aha, teď koukám, že ho dokonce moderuješ :-)

    prostě si to v C++ dělejte po svém, já Vám do toho nebudu kafrat.
    Kliknutím sem můžete změnit nastavení reklam