Erst C oder gleich C++ ???

[u_ser-l]

Man kann nicht C++ ohne C lernen, es sei denn, man will nur eine Teilsprache von C++ lernen.

Wer C++ lernt, lernt automatisch C mit. Schließlich ist erstere eine Spracherweiterung von letzterer.

[~fricky]

~~fricky schrieb:

Eigentlich gar nie, denn new normal muss man kein delete zum new dazu schreiben, da das ungefähr so aussieht:

if (blablubb) {
    boost::scoped_ptr< my_class >( new my_class );
}

^^ warum so eine abgefahrene zeile hinschreiben mit zwei mal 'my_class' darin? kannste nicht 'new' überladen, so dass es sich wie ein 'scoped-new' verhält?

asc schrieb:

Wenn C++ ach soooo schlecht ist, sagt mir mal warum es sich wie C noch immer hält?

es gibt viel suboptimales und veraltetes zeug, das sich hält und hält. es reicht meistens aus, dass es gerade so eben funktioniert.

[asc]

u_ser-l schrieb:

Man kann nicht C++ ohne C lernen, es sei denn, man will nur eine Teilsprache von C++ lernen.

Wer C++ lernt, lernt automatisch C mit. Schließlich ist erstere eine Spracherweiterung von letzterer.

Ich habe nie C gelernt, bin nur durch einige Chaosprojekte auf C gestossen. Die Aussage das man C++ nicht ohne C lernen kann muss also falsch sein. Die einzigen Bestandteile die ich von C nutze ist der Header cmath (for, while etc. sind auch C++, und nicht nur C).

Und C++ ist nicht eine Spracherweiterung von letzterer, sondern eine eigenständige Sprache die ihre Wurzeln zwar in C hat, aber nicht C ist. Zudem sind die Sprachparadigmen unterschiedlich. Selbst wenn ich unter C++ prozedural programmiere, programmiere ich dennoch anders als ich es unter C tuen würde (Alleine schon wegen Verwendung anderer Schlüsselwörter und Bibliotheksfunktionen die teilweise auf anderen Ansetzen basieren).

cu André

[asc]

~fricky schrieb:

^^ warum so eine abgefahrene zeile hinschreiben mit zwei mal 'my_class' darin? kannste nicht 'new' überladen, so dass es sich wie ein 'scoped-new' verhält?

Weil das Prinzip von C++ weiterhin bleibt, das man es sich aussuchen kann. Zudem wäre es Schwachsinn ein new so zu überladen das es sich wie ein "scoped-new" verhält, wenn man es an anderer Stelle auch mit einem shared_ptr etc. einsetzen will.

Flexibilität kostet manchmal etwas, die Mehrkosten in dem Fall sind aber wirklich nur für Schreibfaule relevant.

~fricky schrieb:

es gibt viel suboptimales und veraltetes zeug, das sich hält und hält. es reicht meistens aus, dass es gerade so eben funktioniert.

<ironie>Stimmt, genau darum werden auch neue Projekte noch in C++ (und auch C) begonnen.</ironie>

[~fricky]

asc schrieb:

[
Ich habe nie C gelernt, bin nur durch einige Chaosprojekte auf C gestossen.

soso, C code ist also per default chaotische, ne? dabei hab' ich gestern erst irgendwo gelesen, dass sich der C++ user nicht für die C-wurzeln seiner lieblingssprache schämen sollte.

[Shade Of Mine]

audacia schrieb:

Dafür aber manuelles Speichermanagement. Natürlich kann man sich das mit Smart-Pointern o.ä. vereinfachen - aber das ist auch wieder eine GC-Variante.

wenn raii bei dir unter gc fällt...
dann hat c++ ja einen gc und der artikel ist immernoch falsch.

Oder falls du __closure in C++Builder meinst: das ist eine retrospektiv als unglücklich einzuschätzende Wortwahl, hat aber mit den anonymen Methoden von Delphi 2009, besser bekannt als Closures, nicht das Geringste zu tun.

nein, ich meine die closures aus dem neuen c++ standard

Was auch immer. Das komplette "Jedes struct ist jetzt eine Klasse" inklusive aller Implikationen, eine davon z.B. Default-, Kopierkonstruktor und Zuweisungsoperator für alle Klassen, ist ein gewaltiger Designfehler - IMHO.

begründung?
weil value semantik schlecht ist?

Shade Of Mine schrieb:

der artikel ist doof

Du bist unqualifiziert.

value semantik ist schlecht - und dennoch sagt der artikel dass einige sachen ohne value semantik ja garnicht schön möglich sind.

du kannst referenz semantik mit hilfe von value semantik total easy simulieren. du kannst aber mit referenz semantik keine value semantik simulieren.

ergo ist value semantik essentiell.
schau dir java an: du tust dauernd clone aufrufen und was ist das erste was man einem java programmierer beibringt? finger weg von clone. weils ein käse ist.

ja, reine referenz semantik ist wahnsinnig toll.

Shade Of Mine schrieb:

das ist eine zusatz information die delete nicht braucht -> du sparst performance

Abstrus.

Der tatsächliche Grund dürfte sein, daß new[] erst nach new eingeführt wurde und man vermutlich irgendein ABI nicht kaputtmachen wollte.

was hat source code mit ABI zu tun?

und du kannst new effizienter implementieren als new[] - ist einfach so.
ob das jetzt relevant ist oder nicht sei mal dahin gestellt, aber der vc++ hat früher zB ein new als new[1] implementiert und ist später davon weggegangen.

[u_ser-l]

asc schrieb:

Ich habe nie C gelernt,

doch, hast Du. Und zwar implizit durch Mitlernen im Rahmen von C++

Wenn man von C++ alles herausnimmt, was von C stammt, kann man nicht einmal

int main(){; }

schreiben, denn sowohl int als auch die Funktionsschreibweise mit (){...} und Semikolon stammen von C.

Nur weil man in "reinem" C++ (was immer das auch sein mag) die stdlib nicht benutzt und Zeiger durch Referenzen ersetzt (und noch ein paar andere C-Spezialitäten vermeidet, wenn möglich), heißt das doch nicht, daß man damit kein C mehr benutzt.

asc schrieb:

Und C++ ist nicht eine Spracherweiterung von letzterer,

Doch, und zwar von C90. Ist doch nichts Schlimmes daran, oder ? C ist ja auch ein portabler Assembler, na und ? Beides (C++ als OO-Spracherweiterung von C, und C als portabler Assembler) macht C und C++ zu unverzichtbaren Werkzeugen mit Alleinstellungsmerkmalen. Gut so.

Grüße

[audacia]

Shade Of Mine schrieb:

wenn raii bei dir unter gc fällt...
dann hat c++ ja einen gc und der artikel ist immernoch falsch.

Nö. Er sagt ja nicht, daß es unmöglich wäre. Aber um effizient Daten an Closures weiterzugeben, muß man Smart-Pointer (oder natürlich den neuesten Versuch, den ursprünglichen Designfehler erträglicher zu machen, nämlich die Move-Semantik) bemühen, also einen mehr oder weniger manuellen GC-Mechanismus. In einer Umgebung mit GC gehts einfach so.

Shade Of Mine schrieb:

Was auch immer. Das komplette "Jedes struct ist jetzt eine Klasse" inklusive aller Implikationen, eine davon z.B. Default-, Kopierkonstruktor und Zuweisungsoperator für alle Klassen, ist ein gewaltiger Designfehler - IMHO.

begründung?
weil value semantik schlecht ist?

Barry Kelly schrieb:

Thing is, writing correct value types is far harder than writing correct Java-style types, and C++ has some features that seem to make value types the default.
...
But when did common domain objects like Person, Car and Account ever need to act like integers, freely copyable and duplicated hither and thither?

Shade Of Mine schrieb:

ergo ist value semantik essentiell.
schau dir java an: du tust dauernd clone aufrufen und was ist das erste was man einem java programmierer beibringt? finger weg von clone. weils ein käse ist.

ja, reine referenz semantik ist wahnsinnig toll.

Für die spreche weder ich noch er. Aber eine saubere Trennung wäre einiges wert gewesen.

Shade Of Mine schrieb:

was hat source code mit ABI zu tun?

Um delete so abzuändern, daß es auch Arrays freigeben müßte, hätte die Metainformation, die new vor dem Speicherblock unterbringt, erweitert werden müssen => ABI-Inkompatibilität. Beim Linken älterer Module kann das relevant sein. (Allerdings bin ich nicht der Auffassung, daß das ein Hinderungsgrund hätte sein müssen.)

Shade Of Mine schrieb:

und du kannst new effizienter implementieren als new[] - ist einfach so.

Ist ja okay - dagegen hat ja niemand etwas. Aber was spricht gegen das hier:

template <typename T>
    void pseudoHighLevelDelete (T* data)
{
    if (!data)
        return;
    if (((unsigned*) data)[-1] == 0) // etwa drei ASM-Instruktionen mehr
        data->~T ();
    else
        for (unsigned i = ((unsigned*) data)[-1]; i > 0; --i)
            (data++)->~T ();
    std::free (data);
}

?

asc schrieb:

Ich habe nie C gelernt

Dann wirds ja höchste Zeit.

Edit, @Shade: Obige Fragen, warum man throw 1; braucht und inwiefern etwas, das so unausgegoren ist wie std::type_info, nicht unter deine Auffassung von "undurchdacht" fällt, wären auch noch offen. Und bis jetzt habe ich auch noch kein gutes Argument gehört, warum std::type_info::name() nicht einfach aufgeteilt wurde in eine Mangled-Variante (compilerspezifisch, aber maximale Effizienz) und eine standardisierte Demangled-Variante. Und auch, wozu man auf Gleitkommatypen basierende Enumerationen braucht, weiß ich noch nicht.

Alternativ kannst du mir aber gerne drei Aspekte von C++ nennen, die ich nicht verstanden habe.

[Shade Of Mine]

audacia schrieb:

Nö. Er sagt ja nicht, daß es unmöglich wäre. Aber um effizient Daten an Closures weiterzugeben, muß man Smart-Pointer (oder natürlich den neuesten Versuch, den ursprünglichen Designfehler erträglicher zu machen, nämlich die Move-Semantik) bemühen, also einen mehr oder weniger manuellen GC-Mechanismus. In einer Umgebung mit GC gehts einfach so.

boost lambda kommt zB ohne allokationen aus...

move semantik kannst du auch jetzt schon mit mojo haben

warum genau ist value semantik aber ein design fehler?
bedenke: value semantik kann referenz semantik simulieren - umgekehrt geht es nicht.

Thing is, writing correct value types is far harder than writing correct Java-style types, and C++ has some features that seem to make value types the default.
...
But when did common domain objects like Person, Car and Account ever need to act like integers, freely copyable and duplicated hither and thither?

Irrelevant.

Natürlich gibt es pitfalls bei bei value typen - aber auch referenz typen sind nicht pitfall-los. zB hast du enorm viele java klassen die interne handles hergeben.

Shade Of Mine schrieb:

ergo ist value semantik essentiell.
schau dir java an: du tust dauernd clone aufrufen und was ist das erste was man einem java programmierer beibringt? finger weg von clone. weils ein käse ist.

ja, reine referenz semantik ist wahnsinnig toll.

Für die spreche weder ich noch er. Aber eine saubere Trennung wäre einiges wert gewesen.

Besser geht immer, aber warum ist value semantik schlecht?
mächtige features sind oft mit pitfalls verbunden...

deshalb sind sie aber doch nicht schlecht.
schau dir C# an - dort wird value und reference semantik getrennt - ist auch nicht wirklich perfekt.

aber es geht auch nicht um perfektion sondern darum ob es funktioniert. und c++ funktioniert.

Shade Of Mine schrieb:

Um delete so abzuändern, daß es auch Arrays freigeben müßte, hätte die Metainformation, die new vor dem Speicherblock unterbringt, erweitert werden müssen => ABI-Inkompatibilität. Beim Linken älterer Module kann das relevant sein. (Allerdings bin ich nicht der Auffassung, daß das ein Hinderungsgrund hätte sein müssen.)

ich finde die trennung nicht störend und es bringt wie du gesagt hast ja auch performance.
also wo genau ist das problem?

anders geht immer. aber damit wird kein problem gelöst, denn new/new[] ist kein problem.

der new operator ruft übrigens den operator new auf - der new operator muss somit _kein_ bookkeeping machen, während der new[] operator sehr wohl eins machen muss.

da ich die new operatoren aber selber definieren kann, ist es schwer hier zu optimieren ohne 100 sonderfälle zu betrachten.

das ganze ist zB dann relevant, wenn du fixed size allokationen hast - dann hast du 0 bookkeeping und nur der new[] operator muss bookkeeping machen.

[Shade Of Mine]

audacia schrieb:

Edit, @Shade: Obige Fragen, warum man throw 1; braucht

Warum sollte es verboten werden?

ich mag nunmal auch einen zeiger werfen können (siehe MFC) und das macht manchmal ja auch sinn. und wenn ich zeiger werfen darf, dann wird es plötzlich sehr komisch wenn ich restrikte was für zeiger ich werfen darf.

ich sehe keinen sinn einer restriktion. welchen vorteil habe ich, wenn ich verbiete zeiger zu werfen?

das so unausgegoren ist wie std::type_info, nicht unter deine Auffassung von "undurchdacht" fällt, wären auch noch offen.

weil es so funktioniert wie es gedacht ist.
es könnte besser sein, aber ja, so ziemlich alles könnte besser sein.

name() funktioniert: du kannst es verwenden um eine readable form des typs zu bekommen - die genaue form ist ID. wenn deine implementation es schlecht definiert, jo mei.

Alternativ kannst du mir aber gerne drei Aspekte von C++ nennen, die ich nicht verstanden habe.

exceptions, value semantik und new

[C bleiber]

Erst C oder gleich C++ ???

Back to topic:

1. Ja, erst C lernen.
2. Und auch bei C bleiben.

[sdfsdfsdf]

troll

[Bashar]

Shade Of Mine schrieb:

audacia schrieb:

Nö. Er sagt ja nicht, daß es unmöglich wäre. Aber um effizient Daten an Closures weiterzugeben, muß man Smart-Pointer (oder natürlich den neuesten Versuch, den ursprünglichen Designfehler erträglicher zu machen, nämlich die Move-Semantik) bemühen, also einen mehr oder weniger manuellen GC-Mechanismus. In einer Umgebung mit GC gehts einfach so.

boost lambda kommt zB ohne allokationen aus...

Baut man mit boost lambda etwa Closures? Wie sieht das aus? Wo wird die Umgebung gespeichert?

[Shade Of Mine]

Bashar schrieb:

Baut man mit boost lambda etwa Closures? Wie sieht das aus? Wo wird die Umgebung gespeichert?

kann man machen, ja.

A language implementation cannot easily support full closures if its run-time memory model allocates all local variables on a linear stack. In such languages, a function's local variables are deallocated when the function returns. However, a closure requires that the free variables it references survive the enclosing function's execution. Therefore those variables must be allocated so that they persist until no longer needed. This explains why typically languages that natively support closures also use garbage collection. The alternative is for the language to accept that certain use cases will lead to undefined behaviour, as in the proposal for lambda expressions in C++.

[squidward]

topic --> out off topic --> out out off topic ... => in future meinungsverschiedenheiten zwischen programmierer

greetz!

[audacia]

Shade Of Mine schrieb:

ich sehe keinen sinn einer restriktion. welchen vorteil habe ich, wenn ich verbiete zeiger zu werfen?

Einheitlichen Exception-Typen, unproblematischeres Dispatching. Überhaupt Einheitlichkeit. Ein gewisser Zwang dahingehend, Exceptions mit sinnvollen Fehlermeldungen zu werfen (weil die leichteste Variante, eine Exception zu werfen, dann nicht mehr throw 1; , sondern throw std::runtime_error ("array index out of bounds"); ist). Und weniger Typinformation für Basistypen in der Executable, deutlich geringeren Aufwand auf der RTL-Seite.

Um deine Frage erneut gegen dich selbst zu wenden: wozu braucht man throw 1; ?

Shade Of Mine schrieb:

aber es geht auch nicht um perfektion sondern darum ob es funktioniert. und c++ funktioniert.

Achso, sobald wir also über ein paar konkrete ("undurchdachte") Schwachstellen reden, gehts nur noch darum, daß es funktioniert
Machst du es dir nicht ein bißchen einfach?

Shade Of Mine schrieb:

wenn deine implementation es schlecht definiert, jo mei.

?

Shade Of Mine schrieb:

exceptions, value semantik und new

Nicht auch std::type_info?

Shade Of Mine schrieb:

Wikipedia schrieb:

A language implementation cannot easily support full closures if its run-time memory model allocates all local variables on a linear stack. In such languages, a function's local variables are deallocated when the function returns. However, a closure requires that the free variables it references survive the enclosing function's execution. Therefore those variables must be allocated so that they persist until no longer needed. This explains why typically languages that natively support closures also use garbage collection. The alternative is for the language to accept that certain use cases will lead to undefined behaviour, as in the proposal for lambda expressions in C++.

Interessanterweise ist genau das der Hintergrund meiner (und Barrys) Argumentation. Irgendwie willst du es nur nicht verstehen. Denn der Artikel ist ja Käse.

[asc]

~fricky schrieb:

asc schrieb:

[
Ich habe nie C gelernt, bin nur durch einige Chaosprojekte auf C gestossen.

soso, C code ist also per default chaotische, ne?

Nein, aber wenn du es so lesen willst ist das dein Bier.

C, wenn es einheitlich und in dessen Sprachparadigmen geschrieben ist, ist nicht chaotisch. C++ aber das bunt zwischen Sprachen (C und C++) und deren Paradigmen hin und her mischt, ist dies aber. Am schönsten sind noch Sachen wie Mischen von malloc/delete oder new/free, oder free grundsätzlich auf alle Arrays...

Ich habe nichts gegen C, ich habe aber etwas gegen:
a) C-Programmierer die nur über C++ meckern (Ich verlange nicht das man C++ mag, ich bin nur gegen das generelle C++ ist Sch****...). Ich hasse persönlich beispielsweise VB, dennoch akzeptiere ich das es VB gibt, und das es auch Gründe für VB gibt. Ich werde VB niemals mögen, das war es schon. Jede Sprache hat ihre Vorteile und Macken (sei es C, C++, Java, C#...) und jede Sprache (außer vielleicht sowas wie Brainfuck) hat ihr Sinn und ihre Einsatzgebiete.

b) Programmierer die sich C++ Programmierer nenne, die aber teilweise widersprüchliche Sprachparadigmen mischen und eher schlechtes C mit ein wenig Ausnutzen der C++ Syntax. Ja, ich schimpfe auf C-Konzepte - aber vorwiegend im C++ Kontext.

~fricky schrieb:

dabei hab' ich gestern erst irgendwo gelesen, dass sich der C++ user nicht für die C-wurzeln seiner lieblingssprache schämen sollte.

Mal ganz davon abgesehen das C++ nicht meine Lieblingssprache ist, schäme ich mich nicht dafür das C++ von C abstammt. Ich habe nur etwas dagegen wenn man meint das weil C++ seine Wurzeln in C hat, auch 30 Jahre nach Entstehung, C++ nur ein Sprachaufsatz auf C wäre. C++ hat eigene Paradigmen angenommen. C++ wird anders als C programmiert.

Ich sehe C++ auch - in größeren Projekten - als wartbarer als C an (Teilweise durch OO und generische Programmierung). Dazu muss man aber auch sagen, das die kleinsten Projekte an denen ich bislang gearbeitet habe in der Größenordnung von etwa 100k+ Codezeilen liegen (Ich glaube das größte waren etwa 10 Mio Codezeilen). Zudem glaube ich das man C++ - wenn man es auf die C++ Art lernt - nicht schwerer zu lernen ist als eine Sprache wie C. Man braucht zwar länger um alle Bereiche zu lernen, aber manches benötigt man auch einfach anfangs nicht, oder nur soweit das man es verwenden, nicht aber Programmieren können muss.

cu André

[asc]

u_ser-l schrieb:

asc schrieb:

Ich habe nie C gelernt,

doch, hast Du. Und zwar implizit durch Mitlernen im Rahmen von C++

Wenn man von C++ alles herausnimmt, was von C stammt, kann man nicht einmal

int main(){; }

Nach der Definition lernt auch jeder Java und C# Entwickler C.

Und wieder: Ich habe nie C gelernt. Den auch wenn ich C++ Syntaxelemente gelernt habe die in C ihren Ursprung haben, kann ich kein C programmieren. Und der C# Entwickler wird ebenso for, while, int... lernen und kann ebenso kein C-Programmieren. Einige Sprachelemente mögen gleich sein, dennoch kann man damit nicht C programmieren. Für die Programmieren müsste man auch - zumindest maginale - Kenntnisse der Bibliotheken haben. Ich bekomme auf Anhieb noch nicht einmal die Syntax von malloc, free, prinft hin.

u_ser-l schrieb:

...und Zeiger durch Referenzen ersetzt...

Zeiger sind ebenso Sprachbestandteil von C wie auch C++. Damit ist C++ aber noch immer kein C (auch wenn einige meinen das sie mit C-Code und der C-Programmierweise automatisch C++ Programmierer sind, wenn sie einen C++ Compiler verwenden).

cu André

[Shade Of Mine]

audacia schrieb:

Einheitlichen Exception-Typen, unproblematischeres Dispatching. Überhaupt Einheitlichkeit. Ein gewisser Zwang dahingehend, Exceptions mit sinnvollen Fehlermeldungen zu werfen (weil die leichteste Variante, eine Exception zu werfen, dann nicht mehr throw 1; , sondern throw std::runtime_error ("array index out of bounds"); ist). Und weniger Typinformation für Basistypen in der Executable, deutlich geringeren Aufwand auf der RTL-Seite.

Beantworte einfach die Frage und erzähl keine Marketingmärchen:
Warum darf ich nicht objekt und zeiger werfen sondern nur eins von beiden.
auf grund der value semantik muss man dann wohl objekte by value werfen, was aber n bisschen blöd ist wenn man exception chaining machen will.

oder darf ich zeiger werfen und objekte?

restriktionen, restriktionen,....
und das mit weniger typinformationen kapiere ich nicht.

du weisst wie exceptions implementiert sind, oder?

Um deine Frage erneut gegen dich selbst zu wenden: wozu braucht man throw 1; ?

langweilig, hab ich schon beantwortet: nämlich indem ich eine verwendung für T* gezeigt habe.

Shade Of Mine schrieb:

aber es geht auch nicht um perfektion sondern darum ob es funktioniert. und c++ funktioniert.

Achso, sobald wir also über ein paar konkrete ("undurchdachte") Schwachstellen reden, gehts nur noch darum, daß es funktioniert
Machst du es dir nicht ein bißchen einfach?

Perfekte Features existieren nicht. name() kann man verwenden und es funktioniert. die form von name() ist auch standardisiert, nämlich als ID was aus sicht eines reflection system sehr viel sinn macht.

dass ein reflection system nun name() eine passende form geben kann ist dabei recht praktisch. im c++ standard kann man hier nicht viel sinnvoll definieren. da ist jede definition gleich gut - schränkt aber reflection systeme uU ein.

deshalb ist es besser nicht einzuschränken und die form von name() als ID zu definieren.

Shade Of Mine schrieb:

wenn deine implementation es schlecht definiert, jo mei.

?

und deshalb wird die diskussion langweilig...
ID heisst, dass deine implementierung name() frei definieren kann. wenn deine implementierung dies eben so tut dass es dir nicht passt, dann lebe damit oder nimm eine andere. die idee ist, sobald jemand eine sinnvolle verwendung für name() gefunden hat, können die compiler es implementieren und es gibt keine limitierungen.

aktuell bringt dir aber eine standardisierte name() variante nichts, ausser dass es nett aussieht. also wozu limitieren was erlaubt ist?

uU ist es sinnvoll per compiler switch zB name() als den name mangled namen zu definieren oder als ein pretty print, etc.

Shade Of Mine schrieb:

exceptions, value semantik und new

Nicht auch std::type_info?

nein, weil du type_info schon verstanden hast, nur du willst dass es mehr macht. das ist legitim. ich will ja auch dass java first class functions hat. aber das ist jetzt nicht wirklich etwas undurchdachtes in java.

Interessanterweise ist genau das der Hintergrund meiner (und Barrys) Argumentation. Irgendwie willst du es nur nicht verstehen. Denn der Artikel ist ja Käse.

ich verstehe nicht wo das problem liegt.
du kannst problemlos mit shared_ptr arbeiten.
du kannst problemlos _kopien_ ziehen. und du kannst problemlos referenzen ziehen.

das sind features die du bei den meisten closure implementierungen nicht hast.

ergo: wieder mehr features auf der value semantik seite.

[audacia]

Shade Of Mine schrieb:

oder darf ich zeiger werfen und objekte?

Nur Objekte. Du darfst sie auch kopieren.

Shade Of Mine schrieb:

du weisst wie exceptions implementiert sind, oder?

Davon kannst du ausgehen.

Shade Of Mine schrieb:

langweilig, hab ich schon beantwortet: nämlich indem ich eine verwendung für T* gezeigt habe.

Achso, weil das in MFC üblich ist, soll das erlaubt sein?

Shade Of Mine schrieb:

deshalb ist es besser nicht einzuschränken und die form von name() als ID zu definieren.

Könnte ich zustimmen, wenn wir über std::type_info::mangled_name() redeten.
Hier ist es tatsächlich so, wie du sagst: daß ich mir vor allem ein Feature mehr wünsche.

Shade Of Mine schrieb:

aktuell bringt dir aber eine standardisierte name() variante nichts, ausser dass es nett aussieht. also wozu limitieren was erlaubt ist?

Ich kann mir da ein paar nette Anwendungsfälle für z.B. Serialisierung vorstellen.

Shade Of Mine schrieb:

ergo: wieder mehr features auf der value semantik seite.

Ja, _noch_ mehr Features. Mit C++ ist tatsächlich fast alles umsetzbar.
Ob man das aber zur Maxime erklären sollte, finde ich fraglich.