realloc() changes the size of the memory block pointed to by ptr to size bytes. The contents will be unchanged to the minimum of the old and new sizes; newly allocated memory will be uninitialized. If ptr is NULL, then the call is equivalent to malloc(size), for all values of size; if size is equal to zero, and ptr is not NULL, then the call is equivalent to free(ptr). Unless ptr is NULL, it must have been returned by an earlier call to malloc(),
calloc() or realloc(). If the area pointed to was moved, a free(ptr) is done.

.. tak, a teď babo raď: tohle je skvělá věc (Borland C libc v dřevních dobách DOSu jí podle mě neměla, a z toho vyplynula moje averze k polím a preference spojových seznamů) - ale co o tom realloc() doopravdy kdo víme ? pravděpodobně bude docela platform-dependet: tam, kde lze provést přemapování stránek paměti, aby se alokovaný prostor rozšířil, tam to zřemě bude docela ďábelsky rychlé - ale zřejmě ne každá architektura takové přemapování podporuje - viz ta zmínka If the area pointed to was moved.... ovšem zase pokud realloc() skutečně změní umístění alokovaného bloku, tak tím ovšem zneplatní všechny pointery, které ukazovaly do toho původního bloku - je to tak ? To by znamenalo použít tuto fintu v podstatě jen v kombinace se zcela specifickými programátorskými praktikami (a to vůbec nemluvím o takové thread-safety...)

máte s tímto někdo zkušenost ? chystám se udělat si pár testů a možná i benchmarků, jak se to chová pro různé velikosti bloků paměti před a po realokaci... ale nerad bych znovuobjevoval Ameriku.. takže uvítám pokud se někdo podělí se svými zkušenostmi.

ANT_39: mě šlo zhruba o to předvést, že programovací jazyky se často holedbají abstrakcí, kterou není těžké definovat a implementovat... a naopak se okázale vysmívají lidem, kteří požadují abstrakci, kterou není jednoduché implementovat.

prostě se vrátím k základnímu pocitu: ať je MySQL jakékoliv, tak nám na serverech žere zlomek resourců, oproti tomu, kolik toho žerou PHP skripty (paměti, CPU time). a přitom abstrakce, kterou MySQL nabízí, je neskonale sofistikovanější, než abstrakce, kterou nabízí PHP - které reálně neumí skoro nic ! (v podstatě jediný větší komfort jsou asociativní pole - zbytek jsou povětšinou wrappery nad službami systému).

takže prostě jen tvrdím, že prostor pro optimalizace tu je, a že abstrakce, kterou programátorům vnucují vyšší jazyky, nemusí být nutně ta jediná správná, kterou bychom potřebovali: prostě nás existující prostředí nutí myslet určitým způsobem, nutí nás to využívat zdroje určitým způsobem, apod.

a teď bych už možná obrátil list, s dovolením.

REDGUY: zapoměl si na druhou část mého příspěvku - MATCH AGAINST se ovšem mění podle nastavení serveru, takže ty věci nejsou zcela jednoznačné.

no a 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. Dnes máš přece spoustu knihovních funkcí implementovaných v libc, jejichž chování se mění podle použitého locale... a často i způsobem, který reálně lidé ani moc nechtějí a obcházejí ho (např. desetinná čárka vs. desetinná tečka)

XCHAOS: No v tom specifikovanem vyznamu prave bude zakopany pes, ze...
Nicmene, az udelas ~~, tak dalsim krokem by imho mela byt priblizna diference ~-.

XCHAOS: Abych ocitoval (s mirnou modifikaci) sveho oblibeneho myslitele Iniga Montoyu: "You keep using that expression. I do not think it means what you think it means."

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 ] .

Mozna by pomohlo abys napsal, k cemu presne se tvuj fuzzy operator bude pouzivat a jakou presne bude mit semantiku? Urcite by to bylo prinosem pro debatu. Samozrejme, drobna nevyhoda by byla, ze bys pak jeho udajny smysl a funkci nemohl retroaktivne menit, podle toho jak ti budeme jednotlive fantazie vyvracet 8)

XCHAOS: ale třeba sémantika operátoru LIKE v SQL je pokaždé stejná. - ano, uplne stejne jako je pokazde stejna semantika operatoru "==" v C. Na rozdil od tveho fuzzymatche je ovsem (a) predem presne definovana a (b) uzitecna pro velkou cast aplikaci.

REDGUY: -1 strawman fallacy

ANT_39: ...ale třeba sémantika operátoru LIKE v SQL je pokaždé stejná. ovšem chování MATCH AGAINST je oproti tomu konfigurovatelné na úrovni serveru.

já mám na mysli fuzzy porovnání s jednoznačně specifikovaným významem. komu by to nestačilo, musel by pochopitelně implementovat něco vlastního.

DANIELSOFT: no prostě by mohl být true, když to aprox_eq() by bylo false :-) česky "ani vzdáleně se nepodobá" :-)

tak mě při vaší diskuzi napadl fuzzy operátor ~!= "přibližně se nerovná" a přemýšlím, co by vracel: vždycky true?

XCHAOS: No, vis co, me jako trolovani prijde i kdyz nekdo nadava na neco co nezna. Proto by me fakt zajimala odpoved na prvni otazku v me minule zprave 8)

těch více ruzných interfaců připojených k objektům (které umí Java) jsou věc, která je dost blízká mému přístupu, a která mě zajímá. - whoa. Co by se tak dalo v takove situaci delat? Hmmm... co treba "naucit se Javu"? Bah, radsi ne, to je prilis radikalni a vyzaduje to urcite usili 8)

jinak samozřejmě to ~= (nebo jak) není primárně určené na porovnávání floatů - ze ne? Zatim jsi to tak podaval. To jsem to asi musel spatne pochopit 8)

nejčastější "fuzzy" záležitost je podle mě porovnání čísla ve stringovém formátu s integerem - cozeto? A co je na tomhle (a) fuzzy a (b) problemove? Java: Integer.parseInt(cislo_ve_stringu) == cislo_v_cislu. A v Perlu se o to vubec starat nemusis 8)

ale už fakt nechci plýtvat časem na to, abych ti něco vysvětloval... - jojo, vime proc. Radsi me zase zabanuj 8)

REDGUY: no kdyby sis odpustil to věčné trollování, tak bys i uměl být konstruktivní.

těch více ruzných interfaců připojených k objektům (které umí Java) jsou věc, která je dost blízká mému přístupu, a která mě zajímá.

jinak samozřejmě to ~= (nebo jak) není primárně určené na porovnávání floatů - možná by pro ně šlo nějak zoptimalizovat, nevím, nechce se mi to řešit. vzhledem ke globální inflaci není float tak častý typ ani třeba v eshopech :-) nejčastější "fuzzy" záležitost je podle mě porovnání čísla ve stringovém formátu s integerem - ale už fakt nechci plýtvat časem na to, abych ti něco vysvětloval...