Skepsis am neuen Standard

[Phoemuex]

Dravere schrieb:

3. Das war aber schon immer möglich, auch mit dem jetzigen Standard:

template<typename T>
T create_copy(T const& obj)
{ return T(obj); }

Und wie mache ich damit jetzt etwas, das zu

class 
{ 

} Object; 

decltype(Object) Object2;   // !!!

äquivalent ist?

Felix

[Nexus]

asc schrieb:

Meiner Meinung nach nur redundant, aber nicht zwangsweise unnötig. Ich finde das die Weiterleitung von Konstruktoren zwar nicht verkehrt ist, aber nicht unbedingt übersichtlicher ist.

Ich finde die Weiterleitung von Konstruktoren eine gute Sache. Immerhin sieht man dann noch, welcher Konstruktor aufgerufen wird und kann bei dem die Initialisierung überprüfen. Codeduplizierung kann damit auch stark eingeschränkt werden.

Und wie du sagst, redundant. Die Sprache gewinnt nicht unbedingt etwas, wenn man ein Problem auf mehrere Arten angehen kann. Vor allem nicht, wenn sich die bisherigen Vorgehensweisen bewährt haben...

Phoemuex schrieb:

Und wie mache ich damit jetzt etwas, das zu [...] äquivalent ist?

Er meinte wohl eher, dass man auch ohne decltype an den Datentyp von anonymen Typen kommen kann.

[aaaüüüüüb]

Dravere schrieb:

Tippgeber schrieb:

Initialisierung von Member-Variablen direkt in der Klassendefinition ist doch eine tolle Sache, so kann man sich Code-Duplizierung ersparen, denn im Gegensatz zu deinem ersten Posting gibt es nicht den Konstruktor.

asc schrieb:

Thema Initialisierung innerhalb der Klassendeklaration
Finde ich dann wirklich gut, falls eine Klasse mehrere Konstruktoren hat, und einige der Daten jedesmal gleich sind.

Meiner Meinung nach unnötig, weil es im neuen Standard nun DEN Konstruktor geben kann. Man kann schliesslich zu einem anderen Konstruktor weiterleiten.

Wie sieht das dann aus, wenn man z.B. 2 Konstruktoren mit unterschiedlichen Parametern hat? Muss man dann noch einen ohne Parameter schreiben und an den weiterleiten?

[audacia]

Nexus schrieb:

Auch an den neuen Schlüsselworten auto und decltype zweifle ich ein wenig. Ich habe das Gefühl, die werden sehr oft zur Schreibfaulheit missbraucht werden. Klar gibt es Kontexte, in denen sie sinnvoll sein können, aber bei einfacheren Ausdrücken halte ich es nicht für vorteilhaft, wenn man sich den Typ auch nicht mehr merken muss. Was ich besonders schlimm finde, ist die Tatsache, dass anonyme Typen ihre Anonymität verlieren.

class
{

} Object;

decltype(Object) Object2;   // !!!

Die Gefahr für eine mißbräuchliche Verwendung von auto sehe ich im Einklang mit den meisten hier als sehr überschaubar an; es wird mir bei der Verwendung der STL-Container aber einiges an Schreibarbeit ersparen. Noch wesentlicher ist es, glaube ich, bei diversen Boost-Bibliotheken, die unausschreibbar perverse Typen erzeugen können.

Und die wesentliche Neuerung bei decltype ist, daß damit nicht nur für Funktions-, sondern auch für Klassentemplates Typen automatisch deduziert werden können. Dein anonymer Typ kann, wie ja schon gesagt wurde, auch heute schon ohne weiteres in einem Funktionstemplate zu einem konkreten Typen werden, und mit decltype dann eben auch in einem Klassentemplate.

Viel bedauerlicher finde ich, daß sich das Standardkomitee vor allem ausführlicherer RTTI (in diesem Zusammenhang auch Properties) und objektgebundenen Methodenzeigern verweigert. Und niemand erzähle mir etwas von "in C++ bezahlt man nur, was man braucht" - erstens ist das idealistisches Wunschdenken und heute schon längst nicht mehr Realität (Template-Bloat, Exceptions), zweitens wäre es ohne Probleme möglich, RTTI zur standardmäßig deaktivierten Option zu machen.
Zugegebenermaßen ist es jetzt für die Einführung von RTTI viel zu spät, da es schon zu viele inkompatible Nischenlösungen gibt (z.B. in C++Builder oder C++/CLI); das Komitee ist einfach zu unbeweglich. Ein weiteres schönes Beispiel sind Attribute: so nützlich sie in der Theorie sein können, sie werden praktisch wertlos bleiben, weil Microsoft sie (IIRC aufgrund der Überschneidungen mit der COM-Annotationssyntax) nicht implementieren wird.

Natürlich habe ich auch bei den beschlossenen Neuerungen einiges zu mäkeln
Meine Top 3:

• R-value references/move semantics. Ich bezweifle nicht deren Notwendigkeit, aber die Ursache dieser Notwendigkeit halte ich für einen grundlegenden Sprachdefekt.
• Concepts. Auch hier anerkenne ich die Nützlichkeit, halte es aber für grob fahrlässig, so etwas in den Standard zu schreiben, ohne zunächst die Umsetzbarkeit verifiziert zu haben - derselbe Fehler wie seinerzeit bei export template . (ConceptGCC ist ein nettes Experiment, aber nicht eben ein Indiz für effiziente Implementierbarkeit.)
• Grausamkeiten beim Keyword-Recycling: sizeof für die Anzahl der Argumente bei Variadic Templates, enum class , = default und = delete .

Abschließend muß ich noch einem Statement hier im Thread mit äußerstem Nachduck widersprechen:

Dravere schrieb:

Etwas allgemeines noch. Ich verstehe nicht, was die Leute gegen die neuen Features des Standards haben. Wenn sie sich am Ende als schlecht herausstellen, dann werden sie auch nicht verwendet werden.

Alles, was geht, wird auch verwendet. Es ist schön, wenn du fähig bist, untaugliche Dinge zu erkennen und nicht einzusetzen, aber solange du dich mit "umfassenden Kenntnissen in C++" bewerben können willst, mußt du sie allesamt nicht nur lesen, sondern auch beherrschen können - denn du wirst ja in den meisten Jobs nicht nur Code schreiben, sondern vor allem auch warten müssen, unabhängig davon, ob dein Vorgänger auf denselben ästhetischen Grundlagen arbeitete.

Das ist eines der wesentlichen Probleme der Sprache: wenn das so weitergeht, wird man Einarbeitungszeit in der Größenordnung einer Promotion aufwenden müssen, um C++ umfassend beherrschen zu können.

[Dravere]

audacia schrieb:

Concepts. Auch hier anerkenne ich die Nützlichkeit, halte es aber für grob fahrlässig, so etwas in den Standard zu schreiben, ohne zunächst die Umsetzbarkeit verifiziert zu haben - derselbe Fehler wie seinerzeit bei export template . (ConceptGCC ist ein nettes Experiment, aber nicht eben ein Indiz für effiziente Implementierbarkeit.)

Wobei die Frage natürlich auch offen steht, wer alles bei ConceptGCC mitgearbeitet hat und wie stark bisher die investierte Zeit war. GCC war meiner Meinung nach bisher noch nie ein Indiz von Effizienz

audacia schrieb:

Dravere schrieb:

Etwas allgemeines noch. Ich verstehe nicht, was die Leute gegen die neuen Features des Standards haben. Wenn sie sich am Ende als schlecht herausstellen, dann werden sie auch nicht verwendet werden.

Alles, was geht, wird auch verwendet. Es ist schön, wenn du fähig bist, untaugliche Dinge zu erkennen und nicht einzusetzen, aber solange du dich mit "umfassenden Kenntnissen in C++" bewerben können willst, mußt du sie allesamt nicht nur lesen, sondern auch beherrschen können - denn du wirst ja in den meisten Jobs nicht nur Code schreiben, sondern vor allem auch warten müssen, unabhängig davon, ob dein Vorgänger auf denselben ästhetischen Grundlagen arbeitete.

Das ist eines der wesentlichen Probleme der Sprache: wenn das so weitergeht, wird man Einarbeitungszeit in der Größenordnung einer Promotion aufwenden müssen, um C++ umfassend beherrschen zu können.

Also dies würde ich nicht als Problem des neuen Standards sehen. Es ist ja bereits so, dass C++ extrem komplex ist und eine Menge Zeit braucht, bis man die Sprache "umfassend" kennt. Die "paar Neuerungen" im Standard, kann man sicher noch dazulernen.
Meiner Meinung nach ist das eher ein Schwachpunkt der Sprache an sich und vielleicht indirekt dann ein Schwachpunkt des neuen Standards. Die Sprache wurde nicht vereinfacht, sondern verkompliziert.
Irgendjemand in dem Forum hat mal gesagt, dass ein "Cut" nicht schlecht gewesen wäre. Der Meinung bin ich heute inzwischen auch. Gewisse Dinge wirklich rauswerfen oder brechen und mit dem bisherigen Wissen probieren besser zu machen. Oder auch einfach Dinge vereinheitlichen, damit man es nicht auf X verschiedene Arten machen kann. Die Sprache strikter machen.
Anstatt sie rauszuschneiden, könnte man die Sachen auch als veraltet Kennzeichnen und so probieren erst beim nächsten Standard (wohl in 10 Jahren) die Sachen rauszuschneiden.

Ansonsten volle Zustimmung audacia.

Grüssli

[Nexus]

aaaüüüüüb schrieb:

Wie sieht das dann aus, wenn man z.B. 2 Konstruktoren mit unterschiedlichen Parametern hat? Muss man dann noch einen ohne Parameter schreiben und an den weiterleiten?

Ich bin mir jetzt nicht ganz sicher, aber stelle mir das etwa so vor (ich weiss, blödes Beispiel, aber um das Prinzip zu zeigen, sollte es reichen):

class MyClass
{
    public:
        MyClass(int a, float b) : m_a(a), m_b(b)
        {
        }

        MyClass(int a) : MyClass(a, 2.5f * a + 3.f)
        {
        }

        MyClass() : MyClass(0)
        {
        }

    private:
        int m_a;
        float m_b;
};

audacia schrieb:

Die Gefahr für eine mißbräuchliche Verwendung von auto sehe ich im Einklang mit den meisten hier als sehr überschaubar an; es wird mir bei der Verwendung der STL-Container aber einiges an Schreibarbeit ersparen. Noch wesentlicher ist es, glaube ich, bei diversen Boost-Bibliotheken, die unausschreibbar perverse Typen erzeugen können.

Und die wesentliche Neuerung bei decltype ist, daß damit nicht nur für Funktions-, sondern auch für Klassentemplates Typen automatisch deduziert werden können. Dein anonymer Typ kann, wie ja schon gesagt wurde, auch heute schon ohne weiteres in einem Funktionstemplate zu einem konkreten Typen werden, und mit decltype dann eben auch in einem Klassentemplate.

Da hast du Recht. Wie angetönt kann ich gut nachvollziehen, dass decltype und auto manchmal sehr praktisch sein sollen. Nur befürchte ich, dass man sehr schnell zur Übertreibung tendiert. Klar, kein auto und typedef wäre auch nicht besser. Aber es birgt eben schon Gefahren.

Was die RTTI betrifft, habe ich nicht ganz verstanden, was du damit aussagen willst, aber zugegebenermassen kenne ich mich damit nicht allzu gut aus. Geht es um typeid ? Falls ja, warum "standardmässig deaktiviert"? Das hängt ja vom Compiler ab, nicht von der Sprache (sorry, falls ich das Thema total verfehlt habe...)

audacia schrieb:

Natürlich habe ich auch bei den beschlossenen Neuerungen einiges zu mäkeln
Meine Top 3:

Ja, vor allem das Recycling finde ich auch ganz schlimm (am schlimmsten das = delete ). Ich bezweifle, dass die Tatsache, dass weniger Schlüsselwörter existieren, den Lernprozess vereinfacht. Von der Schönheit ganz zu schweigen. Aber es gibt einen Lichtblick, vielleicht kommen ja Makros wieder in den Trend...

audacia schrieb:

Das ist eines der wesentlichen Probleme der Sprache: wenn das so weitergeht, wird man Einarbeitungszeit in der Größenordnung einer Promotion aufwenden müssen, um C++ umfassend beherrschen zu können.

Das Problem besteht auch darin, dass sehr viele Neuerungen des Standards nur den Zweck haben, falsches Design gerade zu biegen. Das trägt natürlich enorm zum Umfang und zur zunehmenden Unübersichtlichkeit der Sprache bei.

Dravere schrieb:

Irgendjemand in dem Forum hat mal gesagt, dass ein "Cut" nicht schlecht gewesen wäre. Der Meinung bin ich heute inzwischen auch. Gewisse Dinge wirklich rauswerfen oder brechen und mit dem bisherigen Wissen probieren besser zu machen. Oder auch einfach Dinge vereinheitlichen, damit man es nicht auf X verschiedene Arten machen kann. Die Sprache strikter machen.
Anstatt sie rauszuschneiden, könnte man die Sachen auch als veraltet Kennzeichnen und so probieren erst beim nächsten Standard (wohl in 10 Jahren) die Sachen rauszuschneiden.

Ja, definitiv. C++ hat schon eine lange Zeit und viele Überarbeitungen hinter sich. Vor allem was Vereinheitlichung angeht, kann ich zustimmen. Anstatt dass gewisse Spracheigenschaften direkt verbessert werden, kommen einfach neue Alternativen dazu.

Naja, Abwärtskompatibilität stand dem Fortschritt schon viel zu oft im Weg...

[audacia]

Nexus schrieb:

Was die RTTI betrifft, habe ich nicht ganz verstanden, was du damit aussagen willst, aber zugegebenermassen kenne ich mich damit nicht allzu gut aus. Geht es um typeid ?

Auch das (es wurde hier diskutiert), aber auch weit darüber hinaus wäre RTTI, so wie sie in fast allen aktuellen objektorientierten Hochsprachen existiert, eminent nützlich. Schau dir an, was man in Delphi, Java oder C# alles mit Reflection machen kann. Selbst mit den standardmäßig recht limitierten Reflection-Mechanismen des C++Builder kann man Dinge machen, die in Standard-C++ praktisch nicht umsetzbar sind. Wenn man zusätzlich noch Parameterinformationen für Methoden hat (das läßt sich in C++Builder durch das Ableiten von IInvokable aktivieren), wird es wunderbar einfach, RPC-Mechanismen wie SOAP zu benutzen, automatisch IDispatch-Interfaces bereitzustellen oder Skriptsprachen einzubinden (siehe z.B. hier und hier).

Nexus schrieb:

Falls ja, warum "standardmässig deaktiviert"?

Damit niemand hier auf die Idee kommt, einzuwenden, in C++ müsse man eben nur bezahlen, was man auch wirklich braucht.

[knivil]

Halbwahrheiten und sonstiges kommt ja hier zum Vorschein ... Rtti laesst sich deaktivieren, nur darf man dann kein dynamic_cast oder exceptions benutzen. Exceptions lassen sich deaktivieren. Besseres Rtti gibt es ueber Bibliotheken fuer C++. template bloat etc. sind nur Schlagworte. Und Rtti habe ich noch nie wirklich gebraucht.

Desweiteren muss man nicht alles mit C++ machen. The right tool for the right problem. Dann nimmt man halt nicht C++ wenn man sowas braucht.

[Shade Of Mine]

Nexus schrieb:

Da hast du Recht. Wie angetönt kann ich gut nachvollziehen, dass decltype und auto manchmal sehr praktisch sein sollen. Nur befürchte ich, dass man sehr schnell zur Übertreibung tendiert. Klar, kein auto und typedef wäre auch nicht besser. Aber es birgt eben schon Gefahren.

Es gibt ganze Sprachen die streng typisiert sind und man nie einen typen angeben muss. absolut top. der typ interessiert nämlich sowieso nie.

[audacia]

knivil schrieb:

Halbwahrheiten und sonstiges kommt ja hier zum Vorschein ... Rtti laesst sich deaktivieren, nur darf man dann kein dynamic_cast oder exceptions benutzen.

RTTI läßt sich nicht deaktivieren. Man kann höchstens darauf hoffen, daß der Linker in der Lage ist, sie wegzulassen (und bei polymorphen Klassen ist er das nicht). Halbwissen, anyone?

knivil schrieb:

Exceptions lassen sich deaktivieren.

Nicht ohne ein speziell angepaßtes Build der RTL. Du kannst zwar auf ihre Verwendung verzichten, aber das ändert nichts daran, daß der Startup-Code und terminate() einen try/finally-Block enthalten, was impliziert, daß der ganze Exception-Handling-Mechanismus dazugelinkt werden muß.

knivil schrieb:

Besseres Rtti gibt es ueber Bibliotheken fuer C++.

Es gibt fast für alles eine Bibliothek für C++. Doch ist es ein verbreiteter Irrglaube, Bibliotheken könnten oder sollten alle Sprachfeatures ersetzen. Ansonsten zeige mir bitte, wie du mit so einer Bibliothek z.B. ein Dispinterface für ein bereits bestehendes Interface generierst.

knivil schrieb:

template bloat etc. sind nur Schlagworte.

Ich konkretisiere das gerne für dich. Boost.Regex beispielsweise ist vollständig in Headerdateien implementiert - primär, damit man einen beliebigen Char-Typen angeben kann. Das führt das bei C++ ohnehin nur schwach ausgeprägte Modulkonzept vollends ad absurdum, von den Übersetzungszeiten ganz zu schweigen.

knivil schrieb:

Und Rtti habe ich noch nie wirklich gebraucht.

Das spricht gegen deinen Horizont.
Addendum: Die in C++ verfügbare RTTI beschränkt sich auf das Identifizieren von Typen und die Ausgabe eines mehr oder weniger lesbaren Typnamens primär für Debuggingzwecke. Das hat praktisch nichts mit dem zu tun, was mit der RTTI in Delphi/C++Builder möglich ist, von .NET/Java ganz zu schweigen.

knivil schrieb:

Desweiteren muss man nicht alles mit C++ machen. The right tool for the right problem. Dann nimmt man halt nicht C++ wenn man sowas braucht.

Das sehe und praktiziere ich auch so. Allerdings ist das ein schlechtes Argument, wenn es um die mögliche Verbesserung der Sprache C++ geht.

[knivil]

Bei g++ als auch bei Visual C++ gibt es Kompilerswitches, die Exceptions als auch Rtti deaktivieren. Was tatsaechlich generiert wird, habe ich mir noch nicht in der Executable angesehen

Dispinterface für ein bereits bestehendes Interface generierst

Keine Ahnung was das ist, hab 's bestimmt noch nie gebraucht. Genauso kann ich dir bei der Sprache deiner Wahl (Delphi/C++Builder, .NET/Java) auch sofort die Grenzen aufzeigen. In den anderen Sprachen ist das vielleicht ganz nett, aber es kostet auch. Desweiteren gehts ja wohl schwerlich darum Features aus anderen Sprachen zu uebernehmen, damit dann alles irgendwie Einheitsbrei wird.

Boost.Regex beispielsweise ist vollständig ...

Wenn es dich stoert, nutze was anderes (es gibt genug). Aber mit Codebloat hat es wenig zu tun, da du den Code nicht selbst schreibst. Ausserdem soll's ja sowas wie pre compiled templates geben, k.A. was draus wird. Selbst benutze ich Boost aber kaum, da manches mir sowieso suspekt ist oder einfach unnoetig.

[audacia]

knivil schrieb:

Bei g++ als auch bei Visual C++ gibt es Kompilerswitches, die Exceptions als auch Rtti deaktivieren.

Womit fast sämtlicher C++-Code unbenutzbar wird.
Interessant ist, ob sich RTTI selektiv aktivieren oder deaktivieren läßt; wenn C++ ausführlichere RTTI einführen würde, wäre es problemlos möglich, das nur bei Bedarf spezifisch für eine Klasse zu aktivieren.

knivil schrieb:

Keine Ahnung was das ist

Google hilft.

knivil schrieb:

Desweiteren gehts ja wohl schwerlich darum Features aus anderen Sprachen zu uebernehmen, damit dann alles irgendwie Einheitsbrei wird.

Es geht aber durchaus darum, Features aus anderen Sprachen zu übernehmen, weil sie nützlich und sinnvoll sind. Das wird ja auch gemacht (-> Closures).

knivil schrieb:

Wenn es dich stoert, nutze was anderes (es gibt genug). Aber mit Codebloat hat es wenig zu tun, da du den Code nicht selbst schreibst.

?
Natürlich hat das was damit zu tun. Es bläht den Code in den eingebundenen Headerateien, in meinen Übersetzungsmodulen und oft auch in der fertigen Executable auf.
Außerdem geht es ja nicht spezifisch um Boost.Regex (wie "z.B." eigentlich ausdrückt). Es gibt jede Menge Bibliotheken nach diesem Prinzip. C++ und die Standardbibliothek begünstigen solche Bibliotheken nachdrücklich.

knivil schrieb:

Ausserdem soll's ja sowas wie pre compiled templates geben, k.A. was draus wird.

Falls du export template meinst: vermutlich nichts. Und Precompiled Headers sind lediglich ein Workaround für das konzeptionell defizitäre Modulkonzept von C++; sie machen es erträglicher, sind aber auch nicht ganz unproblematisch. Meine Übersetzungszeiten bei C++-Projekten, die ohne PCHs zu einer Kaffeepause würden, sind auch mit PCHs deutlich höher als die von vergleichbaren Delphi-Projekten. Dabei ist BCC, soweit ich weiß, von den verbreiteten Compilern noch der Schnellste, zudem hat er einen höheren Zeilendurchsatz als der Delphi-Compiler.

knivil schrieb:

Selbst benutze ich Boost aber kaum, da manches mir sowieso suspekt ist oder einfach unnoetig.

Vieles aus Boost ist aber auf dem besten Wege, in der nächsten Revision zum Teil des C++-Standards zu werden. Es ist also keineswegs getan mit "nimm doch etwas anderes, wenns dir nicht paßt". std::string paßt mir auch nicht, aber ich muß ihn trotzdem immer mal wieder verwenden, weil anderer Code das auch tut.

[Nexus]

Shade Of Mine schrieb:

Es gibt ganze Sprachen die streng typisiert sind und man nie einen typen angeben muss. absolut top. der typ interessiert nämlich sowieso nie.

Das sagst du jetzt so. Ich bin aber der Meinung, als Programmierer identifiziert man wichtige Informationen mit dem Typen. Ich kann mir unter std::vector<T, std::allocator<T> > einigermassen etwas vorstellen, und zwar mehr als nur ein Container von T. Klar ist es okay, bis zu einem gewissen Grad zu abstrahieren, das hat man ja jetzt bereits mit typedef .

Aber es gibt auch eine gewisse Sicherheit, den Typen zu kennen - denn die Funktionalität unterscheidet sich meistens deutlich, auch wenn die Schnittstelle mehr oder weniger die gleiche ist. Ich habe vor, im neuen Standard soweit wie möglich auf auto und decltype verzichten, sofern die Übersicht nicht stark darunter leidet.

audacia schrieb:

Boost.Regex beispielsweise ist vollständig in Headerdateien implementiert

Nein, Boost.Regex führt Bibliotheken mit.

audacia schrieb:

Natürlich hat das was damit zu tun. Es bläht den Code in den eingebundenen Headerateien, in meinen Übersetzungsmodulen und oft auch in der fertigen Executable auf.
Außerdem geht es ja nicht spezifisch um Boost.Regex (wie "z.B." eigentlich ausdrückt). Es gibt jede Menge Bibliotheken nach diesem Prinzip. C++ und die Standardbibliothek begünstigen solche Bibliotheken nachdrücklich.

Templates haben eben auch ihren Preis, das hat man dafür in anderen Sprachen nicht. Man muss sie ja nicht exzessiv anwenden, aber sie verleihen einem enorme Möglichkeiten. Dafür bin ich gerne bereit, Kompromisse beim Kompilieren einzugehen. Und wie export gezeigt hat, scheint die Problematik nicht allzu trivial zu sein - was sollte also deiner Meinung nach geändert werden?

[audacia]

Nexus schrieb:

audacia schrieb:

Boost.Regex beispielsweise ist vollständig in Headerdateien implementiert

Nein, Boost.Regex führt Bibliotheken mit.

Ah, tatsächlich. Dann muß ich meine Äußerung natürlich korrigieren: 80% von Boost.Regex befinden sich in Headerdateien.

Nexus schrieb:

Templates haben eben auch ihren Preis, das hat man dafür in anderen Sprachen nicht. Man muss sie ja nicht exzessiv anwenden

Gleiches Argument, gleicher Widerspruch: doch, man muß, weil andere das auch tun, und in der Praxis hast du gewöhnlich nicht den Luxus, nur mit selbstgeschriebenem Code arbeiten zu müssen.

Nexus schrieb:

was sollte also deiner Meinung nach geändert werden?

Templates sind sehr nützlich und haben ihre Berechtigung. Die meisten Anwendungsfälle für Templates hätten sich allerdings mit gut spezifizierten Generics genauso lösen lassen. Und sobald man Generics verwendet, läßt sich export wunderbar implementieren. Man hätte der Sprache eine Menge erspart, wenn man zusätzlich zu Templates so etwas wie Restricted Templates oder eben Generics eingeführt hätte.

[Nexus]

audacia schrieb:

Gleiches Argument, gleicher Widerspruch: doch, man muß, weil andere das auch tun, und in der Praxis hast du gewöhnlich nicht den Luxus, nur mit selbstgeschriebenem Code arbeiten zu müssen.

Das kann gut sein, dazu kenne ich mich ehrlich gesagt zu wenig im professionellen Bereich aus. Aber stellen Templates wirklich ein solches Problem dar? Man kann Instanziierungen in andere Module auslagern und auch vorkompilierte Header helfen enorm bei der Kompilierzeit-Verkürzung. Oder ist die grössere Binary das Hauptproblem? Oder alles zusammen?

Nexus schrieb:

Man hätte der Sprache eine Menge erspart, wenn man zusätzlich zu Templates so etwas wie Restricted Templates oder eben Generics eingeführt hätte.

Aber so was kann man sich ja eigentlich selber basteln, zum Beispiel über void* . Klar ist das nicht der schönste Weg, aber wenigstens etwas in die Richtung. Ich verstehe aber, dass das aufgrund der existierenden Templates, die auch meistens angewandt werden, nicht wirklich eine Alternative darstellt.

[Shade Of Mine]

Nexus schrieb:

Ich bin aber der Meinung, als Programmierer identifiziert man wichtige Informationen mit dem Typen. Ich kann mir unter std::vector<T, std::allocator<T> > einigermassen etwas vorstellen, und zwar mehr als nur ein Container von T. Klar ist es okay, bis zu einem gewissen Grad zu abstrahieren, das hat man ja jetzt bereits mit typedef .

Warum ist es wichtig ob es ein vector<int, std::allocator> oder ein vector<int, my_alloc> oder ein my_vec<int> ist?

Aber es gibt auch eine gewisse Sicherheit, den Typen zu kennen - denn die Funktionalität unterscheidet sich meistens deutlich, auch wenn die Schnittstelle mehr oder weniger die gleiche ist. Ich habe vor, im neuen Standard soweit wie möglich auf auto und decltype verzichten, sofern die Übersicht nicht stark darunter leidet.

Es ist stark typisiert. du kannst also nicht ein vec.run_forrest_run() machen.

auto iter = v.begin();

ist zB super praktisch. wozu muss ich hier extra den typen angeben. mich interessieren die allocatoren doch garnicht, ich will nen iterator haben.

und das ist fast überall so. typen händisch angeben wenn es eh keine wahl gibt, ist sinnloser mehraufwand. es ist ja nicht so als ob es andere typen wären - auto reduziert den wartungsaufwand enorm. da du plötzlich nicht mehr dauernd typedef verwenden musst - sondern einfach auto nimmst.

wenn du mal länger mit type inference gearbeitet hast willst du es nicht mehr missen.

[knivil]

Templates sind Generics. Und den rigerosen Templateeinsatz bei Boost finde ich auch nicht toll. Desweiteren habe ich google benutzt, wurde daraus aber nicht recht schlau.Und zum Thema Closures: das "Feature" hat schon C (und wahrscheinlich jede andere Programmiersprache), aber du erkennst sie vielleicht nicht als Closure.

[audacia]

Nexus schrieb:

Ich verstehe aber, dass das aufgrund der existierenden Templates, die auch meistens angewandt werden, nicht wirklich eine Alternative darstellt.

Das ist der Punkt.

[audacia]

knivil schrieb:

Templates sind Generics.

Nein.

knivil schrieb:

Und zum Thema Closures: das "Feature" hat schon C

Nein.

Wie kommst du dazu, anderen das Verbreiten von Halbwahrheiten anzulasten?

[knivil]

Fuer dich Wikipedia: http://de.wikipedia.org/wiki/Generischer_Typ und http://de.wikipedia.org/wiki/Closure . Objekte koennen Closures sein, Closures koennen Objekte sein.

Wie kommst du dazu, anderen das Verbreiten von Halbwahrheiten anzulasten?

Weil sie anscheinend dahinterstehende Konzepte nicht verstanden haben. Klar ist das Generics aus C# nicht vergleichbar mit denen aus C++, aber es sind doch beides Elemente der generischen Programmierung, Generics.