XCHAOS: a další debata o tom "pro koho a proč" je podle mě v tomhle klubu offtopic. - obavam se ze jsi nepochopil proc ty otazky kladu. Jejich smyslem neni zjistit "jestli" to delat, ale "jak" to delat. Pokud si ani tohle neujasnis, narazis po ceste na velke problemy. Ostatne, uz jenom z te jedne zpravy je videt krapet problem: na jedne strane chces univerzalni alokator pro vsechny svoje aplikace, na druhe strane chces "pruzkum technik, bez debat proc by to nekdo chtel delat". Zakladni vyzkum a aplikovany vyzkum jsou dve ruzne veci a delat oboje soucasne mi prijde jako docela spatny napad. Jestli chces nahradu mallocu, mel bys bejt schopnej aspon rict co konkretne je na mallocu spatne. Ne proto ze te s tim otravuje nekdo na nyxu, ale proto abys nakonec poznal jestli se ti to podarilo nebo ne. Jestli chces zkoumat techniky, je dobre zacit tim podivat se jak to delaji ostatni. Co si kuprikladu myslis o tom, jak funguje alokace pameti v ObjC? 8))

XCHAOS: Jestli ti nevadi zaviset na GNU rozsirenich, tak asprintf je jako sprintf, ale buffer si alokuje sam na halde, a pak do nej retezec nakopiruje. Konkatenace by pak byla proste asprintf(&buf, "%s%s%s%s", str1, str2, str3, str4);

REDGUY: připomínky jsou to dobré. odpovím ti stručně (přeci jen je neděle) na tvoje první dvě otázky:

- alokátor má být určen především pro mě (a dále pro lidi, co se mnou budou chtít spolupracovat)
- alokátor bude použit ve všech příštích userspace aplikacích, které plánuji v C vyvíjet

je to podle mě dostačující vysvětlení, které má právo uvést kdokoliv u všech svých dalších dotazů na jakouliv feature jazyka C, kterou v tomhle klubu vznese. Doufám, že je to nyní jasné - a další debata o tom "pro koho a proč" je podle mě v tomhle klubu offtopic. budeme se zde bavit o naprosté jakékoliv (jakkoliv technicky nesmyslné) feature jazyka C - včetně hledání všemožných bezpečnostních děr typu buffer overrun a stack insertion i debat, jak jim zamezit - a nebudeme se prosím bavit proč by toto někdo chtěl zneužít nebo se proti tomu bránit.

prostě mě zajímá průzkum co nejširší možné množiny programátorských technik, které se týkají čistého jazyka C (a to konkrétně na úrovni předposlední specifikace C99, která mi vyhovuje více, než předchozí norma C89, na které jsem vyrůstal) - a nebudeme ztrácet čas debatami, kdo a proč by mohl chtít něco takového dělat (případná snaha o účast v "C obfuscated code contest" je dostatečný argument, kterým lze argumentovat na zcela jakoukoliv námitku)

ANT_39: ano, tak já už nějaký čas vím, že bych takto měl se stringy pracovat. moje starší programy to ale obchází, a trapně používají buď MAXLEN buffery na stacku (a nebo MAXLEN alokují). právě že směřuji k tomu, že moje novější C aplikace budou používat vlastní mini-knihovnu se základní funkcí na řetězení a současnou alokaci stringů a jejich následnou efektivní masivní dealokaci (obdoba operátoru + v Pythonu či JavaScriptu nebo operátoru . v PHP)

A hle, stejne jako Zombie Jesus, po trech dnech vstavam z banu a jsem zpet 8)

Nejdriv troska offtopic, coz?
XCHAOS: moderátor občas musí holt poněkud offtopic komentovat počíná ostatních Coz by bylo dobre zduvodneni, kdyby ty tvoje off-topic prispevky byly skutecne moderovani, a nikoliv mentalni masturbace nad vlastni kreativitou, nesmyslne obvinovani oponenta z chybne argumentace, podsouvani oponentovi neceho, co nikdy nerekl nebo blaboleni o smyslu zivota Kdybys skutecne jen moderoval, tak ano, mas pravdu. Coz jsi ovsem nedelal. A pokud off-topicujes uplne stejne jako ja, tak kdyz potom vytahnes moderatoske kladivo, je to proste jen zbabelost (a rekneme "neuprimnost", pokud to vydavas za moderovani). Jen tak do zaznamu 8)

No, ted ale neco k veci, coz?

Zakladni vec ktera v cele tehle dbate chybi, je kdyz uz ne analyza, tak aspon zduvodneni:

- Pro koho ma byt xallokator urcen?
- Pro co je to urceno?
- Ma to byt nahrada nebo doplnek stavajicich zpusobu alokace pameti?
- V cem jsou soucasne zpusoby alokace pameti nedostacne a proc?
- V cem (a jak moc) chces byt lepsi?
- Jak dobre to ma fungovat s jinejma knihovnama?
- Jak to celkove koncepcne zapadne do celeho jazyka?

Chapu ze kdyz si takhle aspon trochu nadefinujeme co vlastne delame, tak se pozdeji bude mnohem hur vyhybat pripadnym namitkam pomoci ukroku stranou, ale toho uz jsme si driv uzili dost, ne?


XCHAOS: "tradiční" stringovou gymnastiku v C (ta je prováděna na stacku, tradičně vázaná na nějaké to "MAXLEN" - ne, neni. Ze to tak delas ty neznamena, ze to je obecna tradice.

A btw, dival ses jak funguje alokace pameti v Objective C, jak uz jsem ti nekolikrat doporucoval? Docela by me to zajimalo - kdyz mi vycitas off-topic prispevky, rad bych vedel jaky efekt maji ty on-topic 8)

XCHAOS: Ano, co ti chodi zvenku. Uvnitr programu si to zmeris. MAXLEN nepotrebujes.

ANT_39: tak já to chystám přesně jak říkáš - už mám hotovou funkci get_str(), která změří délku všech svých (1 ... n) argumentů, alokuje prostor a nakopíruje do něj obsah stringu (a toto jsem měl mít už dávno a měla by to být podle mě v C norma).

zdrojem řetězců náhodné délky je vše: stringy přicházející z textových konfiguráků, z databáze, z webových formulářů... string známé délky je naprosto speciální případ a mimo chráněný svět zdrojového kódu programů a počítačových her se prakticky nevyskytuje.

Prosím o pomoc, dokázal by někdo z vás zkompilovat toto pod Windows? https://github.com/spekode/sskey, zkoušel jsem CygWin, MinGW, ale nedaří se mi :(

ISTEVE: tak typicky delší životnost než funkce, ve které vznikají, mají "moje" spojové seznamy (viz předchozí flamewar - ale i navzdory argumentům, které zde padly, je to stále moje oblíbená datová struktura...).

typickým příkladem dočasné alokace jsou pak různé operace na bázi immutable stringů (ve stylu Pythonu), které pokládám za bezpečnější, než "tradiční" stringovou gymnastiku v C (ta je prováděna na stacku, tradičně vázaná na nějaké to "MAXLEN" se kterým je alokován každý string)

DAVIDOWITCH: ...pokud nebude funkce brat ownership toho co je ji predano jako argument, treba proto ze ocekava delsi zivotnost tech dat nez caller (ala multithreadovy aplikace)...

...a to s alloca (jak rika janfrog) nemuze vubec, coz je ponekud vetsi omezeni;]

XCHAOS: Tak s mallocem tohle stejne udelat nesmis, protoze si zahodil pointer a nezvladas free, zeano...

DAVIDOWITCH: no tak mě v podstatě ne... ale právě třeba moje makro-zápisy často vedly přesně k něčemu podobnému a byl jsem tady za to dost kritizován...

XCHAOS: Sorry, ale to ze musim udelat:
int *foo = alloca(5*sizeof(int));
bar(foo);

misto

bar(alloca(5*sizeof(int)));

Mi az tak omezujici neprijde. Ale pochopitelne, ymmv

DAVIDOWITCH: jo. já teda používám -std=c99 takže mě asi něco z toho trápit nebude... ale spíš mě jde o to "On many systems alloca() cannot be used inside the list of arguments of a function call, because the stack space reserved by alloca() would appear on the stack in the middle of the space for the function arguments. " - to mě přijde jednak logické, jednak jako vážné omezení.

kdybych věděl, jak zjistit kolik mi zbývá místa na stacku, tak můžu zavolat set_rlimit() pokaždé, když by další alokace to místo spotřebovala :-) ale co jsem tam googlil, tak zjistit tohle vůbec není triviální.

můj závěr je, že pro svojí službu bleskové dealokace celého poolu paměti současně nebudu používat alloca() (ani kdyby to náhodou v gcc fungovalo jak očekávám) - i když to automatické uvolnění po návratu z jakékoliv funkce je samozřejmě lákavé.

XCHAOS: http://linux.die.net/man/3/alloca
Myslis to varovani tady?

HARVIE: o to nejde, jestli je to do nekonečna... malloc() má k dispozici v podstatě veškerou momentálně zbývající RAM + velikost swapu k tomu + ještě vypudíš z RAM diskovou cache, než to začne swapovat. velikost stacku je naproti tomu nastavená fixně (a výchozí velikost je zjevně 0.5 MB).

XCHAOS: Mno... Ani mallocovat se neda do nekonecna zejo...

JANFROG: mě v podstatě jde jen o to napsat si nějaký co nejjednodušší memory pool, u kterého budu plně rozumět tomu, jak funguje - a bude schopen jednoduše hromadně uvolňovat větší množství paměti (i bez použití garbage collection).

že to nemusí fungovat mimo scope, ve kterém alokuju, to mě nevadí - to je u mě spíš feature, ne bug, konec funkce či scope je pro mě vhodné místo, kde masivně dealokovat (pokud se s tím od začátku počítá) (ostatně garbage collection pomocí reference counteru by taky dealokovala typicky v místě, kde zanikne poslední reference na objekt, což je v řadě případů to samé místo)

DAVIDOWITCH: no man alloca před tím varuje, tak nevím... podle téhle manuálové stránky se takto alokovaná paměť překrývá ze začátkem stacku z hlediska té volané funkce.