• úvod
  • témata
  • události
  • tržiště
  • Přišli jste skrz odkaz na příspěvek, který již neexistuje.

  • 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
    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.
    WILD_A
    WILD_A --- ---
    XCHAOS: No javascript umi obcas pekne zamotat hlavu ... zase ale malokdy se v javascriptu dela number-crunching nebo sofistikovany pocitani differencialnich rovnic
    XCHAOS
    XCHAOS --- ---
    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)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: jj, nactes buffer, prohodis buffer.. u tech utf8/16 musis poresit kdyz budes mit na konci bufferu jen pulku znaku.
    Ale nechces mmapnout a jit odpredu-odzadu, protoze se v tom souboru useekujes xmrti.
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: no, myslím to lze číst pořád od konce... nevím jak utf-16 ale utf-8 je snad dělané tak, že poznám, jestli sem přečetl začátek nebo ten doplňkový fragment (?), základ je vzít poslední dvouznak a rozhodnout se, jestli je to x+1 nebo 1 znak? prostě revertovat po bufferech načítaných z disku a vždy se rozhodovat, jestli mi něco zbývá.. voser, ale oddebugovatelný (jako ale napsat to z jedný vody načisto bez debuggingu bych si fakt netroufal :-)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Jop, posral sem to.

    Kazdopadne, ten out-of-core je zajimavej. Kor kdyz clovek zjisti ze ani 128GB pameti neni dost :-D
    Kliknutím sem můžete změnit nastavení reklam