• ú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 --- ---
    DAVIDOWITCH: a co pořadí uvolňování - to by na rychlost taky mohlo mít vliv, ne ?
    tedy, kdybys měl na uvolňování druhou smyčku.

    "u mě" v mém chystaném dialektu bude zápis

    forget
    {
    repeat(100)
    {
    int *ptr=get(array,int,100);
    }
    }

    provedený skutečně jen s jedním malloc() a jedním free() ...
    XCHAOS
    XCHAOS --- ---
    REDGUY: opravdové zásluhy přiznávám těm, kdo chyby opravují...

    a ani jinak není chyba jako chyba - to, že o něčem zjistíš, že to "nejde použít tak, jak bys chtěl" nestačí, abys mohl říct, že je tam "chyba"...
    REDGUY
    REDGUY --- ---
    XCHAOS: až najdeš bug v nějakým mým releasu, tak kolem toho dělej takovej humbuk - humbuk? Ty ses ptal co jsem predvedl a ja ti odpovedel, ze jsem nasel a ukazal ti chyby v tvem kodu. Normalni clovek by za to podekoval, ne nadaval - ale opet, chapu ze to je tvuj emocialni problem se mnou 8)

    btw, pri zbeznem pohledu bych rekl, ze tvuj (ne-release) crl1 je brutalne rozbitej z hlediska mnohonasobneho vyhodnocovani argumentu maker a chybejicich zavorek kolem nej. Skoro jsem myslel ze tohle uz jsem ti pred par rokama vysvetlil, ale asi jsi to vytesnil. Chces to vysvetlit znova? 8))
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Hmm.. no, to je slozitejsi, protoze zalezi jak definujes "to same". Pokud chces aby udelaly stejny memory operace, tak mne nenapada jak to zaridit. Protoze, pokud se nepletu, tak zatimco:
    Cckovy
    for(int i=0; i<100; i++)
    { int *ptr = malloc(100*sizeof(int)); /* do stuff */; free(ptr);}
    a C++
    for(int i=0; i<100; i++)
    { int *ptr = new int[100]; /* do stuff */; delete [] ptr;}

    delaj vesmes to samy (100x naalokuje, 100x uvolni),
    tak kdyz udelas tu druhou smycku v Jave, tak to zoptimalizuje na 1 alokaci, 1 uvolneni.
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: no tak právě proto bych řeč rád stočil třeba nato, jestli existují nějaké benchmarky testující rychlost a efektivitu mechanismů alokace paměti...

    a to samozřejmě nejen pro C... ale i rozšířené vyšší jazyky. srovnávací benchmarky - u kterých by ale bylo jasně vidět, že "dělají to samé"
    XCHAOS
    XCHAOS --- ---
    REDGUY: tak víš co ? až najdeš bug v nějakým mým releasu, tak kolem toho dělej takovej humbuk. pokud kritizuješ věci v těžce vývojovým SVN, tak prostě buď spolupracuj a commituj návrh oprav - a nebo drž papulu.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Popravde, ja si myslim ze v Ccku bys to nemel chtit delat automaticky.
    Pokud neprepodkladas ciste single threaded single process kod, tak ty refcounty (a obecne jakykoliv garbage collection mechanismy) sou hodne drahy kvuli nejakejm atomicum a mutexu. A pak to chce peclive zvazit kdy a jak to presne pouzit.
    Napriklad v nejaky kriticky sekci si dovedu snadno predstavit ze, kdyz uz tam musis dynamicky alokovat, tak nechces dalsi overhead co se refcountu tyce.

    A teda predpokladam, ze pokud mas v planu delat v Ccku nejaky weboviny, tak to bude multithreaded a/nebo multiprocess, pripadne do budoucna timhle smerem rozsiritelny, kdyz uz dneska pomalu nezakopnes o single-core procesor.
    REDGUY
    REDGUY --- ---
    XCHAOS: To je mi popravde receno uplne jedno 8)
    XCHAOS
    XCHAOS --- ---
    JACHYMKO: je to pravda, taky je to jen mírný offtopic.

    podstatné jádro diskuze bylo, že v samotném C sice máme velkou volnost použít nějaký exotický alokátor paměti a různé přístupy ke garbage collection - ale žádná knihovna nám nemůže přetížit tak základní věc, jako chování pointerů.

    v C jde dělat různé krkolomné věci - viz třeba flow control makra, apod. - ale nejde tam nijak jednoduše zařídit, aby se při každé operaci přiřazení nebo na konci scope automaticky zavolal nějaký kód.
    XCHAOS
    XCHAOS --- ---
    REDGUY: našel si bugy v něčem, co jsem _releasnul_ ?
    REDGUY
    REDGUY --- ---
    XCHAOS: co si tedy tak úžasného už předvedl ty - kdyz uz nic jineho, nasel jsem par bugu v tvych programech, naucil te par novych veci a pri tom vyvratil par tvych bludu. Coz by pro zacatek mohlo stacit 8)

    z jakého titulu vlastně tenhle klub neustále zahrnuješ tak sžíravou kritikou - copak, potrebuju na to tvoje povoleni? Ja myslel ze od toho diskusni kluby jsou, aby se v nich tribily myslenky. To ze tvoje myslenky casto za moc nestoji (z ruznych duvodu) a pritahuji kritiku je jen nestastna shoda okolnosti 8)
    XCHAOS
    XCHAOS --- ---
    DAVIDWITCH, JACHYMKO: toto je všechno hezké a zajímavé, ale připomínám, že na NYXu je přece krásný lesklý plyšový klub o C++ - tak s tímto prosím (v tomto rozsahu obecně a co se týče Windows zvláště) jděte tam: tady je to určené spíše pro výměnu zkušeností lidí, co se snaží programovat v C99 a pod GNU/Linuxem.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    JACHYMKO: jo, to prefixovani bylo peklo. Ja ale narazil az primo na to Managed C++ (coz bude ono C++/CLI). Proste sem misto MFC chtel pouzit WinForms a tohle na mne baflo. :-)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Ono kdyby to C++ umelo a delalo automaticky, tak asi zacnu aktivne hledat nejakej programovaci jazyk co mi da na vyber. Libovolny takovyhle chytry mechanismy maj overhead, treba u refcountu to musi bejt threadsafe (tj. nejaky mutexy, atomicky countery) coz neni zadarmo.
    Jinak treba M$ ma vlastni rozsireni C++ standardu pro spolupraci s .NET, kde to ma dalsi 2 znaminka pro pointery (^) a reference (%, hmm.. mozna opacne) ktery jsou garbage collected. (ale jestli to pouziva prave refcounty nevim, ony jsou fakt dost neefektivni, jakmile mas k dispozici prekladac).
    XCHAOS
    XCHAOS --- ---
    REDGUY: no já na tom pracuju, dej mi rok - dva ... :-)

    spíš by mě zajímalo, co si tedy tak úžasného už předvedl ty a z jakého titulu vlastně tenhle klub neustále zahrnuješ tak sžíravou kritikou...
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: jinak ano... běžná interpretace přísudku "umí" ve spojení s podmětem "programovací jazyk" je v hovorové češtině chápána jako "umí to automaticky". ano, došlo tu k politováníhodnému nedorozumění - ale mě neskutečně irituje snaha tohle nedorozumění okamžitě interpretovat tak, že jedna z diskutujících stran je úplně blbá a vůbec neví co říká.

    co je zajímavá a co z toho naopak nečekaně vyplynulo, je že ani samotné C++ v sobě nemá tento mechanismus vestavěný, a potřebuje na to jakési rozšiřující knihovny. takže zajímavé není, že "C to umí, pokud se to udělá ručně", ale že "C++ to samo od sebe neumí automaticky"

    (popravdě - mám určité tušení, že minimálně někteří aktivní účastníci téhle diskuze ve skutečnosti nenaprogramovali/nepřeložili ani řádek v céčku pod linuxem - ale taky neztrácím čas tím, že bych to nějak donekonečna opakoval a zdůrazňoval...)
    XCHAOS
    XCHAOS --- ---
    The XML C parser and toolkit of Gnome
    http://xmlsoft.org/
    XCHAOS
    XCHAOS --- ---
    libcurl - the multiprotocol file transfer library
    http://curl.haxx.se/libcurl/
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: no... asi dělání webu jak v čem :-) existující nástroje/knihovny použitelné přímo na úrovni C (námatkou FastCGI, knihovna pro práci s CGI query stringy a POSTy formulářů ... ale třeba i curl, parsery XML) by tady určitě ontopic byly.

    ono se to málo ví - ale spousta webové funkčnosti ve "vyšších jazycích" jsou jen wrappery pro systémové knihovny, které lze použít i přímo z C - interpretr "vyššího jazyka" často neudělá většinou nic nedělá nic jiného, než že přijde s nějakým bindingem na knihovnu napsanou v Céčku.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Ono je ontopic delani webu? To mne mates, to tam nemas napsany ani naznakem.

    XCHAOS: njn, kdyz mne proste prijde rozdil mezi "Ccko neumi refcounty", a "Ccko neumi pocitat reference automaticky, a tak to je pro single threaded single process aplikace nanic pro spravu automatickou spravu pameti, pokud nemas podporu v prekladaci ala gcc" vetsi nez 10-20%.
    Kliknutím sem můžete změnit nastavení reklam