A nebo ještě jinak.

Zvídavě děti se ptají "a jak funguje magnet ?".

Správná odpověď je, že ve skutečnosti nefunguje o nic více záhadně, než cokoliv ostatního v realitě, ve které dítě vyrůstá - jejíž podstata je a celý život zůstane záhadná, a lidé kteří se naučí na to zapomínat, se o hodně připraví. Správná odpověď možná zní, že dítě se na to ptá proto, že je to příklad jevu, který je v rozporu s kognitivní intuicí, která se formovala už od narození - dávno před tím, než se dítě naučilo mluvit a zeptat se. Jenže této odpovědi by dítě nerozumělo.

Oficiální odpověď je "kolem magnetu se rozprostírá neviditelné magnetické pole - jeho siločáry uvidíme, když dáme magnet pod papír s železnými pilinami". Hle, už to není neviditelné, už je k tomu jakési vizuální API - záhada vyřešena. A navíc: kromě záhady permanentního magnetu existuje ještě záhada elektromagnetu - tím pádem co se vyskytuje "více způsoby", to už není záhada, to je všední, lze s tím počítat, spolehnout se na to, apod. Časem přibude matematika, která jev přesně popíše. Z dětí, které uspokojí takováhle odpověď, se stávají objektoví programátoři.

Ovšem z dětí, které se zeptají "dobře, ale jak funguje to magnetické pole ?" vyrostou programátoři v Céčku.

a tedy... rozhodně zde nejsou offtopic meditace na téma "jak naprogramovat intepreter funkcionálního jazyka v C" nebo "jak napsat precompiler, který ze zdrojáku s funkcionální syntaxí vygeneruje přeložitelný C zdroják".

Python zde je víceméně offtopic - pokud se nebavíme o vnitřnostech /usr/bin/python, což je interpreter naprogramovaný mimochodem v čistém Céčku, ne v C++. zajímavé je třeba pozorovat, jak jsou implementované nativní datové struktury Pythonu, apod.

JavaScript jsem tady zmiňoval spíš z recese - to, že má příbuznou syntaxi, to tu opravdu nehraje roli - to spíš C++kaři nebo Dčkaři by se měli zamýšlet, jak se přiblížit objektové syntaxi Javascriptu - ale co by stálo za to, by bylo bavit se o tom, jak budou vypadat datové struktury Javascriptu v paměti.

Začínáme si trochu rozumět ?

_BENNY: pokud přijdeš na to, jak funkcionálně programovat v ANSI C99 tak jistě ne :-)

(podle mě by samozřejmě klíčem mohlo být předávat funkci nějaký handler na jinou funkci... vlastně by mohla být zajímavá hra předvést, že to jde...)

[ jQuery - the 'write less, do more' javascript library ]
.. dobře, javascripty obecně a JQuery zvláště přesunem sem, ok ? oni si tam s tím už nějak poradí :-)

XCHAOS: funkcionalni jazyky zde nejsou OT?

[ Programovani v C#, F# a dalsich jazycich pro .NET, Mono a ostatni CLI implementace ]
...zajímalo by mě, jestli to F# je spíš síťová verze Forthu, nebo Fortranu :-)

Dobře, tak tenhle klub teda uzavřu, s tím, že se všichni naučíme programovat v Javascriptu... je někdo proti ? :-)

Mala douska k tomu ze "javascript na serveru neni". Dostanu ban za offtopic?
JavaScript conquers the server | Application Development - InfoWorld
http://www.infoworld.com/d/application-development/javascript-conquers-the-server-969

já s tím realloc() plánuji cosi zcela pekelného... ale nejdřív musím pochopit, jak funguje ten fine-tuning u mallocu (viz man mallopt)

XCHAOS: Pockej, jak se chova realloc dnes je uz nejakejch 20-30 let stejny. Zvetsi ten flak pameti a vrati pointer na zacatek zvetseneho flaku, nebo NULL pokud selhal.

Pokud chces vedet vic, tak z definice chces vedet jak se to chova vevnitr. A to uz je implementation specific a glibc se ti bude na x86 chovat jinak nez na Sparcu a jinak nez na PICech a jinak nez na MicroBlazu a jinak nez na ARMu. (Ne nezbytne jinak, ale rozhodne ne spolehlive stejne).

REDGUY: teď popravdě ani nechápu, jestli polemizuješ se mnou nebo s někým jiným. to není můj nápad, to s tím přehazováním pořadí stránek.

v DOSu ani žádné dělení na userspace a kernel nebylo, a jak to bylo s možnostma řazení bloků paměti v reálném módu, to si fakt nejsem jistý a ani už dnes po tom nechci pátrat

mě každopádně zajímá zjistit, jak se to přesně chová dnes (ani ne nutně, jak je to udělané vevnitř). a nějaké indicie mám viz [ XCHAOS @ ANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API ]

ANT_39: No fakt. Sice to funguje az od dostatecny velikosti, ale je to tak. Jdu snist svuj kloboucke. (Chahahaha, zadnej nemam 8) )

REDGUY: no pravděpodobně jí měl jak říká [ DAVIDOWITCH @ ANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API ] - skrze kopírování paměti jinam. tedy alespoň v reálném módu. zase tý kopírovaný paměti nemohlo být ani tolik :-)

jsem přesvědčený, že programy vyvíjené pro win32 nebo pro DOS extendér DOS4GW měly už v půlce 90tých let k dispozici v podstatě stejné možnosti, jako dnes. Ale Borland C byl nižší level. určitě to měli implementované divně.

XCHAOS: Ne, nemuzes se spolehnout na to jak to bude implementovany na konkretni architekture. Jediny na co se muzes spolehnout je, ze to bude na venek delat co pisou ze to bude delat. A ze pokud nejakej kokot napsal dementni implementaci, tak mu nejspis nekdo urval hlavu a uz davno to prepsal efektivne. Ale realloc funguje i na procesorech co proste nemaj virtualni pamet, tam se tezko neco precisluje. (A taky ma potize na 32b OS, kdyz chces velky flaky pameti a mas moc fragmentovanou pamet, a tak vubec)

...These functions allow glibc-specific interaction with the dynamic memory allocation routines.

malloc_stats()

vida. myslím, že právě kvůli podobné sw-archeologii jsem tenhle klub zakládal.

REDGUY:
ANT_39: přesně pochopit, co malloc() - resp. jeho typické dnešní implementace pro typické dnešní architektury dělá - by mi určitě pomohlo "nejít proti srsti". že z větších bloků ukusuje "po částech", to jsem tušil... a právě proto bych předpokládal, že když udělám realloc() z 3prvkového pole třena na 300 000, tak dojde spíš k fyzickému kopírování ?

Normally, malloc() allocates memory from the heap, and adjusts the size of the heap as required, using sbrk(2). When allocating blocks of memory larger than MMAP_THRESHOLD bytes, the glibc malloc() implementation allocates the memory as a private anonymous mapping using mmap(2). MMAP_THRESHOLD is 128 kB by default, but is adjustable using mallopt(3).

vida vida... RTFM... konečně se někam posouváme :-)

XCHAOS: LOL. No, vzhledem k tomu ze jsi nedokazal ze sebe vysypat aspon vzdalene pouzitelnou definici jak by to melo fungovat a k cemu presne by to bylo uzitecne, je to v podstate irelevantni 8)

XCHAOS: U malych pametovych bloku asi tezko, protoze ty se nemapuji separatne. man malloc o tom ma nejake relevantni povidani.

REDGUY: Co ma locale spolecneho s tim, jak presne funguje podobnost objekty ruznych typu?

Hodně.

XCHAOS: co se mé hypotetické funkce týče, tak já bych jí viděl právě třeba jako rozšíření POSIXu - které by se řídilo třeba aktuálním locale. - wtf? Co ma locale spolecneho s tim, jak presne funguje podobnost objekty ruznych typu? A proc by to mel byt globalni setting? Bude si kazda aplikace, vyzadujici jine chovani, muset nastavit vlastni locale? A co kdyz v ruznych castech aplikace (treba v 3rdparty knihovnach) budu potrebovat jine chovani?

Kazdopadne, napises nejaky konkretni navrh jak by to melo fungovat a k cemu presne by to melo slouzit nebo zustanes u "eee.. nejaky ascii string..."?

A porad by me zajimala odpoved na prvni otazku [ REDGUY @ ANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API ] .

XCHAOS: Divas se na to blbe. realloc neni (typicky) zadna magie se strankovanim, na to zapomen. Proste si to predstav ze reknes libc "Hele, vim ze pamet pro malloc beres z nejakyho vetsiho kusu. Bud tak hodna, jestli za timhle kouskem pameti cos mi pred chvili dala je jeste dalsi volny nepouzity misto, tak ten muj kousek zvets na tolikhle bytu, jinak by normalnim postupem pridel novej kus pameti a na jeho zacatek prekopiruj tohle, at se s tim nemusim delat sam. Diky." Jestli chces, muzu ti to namalovat 8)

DAVIDOWITCH: ano, tohle jsem zhruba potřeboval vědět... to mi ušetří spoustu času.

...a můžu se tedy spolehnout, že všechny běžné architektury, na které je libc portovatelné, to budou řešit tím přečíslováním stránek - a ne kopírováním paměti bajt po bajtu ? protože ono je to dost podstatné... přivedlo mi to na myšlenku zacházet s alokací polí výrazně jinak, než s alokací stringů (přeci jen jsem nevzdal myšlenky na ten vlastní alokátor paměti, že...)

_BENNY: já jsem handles používal v 16bit DOSu ... později jsem se dočetl, že stejnou fintu používal původní 16ti bitový MAC OS. (před každým přístupem k pointeru se musela volat mapující funkce, která znovu konvertovala handler na pointer: občas naštěstí ani nebylo nutné skutečně něco fyzicky přesouvat odjinud, protože ten správný blok paměti byl čirou náhodou zrovna namapovaný...)

moje handlery byly 16tibitové, ale uměly adresovat až 4 GB XMS/EMS/hdd swap :-)

ANT_39: no mě jde spíš o to, že přetěžovat operátory jako + nebo == mě přijde poněkud... víš co. (třeba proč by řetězení stringů mělo mít paralelu k aritmetickému sčítání ? co se mi líbí na C a PHP - a třeba i Bashi - je to, že + prostě není na stringy ... natož jiné kontejnery). (Sakra... na to, jak moc na to PHP jinak nadávám, tak musím uznat, že řetězní stringů má relativně dobrý .. aspoň syntakticky)

spíš jsem ten operátor =~ nebo ~~ myslel tak, že by měl být asi jediný "přetížitelný": právě když už operátor, od kterého nevím, co mám čekat - tak ať se aspoň odlišuje od matematických.

ale jinak operátorů už nechme. (C je stejně neumí přetěžovat, tak to max. bude funkce ... :-)