DAVIDOWITCH: kontexty BTW uměj zrušit spoják, na který zahodíš pointer. od toho jsem je dělal.

jinak to co si posílal, byla implementace konzervativní garbage collection http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Precise_vs._conservative_and_internal_pointers

uvedu jako protipříklad zrovna "moje" pole, o kterých uvažuju, že by get(array,typ,počet) vrátil pointer až o kus dál, než je začátek alokované paměti - a na té počáteční pozici by byly servisní údaje (např. max. alokovaná délka, aktuální délka, apod.)

ANT_39: hmm, něco na tom je. víceméně, proto uvažuju o makru "escape", které by bylo doporučenou náhradou break, a bylo by implementované jako nastavení nějakého příznaku + continue. to by řešilo problém mísení kontextů a mých iterátorů.

pořád to ale neřeší problém mísení kontextů a smyček. jak říkám, uvést u flow-control maker jejich chování v případě break; bude nutnost, a ty pořád znovu opakuješ "ale já nechci číst žádné manuály". to je ale potom těžké... pochopitelně, nějaký klikací woknista by asi mohl být překvapen (pokud programuje)... ale prakticky u jakéhokoliv programování pod Linuxem se čte dokumentace HODNĚ... a víceméně, u každé konstrukce, kterou použiješ v jakémkoliv jazyce, se předpokládá, že do manuálu ses předtím podíval (nikdo mi nemůže zabránit, abych pro svoje makra udělal i normální manuálové stránky, např. v sekci 3 ...)

jak jsem se snažil vysvětlit: min (pro někoho) nečekané chování se může vyskytnout ve spoustě situací.. nejsem v tomhle nijak horší, než nečekané chování čehokoliv jiného.

REDGUY: to máš jako rozhodování, jestli se chceš naučit řídit moped nebo traktor :-)

Mas pravdu s tim break, ale, for the sake of argument, minimalne MSVC prelozi tohle "dobre" (ze za redefinici keywordu bych lamal prsty asi netreba zduraznovat):

#include <cstdio>

#define break printf("pycovole\n")

void main(void)
{
	break;
	return;
}

Tak zase, kdyby to bylo "pokud pouzivate moji knihovnu, musite misto break; pouzivat terminate;", tak mi to az tak moc nevadi.
Pokud ale bude tohle platit jen kdyz si v remember a ne v celym programu (tj. terminate mimo remember nefunguje jako break), tak to je pruser.

REDGUY: Toto mi konkretne prijde jako showstopper jak blazen. Ze je k dispozici krom zasobniku a mallocu nejaky mechanismus kontextu, no budiz, proc ne. Ale ty maskovany fory jsou proste pruser.

XCHAOS: Pockej, co ti prijde na Cckovym GC krajne neprakticke? Mark-sweep neni spatnej algoritmus. Neni to tak chytry jako java (kde ti to treba new ve smycce "vyhodi" pred smycku), ale narozdil od tvejch kontextu to umi treba zabit spojak na kterej ztratis pointer.

ANT_39: Presne tak. Ten samej kus kodu, co bude volat ukladani jump bufferu, bude taky volat odblokovani signalu, s tim ze se do nejaky globalni nebo thread-local promenny ulozi oldset (viz man sigprocmask).

XCHAOS: Je, samozrejme, ostatne stary linuxovy thready se implementovaly pres signaly -- tusim ze to bylo neco jako ze signal handler byl vicemene scheduler yield + context switch.

XCHAOS: Az na to, ze "jednodussi" samozrejme take neni - uz proto, ze porad musis v urcitych situacich pouzivat malloc/free. Cili i kdyby kontexty byly super jednoduche (coz nejsou), porad znamenaji pridanou slozitost nad free/malloc. Docela bizarni, v jazyce urcenem pro zacatecniky.

Btw, kdyz napisu tohle:

while (foo()) {
    blabla();
    if (bar()) {
        remember {
            allocate_memory_and_do_stuff()       
            if (baz1()) {
                break;  // chci ukoncit cyklus while
            }
            if (baz2()) {
                continue; // chci spusti dalsi iteraci while
            }
        }
    }
}

Bude to fungovat? Nebude? Co budu muset napsat aby to fungovalo? Vzhledem k tomu jaky bastl predpokladam ze ke remember mam urcitou teorii, ale rad si to poslechnu od tebe 8)

XCHAOS: Jestli se ti nezda nespecificky except kvůli Ctrl+C, tak doporučuju vyrazit směrem SyntaxError ;-)

DAVIDOWITCH: tohle už tu probehlo aspoň 2x .. princip chápu, ale pro množství paměti, které dnes může být alokováno, mi to přijde už krajně nepraktické.. nemluvě o vyswapovaných programech, apod.

REDGUY: já bych zůstal u toho "jednodušší" , do bezpečnostních debat bych se nerad pouštěl (zvlášť ne v tomhle klubu / při použití C)

víceméně, pokud runtime aspoň občas něco dealokuje, aniž by ses o to musel sám zasloužit - tak to podle mě jednodušší je.

ANT_39: Pocinaje tusim 10.5 je v OSX Objective-C s garbage collectorem, ale vzdycky jsem myslel ze GC se tyka jen Objective-C objektu. Ale na druhou stranu tomu houby rozumim protoze ObjCuju jen na iPhone a tam GC jeste neni.

DAVIDOWITCH: Ja si vlastne vybavuju ze ObjC jde kompilovat s garbage collectorem (misto toho retain/release a releasepoolu z GNUStep). Tak mozna to jde zapojit i do normanich appek...

ANT_39: No ja mam prave dojem, ze nabizi nejakou GC podporu i kompilovany aplikaci (pamatuju si to z nejakejch zprav ze tim resej firefoxi memory leaky na linuxu). Ale jistej si tim nejsem, not that kind of engineer :-)

XCHAOS: protože prostě nedokážeš vyvrátit výrok, že "v C lze snadno napsat potenciálně nebezpečný či chybný kód, který se bez varování přeloží" - ano, to nedokazu, proto se o to ani nesnazim. Na druhe strane, vyrok "XChoas se uspesne snazi navrhnout system, ktery alokaci pameti v C zjednodussi a ucini ji bezpecnejsi" lze vyvratit zcela trivialne, poukazem na jednu z mnoha chyb v designu jeho systemu.

ISTEVE: Otazka zni, jak ty signaly po longjmpu odblokujes? V tu dobu uz jsi jinde... Hmm, hadam, ze kdyz to bude maskovany v tech makrech, tak by to za tebe mohlo expandovat makro za kazdym try { a catch {.

DAVIDOWITCH: Tak tomuhle nejak nerozumim. GCC ma preci GC pri kompilaci, jak to pomuze?

http://www.hpl.hp.com/personal/Hans_Boehm/gc/
(asi najdes lepsi zdroje, ale tohle vypada jako slusnej zacatek)

DAVIDOWITCH: no tak o tomhle toho moc nevím, nahoď odkaz

Tak muzes do gcc pridat nejaky hooky, ted uz to zvlada jakous takous garbage collection, tak treba se prilipnout k tomu...