• ú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
    JANFROG
    JANFROG --- ---
    FLEGMA: :-) Je uzitecne se povznest na Javu. S tim zapouzdrenim je to slozite. Co kdyz ten jazyk nema nic jako atributy (fieldy) a metody? :-)
    A s tou dedicnosti mi to prijde stejne jako s celerem (celery root) a celerem (celery sticks) - oboji je to celer, akorat to spolu nema skoro nic spolecneho :-)
    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...
    REDGUY
    REDGUY --- ---
    XCHAOS: dobře [bla bla bla] apod. - a jako obvykle, reagujes na neco co jsem vubec nerekl - a navic dost nesmyslne. "assembler je spatny"? WTF? "mapuje instrukci jazyka"? WTF? Co je prosim "instrukce" jazyka C? "Filosofie C je spatna na platforme s novymy operatory"? WTF?

    tady je z toho celodenní debata. protoze z toho v podstate vtipu vyvozujes nesmyslny zavery. A kdyz ti nekdo rekne, ze je to nesmysl, tak zacnes mluvit o nejakym bizarnich irelevantnostech.
    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í :)
    Kliknutím sem můžete změnit nastavení reklam