ANT_39: tak teď si zmátl i mě :-) unused ? ... proč ? :-)

ANT_39: K tomuhle me napadla jeste nasledujici prasarnicka:

#define NAMED(X) __attribute__ ((unused)) struct __##X##_struct_t X
#define DEFNAMED(X) struct __##X##_struct_t {} X
DEFNAMED(withColor);
int drawPointAt (int x, int y, NAMED(withColor), unsigned color) {
  // ...
  return 0;
}
int main(int argc, char *argv[]) {
  return drawPointAt (10, 20, withColor, 100);
}

DAVIDOWITCH: ohledně množství dostupných vychytávek nehodlám nijak polemizovat.

pouze tvrdím, že "méně je někdy více". a že jednoznačnost/nemožnost přetížení určitých struktur jazyka může být výhoda zejména pro... no, dejme to ne "začátečníky", ale "průměrně talentované vývojáře v produkčním prostředí".

XCHAOS: Ma vic ficur. Furt muzes ignorovat 99% a jen si pretizit operator+ na Vec3f, aby ses z vektorovy matiky nezblaznil uplne. Nebo templatovat nejakou fci, misto uzasnych kras abs, fabs, fabsf.

ANT_39: striktně vzato je to tady offtopic :-)

(ovšem já jsem před časem navrhl dva další operátory v C, které by společně umožňovaly rekurzi uvnitř C expressionů :-) mohly by se zapisovat třeba @ a $ nebo tak něco :-) naštěstí jejich implementace přesahuje moje možnosti coby osamělého infoteroristy)

XCHAOS: Uz bylo na case, aby se to tam dostalo. Existuje asi tak 10 knihoven, ktery ti to do C++ dokazou propasovat i tak--pokud vis presne, do posledni carky, jak to napsat. Kdyz nevis, tak ty chybovy hlaseni ti zlomi krk. Sablony v sablonach jinych sablon atd.

C++0x Finally Becomes a Standard - Slashdot
http://developers.slashdot.org/story/11/08/16/178227/C0x-Finally-Becomes-a-Standard
lambda funkce v C++ ? no ty krávo.

DAVIDOWITCH: ach jo, to jsou zase flejmy...

prostě spoják (což je čirou náhodou MOJE oblíbená datová struktura, dílem skutečně i kvůli tomu, že jsem neznal realloc - ale NEJEN kvůli tomu...) bude mít s konzervativní garbage collection celou řadu problémů, podle mě: víceméně, celou alokovanou paměť musíš scanovat, zda neobsahuje pointer sama do sebe - a při větším množství alokované paměti to vidím dost jako problém.

moje kontexty se chovají divně, pokud v nich někdo použije break - ale aspoň se chovají DETERMINISTICKY divně. nemůžu si pomoct, ale konzervativní GC může podle mě vést k nedefinovanému chování - pokud se aplikace pustí do nějaké odvážnější pointerové aritmetiky.

XCHAOS: 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, - takze odpoved na moji otazku o par zprav dolu je "to fungovat nebude, break/continue ve smyslu ukonci/restartuj smycku while/for spolu s kontexty nebude mozne pouzit, ale protoze to bude napsane v manualu, neni to chyba ale feature!", je to tak? Nebo presneji receno - pokud pouzijes break/continue tak jak jsi zvykly z pricetnych jazyku, Cll1 bez jakehokoliv warningu nebo erroru vygeneruje zcela spatny kod. Je tohle rozumne chovani jednoducheho jazyka pro zacatecniky, jehoz cilem je usnadnit programovani oproti holemu C?

A prosim, pripomen mi - kdyz neco zaalokuju v remember {} bloku, kdy presne se to uvolni?

DAVIDOWITCH: (jinak já samozřejmě žádné existující keywordy redefinovat nehodlám... to je tlustá čára, za kterou bych se svými makry nešel ani já... když udělám ve jménu čitelnosti věci jako <tt>#define and &&</tt> aby to bylo více čitelné pro lidi zvyklé třeba na PHP benevolentní zápis, tak je to popravdě něco přesně opačného...)

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.