• ú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
    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.
    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)
    Kliknutím sem můžete změnit nastavení reklam