C lernen oder C++ ?

volkard schrieb:

Du vergißt das

if (acquireRessource() == OK)
{
   useRessource();
   if(bla) return foo;
   freeRessource();
}

^^anfängerfehler. der code muss in 'useRessource' rein.
(mist, ich hab 'resource' doch tatächlich wieder mit zwei 's' geschrieben)

volkard schrieb:

... Müll. Wie vor Kurzem auch aus Deiner Tastatur

;fricky schrieb:
...

ja, das ist suboptimal. aber schau mal 4 oder 5 postings tiefer, da ist ein link zu 'ner scheinbar vielversprechenden lösung.

volkard

;fricky schrieb:

volkard schrieb:
Du vergißt das
if (acquireRessource() == OK)
{
   useRessource();
   if(bla) return foo;
   freeRessource();
}
^^anfängerfehler. der code muss in 'useRessource' rein.
(mist, ich hab 'resource' doch tatächlich wieder mit zwei 's' geschrieben)

if (acquireRessource() == OK)
{
   if(useRessource()==ERROR_FOO)
      return ERROR_FOO;
   freeRessource();
}

volkard schrieb:

if (acquireResource() == OK)
{
   if(useResource()==ERROR_FOO)
      return ERROR_FOO;
   freeResource();
}

nein, menno, programmierst du erst seit heute, oder versuchst du jetzt mit aller gewalt eine existenzberechtigung für RTTI zu konstruieren? *fg*
so muss das:

...
if (acquireResource() == OK)
{
   err = useResource();
   freeResource();
   return err;
}
...

;fricky schrieb:

RTTI

RAII meinte ich.

volkard

;fricky schrieb:

volkard schrieb:
if (acquireResource() == OK)
{
   if(useResource()==ERROR_FOO)
      return ERROR_FOO;
   freeResource();
}
nein, menno, programmierst du erst seit heute, oder versuchst du jetzt mit aller gewalt eine existenzberechtigung für RTTI zu konstruieren? *fg*
so muss das:
...
if (acquireResource() == OK)
{
   err = useResource();
   freeResource();
   return err;
}
...

Und bei fünf benötigten Ressourcen und sieben möglichen Fehlern wird's eine goto-Orgie oder fünf verschachtelte Wrapper-Funktionen oder oder oder, nur ja nichts Vernünftiges mehr.
RAII machts einfach und harmonisch.

volkard schrieb:

Und bei fünf benötigten Ressourcen und sieben möglichen Fehlern wird's eine goto-Orgie oder fünf verschachtelte Wrapper-Funktionen oder oder oder, nur ja nichts Vernünftiges mehr. RAII machts einfach und harmonisch.

naja, fehler beim ressource-locking und unlocking etc. können sehr vielschichtig und individuell sein. genauso wie die behandlung von fehlern. es gibt kein patentrezept, mit dem sich das alles erschlagen liesse. auch in C++ können destruktoren und konstruktoren scheitern, exceptions innerhalb von exception-handlern, destruktoren und konstruktoren auftreten und..und...und. du hast selbst (in einem thread hier im C-forum) geschrieben, dass generalisierungen beim programmieren nichts bringen (oder hab ich das geträumt?). man kann mit einem künstlich geschaffenen konstruktor/destruktor/softwareexception-system wenig erreichen, wenn die wirklichkeit nicht mitspielt (siehe stackoverflow-thread in RudP, röchelbärchens C++-problematik mit stackoverflows in destruktoren, die unter C überhaupt nicht existiert). wenn RAII so perfekt geeignet fürs speichermanagement usw. ist, warum gibt es dann zig verschiedene sogenannte 'smartpointer'-typen in C++? nee, also wirklich: C++ fügt zusätzliche komplexität hinzu, wo überhaupt keine sein muss. und ich behaupte mal, dass c++-programmierer viel zeit investieren, um eine aufgabenstellung in ein C++-korsett zu zwängen. und dass sie sich grösstenteils mit C++ selber beschäftigen, anstatt an realen problemlösungen zu arbeiten. ganz nach dem motto: http://en.wikipedia.org/wiki/Golden_hammer

volkard

;fricky schrieb:

volkard schrieb:

Und bei fünf benötigten Ressourcen und sieben möglichen Fehlern wird's eine goto-Orgie oder fünf verschachtelte Wrapper-Funktionen oder oder oder, nur ja nichts Vernünftiges mehr. RAII machts einfach und harmonisch.

naja, fehler beim ressource-locking und unlocking etc. können sehr vielschichtig und individuell sein. genauso wie die behandlung von fehlern. es gibt kein patentrezept, mit dem sich das alles erschlagen liesse. auch in C++ können destruktoren und konstruktoren scheitern, exceptions innerhalb von exception-handlern, destruktoren und konstruktoren auftreten und..und...und. du hast selbst (in einem thread hier im C-forum) geschrieben, dass generalisierungen beim programmieren nichts bringen (oder hab ich das geträumt?). man kann mit einem künstlich geschaffenen konstruktor/destruktor/softwareexception-system wenig erreichen, wenn die wirklichkeit nicht mitspielt (siehe stackoverflow-thread in RudP, röchelbärchens C++-problematik mit stackoverflows in destruktoren, die unter C überhaupt nicht existiert). wenn RAII so perfekt geeignet fürs speichermanagement usw. ist, warum gibt es dann zig verschiedene sogenannte 'smartpointer'-typen in C++? nee, also wirklich: C++ fügt zusätzliche komplexität hinzu, wo überhaupt keine sein muss. und ich behaupte mal, dass c++-programmierer viel zeit investieren, um eine aufgabenstellung in ein C++-korsett zu zwängen. und dass sie sich grösstenteils mit C++ selber beschäftigen, anstatt an realen problemlösungen zu arbeiten. ganz nach dem motto: http://en.wikipedia.org/wiki/Golden_hammer

Ist im Prinzip alles richtig. Aber beim Ressourcen-Management glänzt C++ wirklich und ist Gold in 95% der Aufgabenstellungen. Bei den anderen gehe ich in meinem Vorgehen halt nach C runter oder nach Lisp hoch oder verbasele das Problem im Basic-Stil.

volkard schrieb:

Aber beim Ressourcen-Management glänzt C++ wirklich und ist Gold in 95% der Aufgabenstellungen.

die '9' stört mich ein wenig. wenn ich annehme dass viele C++ codes RAII ausgiebig nutzen, dürfte eine hohe acquire...free frequenz üblich sein (rechenzeit-verbraterei, sinnloser speicher- und energieverbrauch), wenn z.b. der C++ progger gedankenlos mit seinen STL-objekten rumfummelt. genauso wie viele überflüssige kopieraktionen (weshalb c++ fans selbst als for-schleifenzähler lieber ++i statt i++ bevorzugen, *fg*).

volkard schrieb:

Bei den anderen gehe ich in meinem Vorgehen halt nach C runter oder nach Lisp hoch oder verbasele das Problem im Basic-Stil.

oder du benutzt C++ ohne RAII, ohne destruktoren und konstruktoren, ohne cin/cout und ohne operatorüberladung, ganz vorsichtig mit templates sein, ohne die STL, ohne C++0x-features und ohne boost sowieso (if you end up using c++, don't try to fix it or even boost it *fg*). ich weiss, dass sowas schwer ist für euch hartgesottene c++ freaks, aber als belohnung winken einfacher, übersichtlicher code, kleine schnelle executables, maximale portabilität, usw.

volkard

;fricky schrieb:

die '9' stört mich ein wenig. wenn ich annehme dass viele C++ codes RAII ausgiebig nutzen, dürfte eine hohe acquire...free frequenz üblich sein (rechenzeit-verbraterei, sinnloser speicher- und energieverbrauch), wenn z.b. der C++ progger gedankenlos mit seinen STL-objekten rumfummelt. genauso wie viele überflüssige kopieraktionen (weshalb c++ fans selbst als for-schleifenzähler lieber ++i statt i++ bevorzugen, *fg*).

Wer sagt, daß man in C++ jemals mehr Arbeit dem Prozessor aufbürden muß als es in C ginge?
Muß man nämlich nicht. Die STL ist auch gar nicht teuer. Einige potentielle überflüssige Kopieraktionen entstehen durch Mittel, die C halt gar nicht hat, und auch da nur, wenn man C++ falsch verwendet.

;fricky schrieb:

oder du benutzt C++ ohne RAII, ohne destruktoren und konstruktoren, ohne cin/cout und ohne operatorüberladung, ganz vorsichtig mit templates sein, ohne die STL, ohne C++0x-features und ohne boost sowieso (if you end up using c++, don't try to fix it or even boost it *fg*). ich weiss, dass sowas schwer ist für euch hartgesottene c++ freaks, aber als belohnung winken einfacher, übersichtlicher code, kleine schnelle executables, maximale portabilität, usw.

Hier ein schmerzloser Schummel-Speedtest. Schmerzlos in dem Sinne, daß die main genauso aussieht, wie mit klassischem C++.
http://www.file-upload.net/download-2088733/prime.exe.html (Ist kein Trojaner drin, keine Bange. Aus dem Alter bin ich raus.)
Die wird auffallen, daß er dreimal so schnell wie

#include <stdio.h>
int main(){
	int i;
	for(i=0;i<=664579;++i)
		printf("%d %d\n",i,i);
	return 0;
}

ist und dazu noch 664579 Primzahlen berechnet. Ich hab halt cout ein wenig aufgebohrt. Kennst Du so ein Spiel auch in C?

volkard schrieb:

Hier ein schmerzloser Schummel-Speedtest. Schmerzlos in dem Sinne, daß die main genauso aussieht, wie mit klassischem C++.
http://www.file-upload.net/download-2088733/prime.exe.html (Ist kein Trojaner drin, keine Bange. Aus dem Alter bin ich raus.)

poste doch mal den quelltext. keine bange, ich bin zwar nur ein blöder C-programmierer, aber vielleicht bekomme ich's ja hin, deinen code durch einen C++ compiler zu jagen.

volkard schrieb:

Ich hab halt cout ein wenig aufgebohrt. Kennst Du so ein Spiel auch in C?

naja, ein C compiler kann halt keine templates, da müsste man wohl was von hand umformen, aber geht bestimmt.

volkard

;fricky schrieb:

oder du benutzt C++ ohne RAII

Nee, das wäre törich, fürchte ich.

;fricky schrieb:

ohne destruktoren und konstruktoren

dito.

;fricky schrieb:

ohne cin/cout

Die Standardimplemetierung gefällt mir nicht. Mit c++0x könnte man statt

cout<<"Der Elefant "<<lpszName<<" wiegt "<<dMasse<<" Kilogramm.";

auch ohne Performanceverlust

print("Der Elefant ",lpszName," wiegt ",dMasse," Kilogramm.");

schreiben. Aber printf mit seinem Laufzeitgeparse muß langsamer sein. Außer natürlich man blödelt ein wenig rum beim Bauen von cout, da war wohl ein Ballmer-Peak.

;fricky schrieb:

und ohne operatorüberladung

Für mathematische Sachen ganz praktisch und triviale Sachen wie Array-KLassen, die [] anbieten und Iteratoren, die ++ und * anbieten. Der << von cout ist recht egal, da ich viel VB und C++/CLI mache, hab ich mich ans WriteLine auch wieder gewöhnt.

;fricky schrieb:

ganz vorsichtig mit templates sein

Außer natürlich, wo sie offensichtlich gut sind, sagen wie mal swap, min, max, und alle Container.

;fricky schrieb:

ohne die STL

Die verwende ich in der Tat sparsam. Aber die Container sind klasse.

;fricky schrieb:

ohne C++0x-features

foreach!

;fricky schrieb:

und ohne boost sowieso

Verwende ich nicht.

;fricky schrieb:

als belohnung winken einfacher, übersichtlicher code, kleine schnelle executables, maximale portabilität, usw.

Och, Standard-C++ ist mir ausreichend portabel. Schnell ist mein Code eigentlich auch. Bei gelegentlichen Programmierwettbewerben war ich nicht immer auf den hinteren Rängen. Klein ist so ein Ding, da werfen die GCC-Macher einem Felsbrocken in den Weg. Zum Beispiel zahlt man für die erste Exception 30k (voller Nullbytes) an reserviertem Speicher für Exception-Objekte. Die erste virtuelle Funktion hat AFAI dieselben Kosten. der default-terminate-handler will immer den Namen der Exceptionklasse ausgeben, haben wir gleich RTTI (nicht RAII) drin. Zusammen so um die 50k Speicher als Fixkosten, das sind fast 0,0025% von meinen 2G auf dem Hauptrechner. Es wäre alle vermeidbar, aber die GCC-Leute haben es nicht vorgesehen, daß man eigene sparsame Implementierungen reinlinkt, weshalb man den Compiler tunen müßte. Ist zwar einfach, aber für die 50k mache ich mir keine Mühe. Rate, weshalb die prime.exe 64000 Bytes braucht. :xmas1:

volkard

;fricky schrieb:

poste doch mal den quelltext. keine bange, ich bin zwar nur ein blöder C-programmierer, aber vielleicht bekomme ich's ja hin, deinen code durch einen C++ compiler zu jagen.

Würde ich gerne, aber ich fürchte, den hab ich verschludert.
Übrigens kann ich inzwischen im Prinzip integers *erheblich* schneller ausgeben, der Kern ist, durch Multiplizieren die führenden Dezimalstellen am hi-Ende rauspurzeln zu lassen, denn MUL ist viel viel schneller als DIV.

char* UInt32ToAsciiWith5Digits(char* dst,UInt32 x){
	EdxEax edxeax;
	edxeax=mul(x,pow(2,32)/pow(10,4)+1);
	*dst++=edxeax.dl+'0';
	edxeax=mul(edxeax.eax,10);
	*dst++=edxeax.dl+'0';
	edxeax=mul(edxeax.eax,10);
	*dst++=edxeax.dl+'0';
	edxeax=mul(edxeax.eax,10);
	*dst++=edxeax.dl+'0';
	edxeax=mul(edxeax.eax,10);
	*dst++=edxeax.dl+'0';
	return dst;
}

Hab das da noch gar nicht eingebaut, die prime.exe ist vom März, da war ich noch total dumm.
Laß Dich aber nicht hindern, mal kurz was zu bauen, das auch schnell aussieht.

asc

;fricky schrieb:

asc schrieb:

Ich finde den C++ weg persönlich besser, als immer den GC aufgezwungen zu bekommen.

das sagst du jetzt, aus deiner perspektive als C++ progger. unter Java hat man mit dem GC keine probleme, ohne hätte man die allerdings.

Davon abgesehen das ich privat mehr mit Sprachen programmiere die einen GC haben (Wenn auch C#), als mit Sprachen die keinen GC haben: Ein GC kann auch Probleme mit sich bringen (z.B. wenn es darum geht das eine Freigabe tatsächlich sofort gemacht werden muss - bei Ressourcen u.a.), die man zwar umschiffen kann (z.B. IDispose oder ähnliches), aber dennoch unschön in der Anwendung sind.

Ein GC ist kein Totschlagargument für eine Sprache, sonst solltest du kein C programmieren. Und zu deinen Ressourcenfreigabebeispielen: In der Regel hantiert man nicht nur mit einer herum, sondern mit mehreren. Die If-Kaskaden sind imho fehlerträchtiger (und auch die Gefahr einmal Rückgaben zu vergessen) als RAII-Techniken.

;fricky schrieb:

asc schrieb:

Nur das du C++ grundsätzlich ablehnst und dennoch mitredest wenn es auch um C++ geht

es muss ja wenigstens einen geben, der gegen diese ständigen lobhudeleien betreffend C++ angeht. *fg*

Ich sehe in diesem Thread keinerlei Lobhymnen, egal auf welche Sprache bezogen.

Davon abgesehen würde ich einem Programmieranfänger auch eher zu C# oder Java raten, nur kotzen mich deine Hasstriaden auf C++ wirklich an. Wenn du es nicht magst dann reicht es wenn du es einmal sagst. C++ hat Macken (ebenso wie C, Java, C# usw.) und es gibt persönliche Geschmäcker, aber wenn du wenigstens auf die wirklichen Probleme eingehen würdest, und nicht an den Stellen wo dich die Syntax stört...

volkard

;fricky schrieb:

naja, ein C compiler kann halt keine templates, da müsste man wohl was von hand umformen, aber geht bestimmt.

Makros. :xmas2:

KornChief

Danke nun allen beteiligten, wir wissen nun, was wir tuen.

Danke.

Ich möchte mich zwar nicht einmischen (Da ich auch keine Ahnung habe mal davon abgesehen :lol:), aber mir scheint es, dass dies langsam aus dem Ruder gerät. Kann man es nicht darauf belassen, dass beides gut ist? :p

LG Korn

so endet hier jede Frage die irgendwie beide Sprachen mit einbezieht. Ich persönlich finde es besser sich zuerst ein wenig in C einzulesen und dann C++ dazuzulernen, allerdings immer mit strikter Trennung was C-Sitte ist, und was das C++ Gegenstück.
Du solltest damit beginnen, was du am Anfang für einleuchtender hälst.

volkard schrieb:

;fricky schrieb:

ohne cin/cout

Die Standardimplemetierung gefällt mir nicht. Mit c++0x könnte man statt
cout<<"Der Elefant "<<lpszName<<" wiegt "<<dMasse<<" Kilogramm.";
auch ohne Performanceverlust
print("Der Elefant ",lpszName," wiegt ",dMasse," Kilogramm.");

sieht gut aus, back to the roots *fg*. ist dieses 'print' in C++0x enthalten, oder muss man sich das selber bauen?

volkard schrieb:

;fricky schrieb:

ganz vorsichtig mit templates sein

Außer natürlich, wo sie offensichtlich gut sind, sagen wie mal swap, min, max, und alle Container.

bei swap/min/max kann ich mir gut vorstellen, dass sie sehr effizient sind, aber mit containern, die zur laufzeit ihren füllstand ändern, dürfte C++ auch einiges an mühe haben.

volkard schrieb:

...da werfen die GCC-Macher einem Felsbrocken in den Weg. Zum Beispiel zahlt man für die erste Exception 30k (voller Nullbytes)

foobar! KO-kriterium für C++ oder GCC (GCC nehme ich an).

volkard schrieb:

Die erste virtuelle Funktion hat AFAI dieselben Kosten.

ok, KO-kriterium für virtuelle funktionen unter C++ oder GCC, (GCC nehme ich an).

volkard schrieb:

der default-terminate-handler will immer den Namen der Exceptionklasse ausgeben, haben wir gleich RTTI (nicht RAII) drin. Zusammen so um die 50k Speicher als Fixkosten

ok, all diesen mist kannst du verhindern, indem du C statt C++ verwendest, versuch es einfach mal. ich bin mir sicher, dass viel von diesem default-bullshit, den C++ so braucht, dann einfach garnicht mehr nötig ist. gerade für deine zahlentheorie/primzahlen-experimente, die normalerweise sehr rechenintensiv sind (ausser vielleicht, du hast neue mathematische verfahren entwickelt, die dich berühmt machen werden, ich warte ja schon darauf, dass dein name zwischen pierre de fermat und david hilbert erwähnt wird *fg*)

asc schrieb:

Ein GC kann auch Probleme mit sich bringen (z.B. wenn es darum geht das eine Freigabe tatsächlich sofort gemacht werden muss - bei Ressourcen u.a.), die man zwar umschiffen kann (z.B. IDispose oder ähnliches), aber dennoch unschön in der Anwendung sind.

nee, du musste einfach nur gedanklich speicherfreigabe vom 'resource-unlock' trennen. du gibst z.b. die ressource frei, wenn du sie nicht mehr benötigst (den socket, den window-handle, whatever...), den dazugehörigen speicher gibt der GC automatisch frei, darum musste dich nicht kümmern. für einen c++ progger ist das möglicherweise intellektuell ein sprung in eine andere dimension, aber nix, was so dermassen abstrakt ist, dass er's nicht verstehen kann (hat er immerhin schon vorher c++ zum teil verstanden *fg*)

asc schrieb:

Ein GC ist kein Totschlagargument für eine Sprache, sonst solltest du kein C programmieren.

ich programmiere in zwei welten, die sich sehr unterscheiden. in der einen ist jegliche form von automatischem speichermanagement nahezu ausgeschlossen (sogar manuelles malloc/free), in der anderen existiert theoretisch speicher ohne ende und man sagt einfach 'new' und tschüss.

asc schrieb:

Und zu deinen Ressourcenfreigabebeispielen: In der Regel hantiert man nicht nur mit einer herum, sondern mit mehreren. Die If-Kaskaden sind imho fehlerträchtiger (und auch die Gefahr einmal Rückgaben zu vergessen) als RAII-Techniken.

naja, wie schon gesagt, die anforderungen sind sehr unterschiedlich. es gibt ressourcen, die man mehrfach anfordern und mehrfach konkurrierend benutzen kann, oder solche mit exklusivem zugriff, oder welche, die nur eine bestimmte anzahl an 'clients' vertragen, usw. das ist alles sehr individuell. einfach zu sagen 'ich mach das jetzt mit RAII' ist blauäugig, meistens doof und geht voll nach hinten los.

asc schrieb:

nur kotzen mich deine Hasstriaden auf C++ wirklich an. Wenn du es nicht magst dann reicht es wenn du es einmal sagst. C++ hat Macken (ebenso wie C, Java, C# usw.) und es gibt persönliche Geschmäcker, aber wenn du wenigstens auf die wirklichen Probleme eingehen würdest, und nicht an den Stellen wo dich die Syntax stört

die oberflächlichen macken, die ich kenne, reichen aus, um C++ nicht zu verwenden und sogar zutiefst zu verabscheuen. ich habe einige male erlebt, wie leute sich mit C++ das bein weggeschossen haben (embedded system - out of memory - RAM wie auch ROM und/oder performanceprobleme), weil sie in ihrer einfältigkeit dachten, C++ wäre ein besseres C. ich verspüre nicht die geringsten ambitionen, in die tiefen von C++ hinabzusteigen, um es weiter kennenzulernen und euch mit diffizilerer kritik zu nerven (es wäre auch mit schmerzen meinerseits verbunden). von daher ist doch alles gut, haltet mich für den ewig gestrigen, der sich allem neuen verweigert (*lol*' C++ ist ~30 jahre alt) und dann ist die welt wieder in ordnung *fg*

volkard

;fricky schrieb:

volkard schrieb:

;fricky schrieb:

ganz vorsichtig mit templates sein

Außer natürlich, wo sie offensichtlich gut sind, sagen wie mal swap, min, max, und alle Container.

bei swap/min/max kann ich mir gut vorstellen, dass sie sehr effizient sind, aber mit containern, die zur laufzeit ihren füllstand ändern, dürfte C++ auch einiges an mühe haben.

also zum Beispiel vector mit push_back. das ist natürlich nicht zu vergleichen mit rohen arrays. vergleichen kannst du rohe arrays mit einem trivialen array-wrapper, der hat aber gleich als bonus, daß man im op[] assert reinhaut (und bei meiner implementierung, weil ich faul bin, daß er bei gleichem anwendungscode auf dem stack oder heap liegen kann und wenn sich der anwender nicht festlegen mag, bis 4096 bytes auf dem stack und darüber auf dem heap liegt, deswegen war diese stack-diskussion auch nicht so extrem sinnvoll für mich). willst du die funktionalität von vector mußt die die bezahlen, auch in C. willst du eine verkettete liste mußt du zahlen, auch in C. willst du einen AVL-Baum mußt du zahlen, auch in C. nur müßte man in C böse mit makros rumhampeln, um die effizienz von C++ zu erreichen, ich erinnere mal an das durchaus lahme qsort und das schnelle std::sort.

volkard

;fricky schrieb:

volkard schrieb:

der default-terminate-handler will immer den Namen der Exceptionklasse ausgeben, haben wir gleich RTTI (nicht RAII) drin. Zusammen so um die 50k Speicher als Fixkosten

ok, all diesen mist kannst du verhindern, indem du C statt C++ verwendest, versuch es einfach mal. ich bin mir sicher, dass viel von diesem default-bullshit, den C++ so braucht, dann einfach garnicht mehr nötig ist.

Gar nicht nötig. Saubere Programme laufen nie in diesen Handler rein. Der könnte meinetwegen direkt auf exit zeigen. Wäre er im GCC weak gelinkt und ich könnte den überschreiben, wäre auch alles ok. Aber nein, im startup-Code wird dessen Adresse gezogen und in eine globale Variable gelegt. Da kann ich den umdefinieren, wie ich will, gezogen ist gezogen und reingelinkt wirds. Das AUsgeben von Klartextklassennamen bei sowas ist auch gar nicht das, was ich von C++ erwarte. Aber vergiß nicht, daß mit den ca 50k die man ohne am GCC zu fummeln zahlen muß, die Fixkosten erledigt sind. Eine dicke fette Anwendung, die 200k an Nutzcode braucht, braucht deswegen halt 250k. Es ist kein Faktor, sondern nur additiv. Und die GCC-Leute haben wohl gedacht, daß die embedded-Leute eh kein C++ verwenden, und haben sich gesagt, daß auf normalen Rechnern 50k wurstegal sind.