vergesst C++ ...

volkard schrieb:

und wenn nicht, geh ich von c++ weg. dann hat's einfach keinen sinn mehr mit diesem standardisierungskomitee.

Dann würde ich weggehen, das werden die nie im Leben ändern. Geh zu C#, für C# 3.0 sind implizite Typen geplant.
btw. finde ich nicht, dass Destruktoren GC ersetzen. Destruktoren sind toll für deterministische Destruktion von Objekten, was man in jeder Sprache braucht und in jeder Sprache, die hier angesprochen wurde, auch hat. Deterministische Destruktion mit einer automatischen Speicherverwaltung zu vergleichen ist wie Äpfel mit Birnen zu vergleichen.

Bei komplizierten Zusammenhängen kann man nicht immer leicht den idealen Zeitpunkt bestimmen, wann ein Objekt freizugeben ist. Nimm doch mal nen Graphen mit vielen Knoten der ständig dabei ist, sich irgendwie zu verändern. Wie wir beide wissen, ist Referenzzählung hier nicht zuverlässig.
Was ist jetzt der ideale Zeitpunkt für die Freigabe eines Knotens? Klar geht es. Niemand behauptet, dass automatische Speicherverwaltung notwendig ist. Aber angenehm ist sie, effizient ist sie (meistens) und sie lässt sich nicht durch Destruktoren oder Referenzzählung ersetzen. Die Antwort ist, wenn man einen GC hat: "Ist mir egal, was der ideale Zeitpunkt wäre". Die Antwort ist, wenn man keinen GC hat, kompliziert, weil man den idealen Zeitpunkt schlicht nicht verpassen oder ihm zuvor kommen darf. Ich verstehe nicht, was du immer gegen garbage collection hast. Das ist wirklich ein Feature, was man meistens ohne Bedenken anwenden und einem die Arbeit wirklich erleichtern kann.

volkard

maximAL schrieb:

trotzdem muss du in der definition angeben, dass es ein triple zurückgibt -

ultra-lästig. mit typeof vom gcc kann ich die variablen ja schon machen, aber rückgabetypen in der funktionsdefintion gehen o nicht. ich hoffe auf den nächsten standard.

groovemaster

@O'Rakl
Weisst du, du bist ein echter Troll. Immer wieder die selben und sinnlosen Argumente. Wie wäre es, wenn du meine Beiträge mal ganz durchliest, anstatt einzelne Passagen zu zitieren und mir dann die Worte im Mund umzudrehen. Nur mal so als Bsp.

O'Rakl schrieb:

Hauptsache, C/C++, hm ?

Wo hab ich denn sowas gesagt? Du solltest echt Lesen lernen, vielleicht hast du deshalb auch nie C++ begriffen. Lesen heisst nicht nur, aneinander gereihte Buchstaben zu wiederholen, sondern diese auch zu verstehen.

groovemaster schrieb:

Selbst C++ Programmierer in diesem Forum betonen immer wieder, dass man die Sprache nehmen sollte, die für den Zweck angemessen ist. [...] Und wenn Python für ein Projekt die bessere Wahl ist, dann wäre ich dumm, dies nicht zu nehmen.

O'Rakl schrieb:

Nun ist es aber so, daß C++ mangels eingebauter Datenstrukturen und aufgrund des auf C aufgepropften Objekt-Modells viele sehr einfache Dinge (wie L=["a",1.0]) sehr kompliziert macht, auch wenn sie mit hohem Aufwand und unter Verwendung
äußerst raffinierter externer Bibliotheken (STL,boost,...) möglich sind.

Gähn... (Anm.: seltsamerweise musste ich tatsächlich gähnen, als ich das gelesen habe - kein Witz)

O'Rakl schrieb:

Meinst Du wirklich ?

Dir fehlt echt das Verständnis Zusammenhänge zu verstehen. Mein Statement bezog sich auf maximAL's tuple Beispiel.

O'Rakl schrieb:

Zum Einen erfordert höhere programmtechnische Eleganz
und Kürze eine gewisse Abstraktion in Form eines dynamischen Typkonzepts
und Garbage Collection

Erstmal nö. Ich wüsste nicht, warum GC zu mehr Eleganz und Abstraktion führen sollte. Beschäftige dich mal mit scope-basiertem Ressourcenmanagement, dann verstehst du vielleicht, warum C++ keinen GC braucht. Was das dynamische Typkonzept betrifft, da hab ich erstmal grundsätzlich nichts dagegen, aber nur, wenn es nicht auf Kosten des statischen Typsystems implementiert ist. Und da hab ich so meine Zweifel, dass beide Typsysteme unter einem Dach zu mehr Eleganz führen.

O'Rakl schrieb:

, zum Andern ist C++ doch schon groß und kompliziert
genug

Das kommt natürlich immer auf den Standpunkt an. Für Leute wie dich, die davon überhaupt keine Ahnung haben, mag das so erscheinen. Erfahrene C++ Programmierer werden an der Sprache nicht mehr viel finden, was wirklich kompliziert ist. Da bietet die Verwendung der richtigen Algorithmen und Design Patterns schon deutlich mehr Herausforderung.

@maximAL
Wenn ich dich richtig verstanden habe, willst du sowas hier:

auto add_multiply_divide(int a, int b)
{
    return make_tuple(a+b, a*b, double(a)/double(b));
}
// bzw.
tuple add_multiply_divide(int a, int b)
{
    return make_tuple(a+b, a*b, double(a)/double(b));
}

Sowas geht aber nicht, denn was soll der Compiler denn hier machen?

auto add_multiply_divide(int a, int b);
// bzw.
tuple add_multiply_divide(int a, int b);

Im ersten Fall kann er den Typ überhaupt nicht herleiten, ausser auto beschreibt etwas wie VB's Variant. Und im zweiten Fall weiss er zwar, dass es ein tuple ist. Er weiss aber nicht, wie es aussieht. Ausser es wird dynamisch gehandelt. Beides hat aber mit einem statischen Typsystem nichts zu tun. Und wer jetzt behauptet, dass Funktionsdeklarationen überflüssig sind, bekommt eins auf die Nuss. Gerade für Schnittstellen, zB über dynamische Bibliotheken, ist das äusserst effektiv und universell einsetzbar. Selbst in anderen Sprachen.

->Sovok<- schrieb:

und wie gesagt in der praxis sind zahlen und strings im selben container selten nötig

Das würde ich zwar nicht behaupten, für die Praxis ist das Beispiel trotzdem irrelevant, da man die Elemente des Containers eher dynamisch einliest (zB aus einem Textfile oder einer Datenbank), anstatt diese fest vorzugeben.

volkard

groovemaster schrieb:

Sowas geht aber nicht, denn was soll der Compiler denn hier machen?
auto add_multiply_divide(int a, int b);
// bzw.
tuple add_multiply_divide(int a, int b);

error 4711: auto kann nicht in deklarition ohne definition benutzt werden
error 4712: basta.

ich will das aber haben tun.
ich schreib ja jetzt schon lieber

#define AUTO(name,init) typeof(init) name(init)
AUTO(in,openFileForRead("in.txt"));
AUTO(out,openFileForWrite("out.txt"));

als

FileReader in(...);
FileReader out(...);

und weil ich schon lange vergessen haben will, wie die typen wirklich heißen, wenn ich nur die erzeugende funktion kenne, muß es dann auch weitergehen mit

auto openFileForReadByNumber(int nr){
   strstream name;
   name<<nr<<".txt";
   return openFileForRead(name.c_str());
}

daß der compiler dann auch noch dafür sorgen sollte, daß das ding nicht zwingend static linkage haben muß, gehört halt auch noch dazu. mit export?

maximAL

groovemaster schrieb:

Im ersten Fall kann er den Typ überhaupt nicht herleiten, ausser auto beschreibt etwas wie VB's Variant. Und im zweiten Fall weiss er zwar, dass es ein tuple ist. Er weiss aber nicht, wie es aussieht.

also ehrlichgesagt versteh ich das problem jetzt nicht so ganz.
nochmal ganz kurz, wie das typsystem in meinem beispiel funzt: die funktion ist generisch und erst mit dem aufruf der parameter wird der rückgabetyp bestimmt. desweiteren muss man den rückgabetyp nirgends explizit hinschreiben (auch keinen "platzhalter"), sondern es wird überprüft, welchen typ die funktion tatsächlich zurückgibt. dürfte in C++ schwierig sein, denn da muss man im prinzip gar nichts zurückgeben - selbst wenn ein rückgabewert definiert ist
quasi: würde in meiner C++ funktion return MeinInteger; stehen, dann wüsste der compiler, was ich will.

ps: das soll übrigens kein aufruf sein, diese funktionalität irgendwie nachzubauen oder den standard dementsprechend zu erweitern. ich sage nur, dass es leider so nicht geht, aber imho in eine wirklich moderne hochsprache gehört.

volkard

maximAL schrieb:

dürfte in C++ schwierig sein, denn da muss man im prinzip gar nichts zurückgeben - selbst wenn ein rückgabewert definiert ist

da wirft schon wieder einer halbwissend der armen sprache c++ was vor, was in c so ist. also mein compiler erlaubt ir nicht int f(){};.

maximAL

volkard schrieb:

maximAL schrieb:

dürfte in C++ schwierig sein, denn da muss man im prinzip gar nichts zurückgeben - selbst wenn ein rückgabewert definiert ist

da wirft schon wieder einer halbwissend der armen sprache c++ was vor, was in c so ist. also mein compiler erlaubt ir nicht int f(){};.

also mein minGW frisst das ohne weiteres. ok, mit -Wall gibts zumindest ne warnung...

GPC

maximAL schrieb:

also mein minGW frisst das ohne weiteres. ok, mit -Wall gibts zumindest ne warnung...

Mein gcc gibt nen Error raus.

Werfen wir einfach einen genaueren Blick darauf.

// nicht erlaubt
int foo() {
}

// erlaubt
int foo(bool something) {
	if( something )
		return 5;
}

affig

Artchi

maximAL schrieb:

also mein minGW frisst das ohne weiteres. ok, mit -Wall gibts zumindest ne warnung...

Mein msvc gibt nen error raus. Nur weil main() keinen return erfordert, heißt das nicht, das es bei funktionen und methoden auch so ist.

Sehr schön, das die OpenSource-Compiler so standardkonform sind.

maximAL

Artchi schrieb:

Sehr schön, das die OpenSource-Compiler so standardkonform sind.

tja, theorie und praxis, was?
ok, die leere funktion ist verboten. was ist aber mit dem if-kontrukt (laut standard)?

groovemaster

volkard schrieb:

error 4711: auto kann nicht in deklarition ohne definition benutzt werden
error 4712: basta.

LOL. Schön das du wenigstens das ganze mit Humor nimmst.

maximAL schrieb:

quasi: würde in meiner C++ funktion return MeinInteger; stehen, dann wüsste der compiler, was ich will.

Mir ist schon klar, was du willst. Aber nochmal, ein Compiler sieht bei einer Deklaration kein return MeinInteger;. Wie soll er also den Rückgabetyp bzw. -wert herleiten?

@Optimizer
Mal schauen, was der Standard dazu sagt.

Flowing off the end of a function is equivalent to a return with no value; this results in undefined behavior in a value-returning function.

Und wenn ich mir die Asm Listings beim MSC anschau, das kommt das ziemlich gut hin. Imo alles korrekt, wenn ein Compiler beim zweiten Beipiel nur eine Warnung bringt.

Ich habe ja nie behauptet, dass mein Compiler das gegen den Standard erlaubt. Ganz im Gegenteil bezog sich der Begriff "affig" auf die Regel, dass es gleichzeitig mindestens ein return-Statement geben muss, andererseits muss nicht jeder Kontrollpfad ein return-Statement enthalten. So eine inkonsequente Regel bringt meines Erachtens keinen erkennbaren Vorteil, mit Warnung zwar auch keinen Nachteil, aber naja.

Hoppla, schon wieder Feierabend... und wieder die C++-Arbeit eines Wochenendes
mit durchwachten Nächten an einem halben Vormittag erledigt.
Danke, Python.

volkard

Optimizer schrieb:

So eine inkonsequente Regel bringt meines Erachtens keinen erkennbaren Vorteil, mit Warnung zwar auch keinen Nachteil, aber naja.

naja, geschichte.
natürlich haben wir alle -Wall und -Werror an. daß es eigentlich erlaubt ist, daß eine funktion affig ist, ignoriert die c++-gemeinde einfach. und im falle eines aufrüstens der sprache mit auto, würde einfach auto verlangen, daß jeder kontrollpfad den gleichen typ zurückgibt (so hoffe ich).

aber was ist eigentlich mit

template<typename T,int size>
auto findElemAndIKnowItsExistent(T (&arr)[size],T const& toFind){
   for(int i=0;i<size;++i)
      if(arr[i]==toFind)
          return &arr[i];
   //hier ist was komisch. 
}

die normale lösung wäre

template<typename T,int size>
auto findElemAndIKnowItsExistent(T (&arr)[size],T const& toFind){
   for(int i=0;i<size;++i)
      if(arr[i]==toFind)
          return &arr[i];
   return *(T*)0;//only to make the compiler happy
}

ist aber gar nicht hübsch, wenn man kein assume hat. der happy-code wird erzeugt.

template<typename T,int size>
auto findElemAndIKnowItsExistent(T (&arr)[size],T const& toFind){
   for(int i=0;i<size;++i)
      if(arr[i]==toFind)
          return &arr[i];
   __assume(false);
}

so ist alles bestens und ms rult. nichmal die warnung ist noch da.

hmm, ok, geht ja. ich nehme meine frage zurück und lehne mich zufrieden auch zurück. ich will auto haben.

Power Off

volkard schrieb:

ich will auto haben.

Gibt's doch schon: Deklariert Variable auf dem Stack.

(also "auto" ist das Gegenteil von "register")

Ich glaube nicht, daß das Schlüsselwort in der Zukunft zweckentfremdet wird!

Deine Idee ist zwar theoretisch durchführbar, aber wozu? Nur um faulen Programmierern Tipparbeit arbzunehmen? Da kennst Du C++ aber schlecht!

Für den Compiler gibt es hier und da einige Probleme: Wenn z.B. Deklarationen ohne Definitionen auftreten. Das hast Du ja explizit ausgeschlossen, aber dann können solche Funktionen niemals external linkage haben, da ja der Rückgabetyp der Funktionen zur Compile-Zeit bekannt sein muß, was aber nicht der Fall ist, wenn die Definition in der Translation Unit fehlt. D.h. beim Versuch, eine solche Funktion extern zu referenzieren, müßte laut Deiner eigenen Regel eine Fehlermeldung kommen, weil keine Definition vorhanden ist. Externe Referenzen werden ja erst beim Linkvorgang aufgelöst. Andernfalls müßte man Compiler und Linker miteinander verquicken, was aber kaum jemand machen würde. Eine andere Möglichkeit wäre ein Intermediate-Code-Linker, der aber für das Konzept dann zwingend erforderlich wäre, da vor der Code-Generierungsphase der Code der Funktionsimplementation bekannt sein muß.

volkard

Power Off schrieb:

Ich glaube nicht, daß das Schlüsselwort in der Zukunft zweckentfremdet wird!

lies mal schnell http://www.research.att.com/~bs/C++0x_keynote.pdf

Deine Idee ist zwar theoretisch durchführbar, aber wozu? Nur um faulen Programmierern Tipparbeit arbzunehmen?

jup. und denkarbeit. manchmal ist es sauschwer, bei nem

template<class A,class B>
? operator*(A a,B b)

den typ ? zu bestimmen. nehmen wir als A und B mal physikalische größen, die im kern einen double haben und deren dimension (also einheiten) über die typen mitgeschleppt werden. man müßte zu dem an sich einfachen code, der den op* implementiert auch noch in metaprogrammierung das returntypbestimmen programmieren. wir hassen alle diese programme, die 5 nutzzeilen haben aber 250 metaprogrammierungszeilen.

Da kennst Du C++ aber schlecht!

och, die sprache kenne ich. die hat nix dagegen. den stil kenne ich, der freut sich drauf. die gemeinde kenne ich, die ist geil drauf. das standardisirtungskommitee kenne ich, die bewegen sich nicht. ich hoffe, im letzten punkt unrecht zu haben.

Für den Compiler gibt es hier und da einige Probleme: Wenn z.B. Deklarationen ohne Definitionen auftreten. Das hast Du ja explizit ausgeschlossen, aber dann können solche Funktionen niemals external linkage haben, da ja der Rückgabetyp der Funktionen zur Compile-Zeit bekannt sein muß, was aber nicht der Fall ist, wenn die Definition in der Translation Unit fehlt.

das problem haben wir auch bei templates. löst man das problem der templates mit export, löst man auch auto, oder?

Andernfalls müßte man Compiler und Linker miteinander verquicken, was aber kaum jemand machen würde.

doch. das muss gemacht werden. ist ja auch nicht da höllen-problem, wenn man aufgibt, daß der objekt-code mit alten und uralten versionen gelinkt werden kann. oder einfach für so funktionen ne unique signature machen und der linker nimmt nur die erste, die er sieht.

Power Off

volkard schrieb:

Power Off schrieb:

Ich glaube nicht, daß das Schlüsselwort in der Zukunft zweckentfremdet wird!

lies mal schnell http://www.research.att.com/~bs/C++0x_keynote.pdf

Hmmm ... erstmal danke für den Link!

Also hier der Quote für die anderen:

Example: typeof/auto
• Solve half the problem
– (first implemented in 1982!)
template<class A, class B> typeof(a*b) operator*(A a, B b)
{
   auto x = a*b; // avoid replication of expression/type
   // …
   return x;
}
• What about non-local uses?:
auto glob = x*y; // would dcl or typeof be a better keyword for this?

Der Artikel stammt offensichtlich aus der Zeit vor 2003:

Bjarne Stroustrup schrieb:

The ISO C++ standard comes up for renewal in 2003. By then,

Da der 2003er Standard längst draußen ist, ist auch der Vorschlag bereits abgelehnt worden.

Ich hab Bjarne mal angeschrieben wegen des fehlenden valof-Operators in C++, und er meinte, die Sprache sei schon dermaßen festgelegt, daß man kaum noch was ändern könne. Er sagte auch, daß er auf das Kommittee keinen Einfluß habe.

Schick ihm doch mal 'ne Mail und sag ihm, er soll doch mehr Druck machen, wirst sehen, was er zurück schreibt.

Jedenfalls, sein Vorschlag ist anders als Deiner: Bei seiner Variante ist die Bekanntheit der Typen zur Compile-Zeit erhalten.

Es könnte ein ähnliches Problem verursachen wie bei den Templates: einige Compiler werden bei "extern auto " einen Fehler bringen, andere werden's ausführen.

volkard schrieb:

man müßte zu dem an sich einfachen code, der den op* implementiert auch noch in metaprogrammierung das returntypbestimmen programmieren. wir hassen alle diese programme, die 5 nutzzeilen haben aber 250 metaprogrammierungszeilen.

Eigentlich steht doch dem gar nichts im Wege: Deklarier den Rückgabewert einfach als Referenz-Parameter (mit Template-parametrisiertem Typ). Problem gelöst!

volkard schrieb:

das problem haben wir auch bei templates. löst man das problem der templates mit export, löst man auch auto, oder?

Nein. Die meisten C++ Compiler verwenden Name-Mangling, um Namen zu exportieren. Bei Template-Klassen geht das noch, da ja die Typen einer Template-Instanz (und nur einer Instanz, nicht der Deklaration!) zur Compile-Zeit bekannt sind. Einen anonymen Rückgabewert kann man nur dann erkennen, wenn die in Frage kommenden Typen zur Compile-Zeit bekannt waren.

volkard schrieb:

doch. das muss gemacht werden. ist ja auch nicht da höllen-problem, wenn man aufgibt, daß der objekt-code mit alten und uralten versionen gelinkt werden kann. oder einfach für so funktionen ne unique signature machen und der linker nimmt nur die erste, die er sieht.

Stell Dir vor: Du würdest den gesamten Compile-Link-Prozess über den Haufen werfen müssen. Wenn Du bisher Makefiles gehabt hast, kommt ein zusätzlicher Intermediate-Code-Linker-Aufruf dazu und neue Intermediate-Objektdateien.

Das wäre eine zu große Umstellung für die Software-Industrie.

Außer, man stellt sicher, daß alte Projekte sich nach dem alten Modell compilieren lassen und stellt dem Entwickler die Verwendung des Intermediate-Code-Linkers frei, für den Fall, daß er Template-Instanzen oder variante Rückgabetypen vorher auflösen möchte (im Extremfall kommt dann bei der Nicht-Verwendung des ICL ein Linker-Fehler).

volkard

Power Off schrieb:

Da der 2003er Standard längst draußen ist, ist auch der Vorschlag bereits abgelehnt worden.

der gedanke schwebt noch rum. hab keine links, über was aktuell beraten wird.

Er sagte auch, daß er auf das Kommittee keinen Einfluß habe.

jo.

Schick ihm doch mal 'ne Mail und sag ihm, er soll doch mehr Druck machen, wirst sehen, was er zurück schreibt.

ich traue mich nicht, ich bin so ein kleines licht.

Jedenfalls, sein Vorschlag ist anders als Deiner: Bei seiner Variante ist die Bekanntheit der Typen zur Compile-Zeit erhalten.

BEI MIR AUCH! aber klaro. alles ander würde das wesen von c++ killen. laufzeit-typ-bestimmung mach interpretersprache. mit undendlich vielen vorteilen, aber mit abstraction overhead.

Es könnte ein ähnliches Problem verursachen wie bei den Templates: einige Compiler werden bei "extern auto " einen Fehler bringen, andere werden's ausführen.

man darf nicht warten, bis auch der hinterindische sogenannte c++-compiler für die kernels der miele-spülmaschinen es auch haben, sondern man muß was sinnvolles und in kurzer zeit erreichbares definieren (am besten was, was schon welche gebaut haben, wie typeof!) und verlangen.

volkard schrieb:

man müßte zu dem an sich einfachen code, der den op* implementiert auch noch in metaprogrammierung das returntypbestimmen programmieren. wir hassen alle diese programme, die 5 nutzzeilen haben aber 250 metaprogrammierungszeilen.

Eigentlich steht doch dem gar nichts im Wege: Deklarier den Rückgabewert einfach als Referenz-Parameter (mit Template-parametrisiertem Typ). Problem gelöst!

nee. muß ja speicher anlegen, was referenz verbietet. aber auch sonst kenne ich den rückgabetyp nicht. es ist nicht A oder B.

Nein. Die meisten C++ Compiler verwenden Name-Mangling, um Namen zu exportieren. Bei Template-Klassen geht das noch, da ja die Typen einer Template-Instanz (und nur einer Instanz, nicht der Deklaration!) zur Compile-Zeit bekannt sind. Einen anonymen Rückgabewert kann man nur dann erkennen, wenn die in Frage kommenden Typen zur Compile-Zeit bekannt waren.

was hindert einen daran, ins name-mangeling bei auto-return-funktionen den md5 des whtespacebereinigten codes in den namen reinzumachen? nur so als dummer gedanke, mit ein paar tagen überlegen kriegt man bestimmt auch nen guten plan hin, den man in wenigen monaten zufriedenstellend (echt zufriedenstellend meine ich damit) implementierren kann.

Stell Dir vor: Du würdest den gesamten Compile-Link-Prozess über den Haufen werfen müssen. Wenn Du bisher Makefiles gehabt hast, kommt ein zusätzlicher Intermediate-Code-Linker-Aufruf dazu und neue Intermediate-Objektdateien.

siehe gcc repro http://gcc.gnu.org/onlinedocs/gcc-4.0.1/gcc/Template-Instantiation.html#Template-Instantiation
es ist nicht notwendig, jeden zu zwingen, für doppel-definitionen nur eine echte instanz zu kreieren. der gcc sorgt wenn befohlen mit zusätzlichen repo-dateien für uniqueness. muss er aber nicht. doppel macht nur den code größer aber das prog läuft auch so. und so können wir auch fein auto machen. alle compilerbauer, die es nicht sofort perfekt hinkriegen, machen mehrfachen code. und wir geben ihnen 10 jahre, es fertigzubringen, daß sie den code auch zusammenfassen. und wir kündigen das jetzt an. wir sagen "static-variablen in funktionen, die auto zurückgeben können aber müssen nicht mehrfach sein" und "funnktionszeiger von fun... sein" und "in 10 jahren dürfen sie nicht mehr merhfach sein". wo ist das problem?

Power Off

volkard schrieb:

ich traue mich nicht, ich bin so ein kleines licht.

Na, da unterschätz Dich mal nicht so!

volkard schrieb:

Power Off schrieb:

Eigentlich steht doch dem gar nichts im Wege: Deklarier den Rückgabewert einfach als Referenz-Parameter (mit Template-parametrisiertem Typ). Problem gelöst!

nee. muß ja speicher anlegen, was referenz verbietet. aber auch sonst kenne ich den rückgabetyp nicht. es ist nicht A oder B.

Na ja, aber was spricht dagegen:

template <class A, class B, class C>
void func( A a, B b, C& c ) { c = a * b; }

und dann:

char a = 2;
short b = 7;
int c;
func( a, b, c );

bzw.

func<char,short,int>( a, b, c );

Ist mir klar, daß je abstrakter die Template-Klassen werden, um so unwahrscheinlicher ist es, daß man den Typ einiger Ausdrücke noch vorausahnen kann.

Leider hab ich so eine Konstruktion wie Du noch nie gebraucht.

Kannst Du mal ein Beispiel nennen, wo man sowas wirklich braucht? Also, in welchen Fällen ist es wirklich unmöglich, den Typ zu wissen? Ich meine, wenn ein Compiler den Rückgabetyp erraten kann, kann das ein Programmierer doch auch, oder?

(Aber ich kapier auch die BOOST Library nicht, ist mir zu unlesbar, aber ist wohl Geschmackssache; ich gehör nicht zu denen, die ständig neue Sprachfeatures lernen, wenn ich sie nicht brauche -- leider; hab lang gebraucht, bis ich mir mal die STL so richtig reingezogen habe)

volkard schrieb:

was hindert einen daran, ins name-mangeling bei auto-return-funktionen den md5 des whtespacebereinigten codes in den namen reinzumachen? nur so als dummer gedanke, mit ein paar tagen überlegen kriegt man bestimmt auch nen guten plan hin, den man in wenigen monaten zufriedenstellend (echt zufriedenstellend meine ich damit) implementierren kann.

So dumm ist der Gedanke eigentlich gar nicht. Man könnte eine Art Code-Signatur verwenden, die dann irgendwo im Objektmodul ausspezifiziert wird (z.B. als platter Syntaxbaum oder sowas).

Jedenfalls MD5 allein reicht nicht, weil sonst bei Duplikaten Mißverständnisse seitens des Compilers oder Linkers auftreten könnten. Man muß auf jeden Fall noch den Code irgendwo mit hinspeichern. Das sollte aber das geringste Problem sein.

Wenn man externe Referenzen nur zulässt, wenn auch die Implementation bekannt ist, dann dürfte das Ganze funktionieren, sogar ziemlich einfach.

volkard schrieb:

siehe gcc repro http://gcc.gnu.org/onlinedocs/gcc-4.0.1/gcc/Template-Instantiation.html#Template-Instantiation

Yikes! IBM Visual Age, ick hör dir trapsen ...

volkard schrieb:

es ist nicht notwendig, jeden zu zwingen, für doppel-definitionen nur eine echte instanz zu kreieren. der gcc sorgt wenn befohlen mit zusätzlichen repo-dateien für uniqueness. muss er aber nicht. doppel macht nur den code größer aber das prog läuft auch so. und so können wir auch fein auto machen. alle compilerbauer, die es nicht sofort perfekt hinkriegen, machen mehrfachen code. und wir geben ihnen 10 jahre, es fertigzubringen, daß sie den code auch zusammenfassen. und wir kündigen das jetzt an. wir sagen "static-variablen in funktionen, die auto zurückgeben können aber müssen nicht mehrfach sein" und "funnktionszeiger von fun... sein" und "in 10 jahren dürfen sie nicht mehr merhfach sein". wo ist das problem?

Hast ja recht, im Prinzip gibt's keins, wenn man es wie besprochen handhabt.