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)

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 :-)

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ě :-)

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.

Je něco snažší napsat v low-level jazyce (kde aritmetika jsou prostě jen kupecké počty) a nebo "high level objektovém jazyce"? :-) (příklad je v JavaScriptu, který nám "usnaďnuje život" tím, že umí občas vypadat jako C... na první pohled)