• ú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
    XCHAOS
    XCHAOS --- ---
    UETOYO: tak se vrať k sobě do klubu, a čekej, až se ti někdo lapí do tvých objektových sítí :-)
    XCHAOS
    XCHAOS --- ---
    REDGUY: tak s tím paralelismem vyjímečně souhlasím - že je - nejen v C - potřeba udělat něco, aby thready šlo používat jednodušej (co takhle třeba jen "iterace bez udání pořadí" - tu je možné paralelizovat podle počtu jader, kdyby na to byla jedna instrukce, usnadnilo by to spoustu práce)

    jinak co potřebujem a co ne, to je trochu tvůj "plural majesticus". zaměstnanec korporace má asi jinou představu, co potřebuje, než vývojář na volné noze nebo dokonce amatér. jediný nástroj nebude nikdy vhodný pro všechny. aby mohl někdo používat hotovou abstrakci, musí jí někdo jiný naprogramovat. proč je interpreter Pythonu pořád napsaný v C a ne v C++? apod...

    C je celkem dobrý nástroj k pochopení, jak některé věci fungují - je to kladivo, a lze na něm okoukat, jak zatloukat hřebík. není to parního buchar uvnitř nějaké ochranné klece, do které dáš věc do které chceš zatlouct hřebík, a ona ti z toho vypadne ve většině případů se zatlučeným hřebíkem a v jednom případě ze sta s ohnutým nezatlučeným hřebíkem, takže musíš zavést výstupního kontrolora kvality a zohlednit to v kalkulaci nákladů a vůbec dělat všechny ty věci, které korporace milují, protože je to to, v čem jsou vážně dobré: celý blackbox parního bucharu můžeš spolehlivě používat celá desetiletí, aniž by si chápal, jak funguje, a můžeš vykřikovat, že potřebuješ víc podavačů hřebíků co to rovnají na běžící pás a víc kontrolorů kvality a víc lidí, co umí prodat zatlučený hřebík - a přitom nikdo v celém tom cyklu nemusí mít ponětí, jak se zatloukají hřebíky, protože parní buchar dodává jiná korporace (teda pokud nestihne zkrachovat dřív, než se buchar rozbije)

    to je všechno pěkné, ale někteří lidi se prostě chtějí naučit dobře zatloukat hřebíky a nepraštit se u toho přes prsty. pro tyhle je tenhle klub, a ty sám přiznáváš, že pro tebe ní, tak proč sakra celá ta debata s tebou? (já třeba dostal v konferenci Marxismus na NYXu ban hned, když jsem tam napsal, že mám celkem rád Karla Poppera... proč ty nedostaneš ban tady?)
    XCHAOS
    XCHAOS --- ---
    REDGUY: jasně, všechno je "strawman fallacy"... (aspoň v posledních 10 příspěvcích od tebe). faktem je, že ty se účastníš debatního klubu o C s tím, že chceš dokázat, že to je okrajová záležitost. moderátor klubu se domnívá, že to až tak okrajová záležitost není (min. objem legacy free/open source software napsaný v C je jedním slovem obrovský)... a že např. pokud by se C učili středně pokročilí programátoři, kdyby přitom byli seznámeni s nějakou sadou "best practices" jak se nestřelit do nohy (která se jim neztratí mimochodem ani u těch embded minisystémů), tak by to nemuselo mít špatné výsledky.

    naproti tomu, snažit se programátory vést k C++ znamená podle mě vést je směrem, kdy se smíří s používáním abstrakcí, které nechápou, jak fungují uvnitř. a navzdory rozšířené propagandě, objektový model není obrazem fungování světa, ale obrazem fungování hierarchických struktur uvnitř lidské společnosti (což diskutabilně... může být užitečné k tomu najít si dobře placené zaměstnaní, uznávám). Stůl nedědí vlastnosti objektu "noha od nábytku" a stůl a židli není vhodné navrhnout jako extenzi objektu noha, aby mohly stát na podlaze - fakticky, objekty v reálném světě jsou smontované ze součástí, mezi kterými není hierarchický vztah. Tzn. i softwarové objekty nakonec budou smontované či poslepované z objektů, které budou zahrnovat vlastnosti jiných objektů, ale ne děděním. To určitě neznamená, že se vše bude psát v čistém C, ale min. to znamená, že má smysl zajímat se i o jiné abstrakce, než nabízí dnešní OOP.
    REDGUY
    REDGUY --- ---
    XCHAOS: tak bychom ze stávajících technologií vymáčkli daleko víc. - jenomze to vubec nepotrebujeme. Vykon soucasnych pocitacu je takovy, ze nejaky "vymackavani vykonu" je zcela sekundarni, ne-li tercialni zalezitost ve srovnani s otazku jak dobre, rychle a spolehlive psat udrzovatelny a kvalitni kod. Nemluve o tom, ze v dobe kdy se rust rychlosti procesoru zastavil a vykonost ziskavame pridavanim extra jader je C, se svoji absenci podpory paralelismu, dost handikapovane i co se toho "vymackavani vykonu" tyce.
    REDGUY
    REDGUY --- ---
    XCHAOS: takže poslední aplikace, kterou podle tebe má smysl napsat v C, je databázový engine, a když nevím, kolik toho přesně bude, tak to mám rovnou vždycky naskriptovat s použitím databáze - ne, to je samozrejme strawman fallacy. C ma svoje misto (kolikrat to budu opakovat?), ale je velmi male: jadro OS. Malinke embedded systemy. Situace s extremnimi naroky na vykon. A tak dale. Ale treba uz ten db engine to byt nemusi. Pro vsechno ostatni muzu pouzit jine nastroje a budu na tom lip nez s Ceckem.
    REDGUY
    REDGUY --- ---
    XCHAOS: lidem dělá dobře představa, že vesmír je deterministický [...] programování prostě nejde vytrhnout z historického kontextu - WHAT. THE. FUCK? Takze protoze (podle tebe) lidem dela dobre "predstava determinismu", je dobre mit iluzi o tom, ze v C mam vsechno pod plnou kontrolou? Je dobre ignorovat vsechny ty veci, o kterejch jsem mluvil, diky kterejm nad low-level vecma vlastne zadnou kontrolu nemam? Opravdu rikas, ze mit technicky spatnou predstavu o tom, jak pocitace fungujou, je vlastne dobre, protoze nejaky filosoficky kecy?
    XCHAOS
    XCHAOS --- ---
    jak příznačné, že dokument:
    Recommended C Style and Coding Standards
    https://www.doc.ic.ac.uk/lab/cplus/cstyle.html
    neobsahuje ani slovo o tom, jak by se mělo v C optimálně zacházet se stringy :-) (BTW, ani netuším, jestli libc v současné verzi obsahuje třeba funkci, která by textový soubor načetla do pole stringů, které alokuje on-fly.. a zase když jsou tam regexpy, tak proč by tam nemělo být tohle? :-)

    spíš mi jde o teoretickou úvahu, jak by mohlo C bývalo vypadat, kdyby nikoho v první řadě nenapadlo, že funkce strcpy()/strcat() jsou dobrý nápad :)

    REDGUY: viz výše: lidem dělá dobře představa, že vesmír je deterministický. protože opakovaně zjišťují, že ten skutečný není, tak aspoň vymysleli počítače. vem to tak, že pokud se ukázalo, že vědecký pozitivismus 19.století byl slepá ulička a 20.století se vydalo úplně jiným směrem (viz Feynmanovy antičástice cestující v čase opačným směrem než částice apod.), tak se programování počítačů stalo jakousi náhražkovou aktivitou. je to asi podobný posun, jako že ve středověku by správný křesťan vyrazil s plechovým kýblem na hlavě dobývat Svatou zemi, zatímco v baroku by tak maximálně chodil poslouchat od kostela varhany a jen sem tam by někoho upálil (nebo daleko spíš už jen oběsil) kvůli obvinění z čarodějnictví (a stejně by to nedělal už ani moc s přesvědčení, ale spíš jen kvůli vyvlastnění majetku)

    programování prostě nejde vytrhnout z historického kontextu.

    a teď bychom se mohli vrátit k těm stringům - snažím se celý léta pochopit, co vlastně svým trollováním chceš říct - takže poslední aplikace, kterou podle tebe má smysl napsat v C, je databázový engine, a když nevím, kolik toho přesně bude, tak to mám rovnou vždycky naskriptovat s použitím databáze?

    můj pocit z programování od jistého okamžiku je, že kdybychom měli dobré low-level algoritmy na nevím, kolik toho přesně bude, ale jinak celkem primitivní datové struktury, tak bychom ze stávajících technologií vymáčkli daleko víc. ale protože primitivní algoritmy se nejlépe staví nad vím, kolik toho přesně bude datovými typy, tak existují už několik desetiletí značné snahy připodobnit civilizaci počítačové hře, kde panáček chodí po jasně vymezené hrací ploše 80x25 znaků (nebo u ZX Spectra 32x24, dobře :-), aby se to dobře programovalo :-)

    Co nelze upřít C++ je, že na rozdíl od různých akademických a experimentálních jazyků má business model: když se smíříš s tím, že stringy (nebo cokoliv jiného) jsou abstrakce a může ti být jedno, jak jsou naprogramované, tak máš větší šanci se někde zaměstnat a být placený od hodiny za vývoj nějaké aplikace podle nějakých specifikací. to je super.. ale vždycky existuje určitý typ lidí, kteří se v tom prostě budou vrtat (ať už půjde o to sami si opravovat auto nebo sletovat zesilovač.. vrtat se uvnitř nějaké ready-made abstrakce, kterou ostatní berou jako hotové spotřební zboží, je prostě jiný typ podobné úchylky... a souhlasím, že to může být nebezpečné, stejně jako když si člověk u auta sám zkusí opravit brzdy :-)
    REDGUY
    REDGUY --- ---
    XCHAOS: No tak jestli se chces bavit o "iluzich"... 8)))

    A to ze nejaka konstrukce je "primitivni" podle tebe znamena, ze je prakticky uzitecna? A i pokud chces uvazovat "teoreticky", mas tady lepsi nastroje.
    XCHAOS
    XCHAOS --- ---
    JS C Compiler - A C compiler written in client side javascript
    https://www.youtube.com/watch?v=fzHvFn-46NM

    XCHAOS
    XCHAOS --- ---
    REDGUY: dobře - i když jsme si vyjasnili, že "naprostá většina programátorů dnes už nechápe, co jejich program přesně dělá", tak pořád existuje část programátorů, kterým dělá dobře iluze deterministického prostředí a tu jim jazyk C poskytuje.

    kromě toho, některé "objekty v paměti", typu null-terminated stringy, jsou natolik základní či primitivní konstrukce, že prakticky každá civilizace je objeví krátce poté, co se naučí vykopat díru, do které spade mamut (či napsat román o životě v pravěku) a někdy krátce předtím, než přistane na Munu. tzn. prostě se vyplatí uvažovat o jazyce, který s tím pracuje, i kdyby to byl čistě teoretický konstrukt, jehož simulace zabere kvantovým umělým inteligencím spoustu bolení hlavy (možná i právě proto :-)
    REDGUY
    REDGUY --- ---
    XCHAOS: jak by se vlastně mělo v 21.století programovat v čistém C - ona hlavne otazka je, _proc_ by se v 21. stoleti vubec melo programovat v cistem C. Samozrejme, existuji situace kdy je to zcela na miste. Je jich ale zcela minimum a v naprosty vetsine pripadu existujou nastroje, s kterejma stejnou praci udelas kvalitnejc a za kratsi dobu.
    REDGUY
    REDGUY --- ---
    XCHAOS: To neni odpoved na moji otazku. A druhej odstavec uz je uplny dada.
    XCHAOS
    XCHAOS --- ---
    jinak já se občas (některému, když pochopím, že jsem součástí cílové skupiny) vtipy zasměju. pokud někdo ze vtipu "vyvozuje závěry", tak je to, obávám se, součást problému, nikoliv součást řešení.

    nicméně, to, že se jste ochotný hádat skoro o cokoliv, jen ne o to, jak by se vlastně mělo v 21.století programovat v čistém C (a ne C++), to v podstatě o téhle debatě vypovídá hodně (v podstatě jakýkoliv C kód, který když by řídil vaší raketu/kosmickou loď, tak jste ochotní si do toho pak sami sednout, je asi napsaný dobře)
    XCHAOS
    XCHAOS --- ---
    REDGUY: no tak operátorů (v původním smyslu, tzn. podle mě typicky operace s registry či pamětí, nevyžadující alokaci další paměti pro výsledek) si lze představit spoustu. Např. kultovní jazyk http://en.wikipedia.org/wiki/INTERCAL měl operátor interleave/mingle který vypadá jako vtip, ale jeden z ruských počítačů dané éry prý tento (nebo téměř podobný) operátor měl.

    opravdu nevím, co můžeme čekat od CPU, která bude navrhovat generace smartphone hipsterů (nebo jejich umělých inteligencí, které si vytisknou na 3D tiskárnách). jsem pro jistotu připravený na všechno.
    FLEGMA
    FLEGMA --- ---
    JANFROG: Pokud ten jazyk nema nic jako atributy/fieldy, tak se nic nedeje, stale jde o ten samy princip, totiz pokusy o zapouzdreni byly i mimo OOP - napr. moduly v proceduralnich jazycich atd. Ale zas argumentovat nejakym ciste akademickym, byt historicky dulezitym (vyvoj JIT) jazykem pro psani hricek nekde v kavarne... hmm....
    FLEGMA
    FLEGMA --- ---
    JANFROG: Mas pravdu, ale ne kazdy je takovy polyglot jako ty :-) Kolik jazyku znas, tolikrat ... (vice stravenych noci u PC :-) Ano, je to jiny mechanismus, vsak jsem to psal. A prijde mi to jako docela nebezpecny mechanismus tohle dynamicke prototypovani na prvni pohled...
    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í)
    Kliknutím sem můžete změnit nastavení reklam