Skepsis am neuen Standard

[Nexus]

Mr X schrieb:

Ich finde, es gibt sinnvolleres zu implementieren als neue Arten der Initialisierung

Ja, das stimmt natürlich, aber wie gesagt beinhaltet der neue Standard sehr viele andere Erweiterungen.

Mr X schrieb:

Dann wird wahrscheinlich vielen Anfängern aus bequemlichkeit das Schlüsselwort auto beigebracht, die es dann blind anwenden und sich über seltsames Verhalten und inkonsistente Typen wundern...

Das befürchte ich eben auch. Meines Erachtens sollte man auto erst anwenden, wenn man in komplexere Gebiete wie Template-Metaprogrammierung oder Ähnliches eindringt, die das Schlüsselwort auch wirklich notwendig machen. Ich bin bisher immer ohne auto und decltype ausgekommen, und werde das wohl auch in Zukunft noch eine Weile...

Mr X schrieb:

Ich fände es erheblich besser, wenn die Standardbibliothek um wichtige, sinnvolle Dinge erweitert würde, z.B. einer Speicherverwaltung ähnlich wie bei C#. Damit könnte C++ ein paar Rückstände gegenüber mancher neuer Programmiersprachen aufholen, ohne seine Vorteile zu verlieren...

Da bin ich nicht einverstanden. C++ hat nicht umsonst den Weg einer manuellen Speicherverwaltung ohne Garbage Collector eingeschlagen. Aber zur wirklich manuellen Verwaltung kommt es sowieso kaum, wenn man Container, Smart Pointer und andere Errungenschaften der RAII einsetzt. Da sehe ich kein Problem.

[knivil]

Speicherverwaltung ähnlich wie bei C#

Gibt es, aber nicht als Sprachfeature sondern als Bibliothek. Ich bin froh, dass C++ noch kein garbage collection hat.

[Gast]

Hallo

Ich kenne den neuen Standard nicht, aber kann ich mir auto wie var in C# vorstellen? Ein "universeller" Datentyp, der anhängig von der Initialiserung ist:

var test = 3 //int
var test = 4f //float

Das ist doch praktisch. Wo sehr ihr da die Nachteile? Bei C# geht das nur bei lokalen Varibalen und damit ist die Übersichtlichkeit auch nicht wirklich eingeschränkt.

chrisce

[Dravere]

@Nexus,
Ich kenne mich zwar nicht mit den Beweggründen aus, aber ich probiere diese mal aus meiner Sicht zu interpretieren.

1. Ich könnte mir gut vorstellen, dass dies mit den Templates zusammenhängt. Damit man eine einheitliche Schreibart hat, egal welcher Typ dahinter liegt. Es wird dir ja nicht Verboten immer noch den Zuweisungsoperator zu verwenden. Ich werde das in Zukunft auch nicht anders machen. Sowas gehört dann eher in Stilfragen hinein.

2. Das ist mir auch nicht ganz klar, was man damit erreichen möchte. Ob der Gedanke dahinter womöglich ist, dass man so einfache Klassen einfach initialisieren kann, ohne zusätzlich einen Konstruktor zu schreiben? Ich weiss es nicht so richtig. Derzeit habe ich nicht vor, von diesem Feature gebrauch zu machen.

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 wenn du willst, dann kannst du dir auch ein Container schreiben, welcher das Objekt hält. Dann den operator -> überladen, um so auf die Methoden und Variablen des Objektes zuzugreifen. auto vereinfacht solche Dinge nur. auto macht wirklich nichts anderes, als zu vereinfachen. Mir ist nicht bekannt, dass auto irgendetwas neues bringt, ausser zu vereinfachen.

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. Nur weil ein neuer Standard kommt und darin vielleicht ein paar Dinge sind, welche einem nicht gefallen, muss es ja nicht heissen, dass nun alles so aussehen wird und alle so programmieren. Auch im jetzigen Standard gibt es viele Dinge, welche nicht verwendet werden, da man es als unschön erachtet.

Das wird sich dann alles mit der Zeit zeigen.

Grüssli

[Tippgeber]

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]

Ich sehe die Sachen - zumindest in Teilen - ein wenig anders.

Thema auto
Beispielsweise sehe ich auto als sehr nützlich an, und ich zähle mich nicht zu den Schreibfaulen. Dennoch liebe ich die Übersichtlichkeit, und gerade bei sehr langen Templateangaben leidet die Übersichtlichkeit enorm, und jedesmal dafür wieder typedefs zu machen, um an einer Stelle beispielsweise eine Schleife in einem Blick erfassen zu können finde ich auch nicht wirklich gut.

Des weiteres kenne ich Firmen in denen ein wesentliches Argument gegen Templates und einige STL-Bestandteile die ewig und drei Tage langen Bezeichner sind. Typedefs können, wenn man sie hier ständig einsetzt, auch nicht wirklich zu einer Lesbarkeit beitragen.

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

@Mr X: Was Speichermanagement angeht, sehe ich es wiederum nicht relevant. Zumindest will ich nicht das was zur Diskussion stand: einen GC den man entweder ganz oder garnicht verwenden kann.

Viel wichtiger würde ich ein einheitliches Speicherlayout ansehen, das zumindest auf einer Umgebung die Unproblematische Übergabe von Objekten ermöglicht. Dies sehe ich persönlich als viel größeres KO-Kriterium bei größeren Projekten an.

[Nexus]

chrische5 schrieb:

Ich kenne den neuen Standard nicht, aber kann ich mir auto wie var in C# vorstellen? Ein "universeller" Datentyp, der anhängig von der Initialiserung ist:

Ja, der Typ wird aus dem initialisierenden Ausdruck abgeleitet.

chrische5 schrieb:

Das ist doch praktisch. Wo sehr ihr da die Nachteile? Bei C# geht das nur bei lokalen Varibalen und damit ist die Übersichtlichkeit auch nicht wirklich eingeschränkt.

Ich sehe darin die Gefahr, dass man mehr und mehr die Übersichtlichkeit über die Typen verliert. Vor allem in der streng typisierten Sprache C++ sehe ich darin nicht nur einen Fortschritt. Gerade bei eingebauten Datentypen wäre auto das Letzte, was ich einsetzen würde!

Dravere schrieb:

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

Stimmt, daran habe ich gar nicht gedacht. Dann ist das Prinzip der anonymen Typen schon seit Jahrzehnten ausgehebelt!

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. Nur weil ein neuer Standard kommt und darin vielleicht ein paar Dinge sind, welche einem nicht gefallen, muss es ja nicht heissen, dass nun alles so aussehen wird und alle so programmieren. Auch im jetzigen Standard gibt es viele Dinge, welche nicht verwendet werden, da man es als unschön erachtet.

Das wird sich dann alles mit der Zeit zeigen.

Ja, aber grundsätzlich ermöglicht alles, was die Sprache bietet, einen neuen Programmierstil. Nicht, dass ich jetzt Angst hätte, dass das schöne C++ von Barbaren übernommen wird.

Aber mich interessiert es eben schon, welche Ideen dahinter stecken, denn momentan sehe ich besonders in der Klassendefinitions-Initialisierung keinen Vorteil.

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.

Aber gerade mit der Möglichkeit, Konstruktoren zu delegieren, sollte das doch nicht wirklich etwas ausmachen? Bei mir unterscheiden sich die Konstruktoren auch meistens derart, dass nicht wirklich von Codeduplizierung die Rede sein kann. Und ich finde es schöner, wenn man in der Initialisierungsliste alle Member aufgelistet sieht, anstatt dass man herausfinden muss, welche fehlen, und diese in der Klassendefinition nachschlägt. Ich schreibe zum Beispiel auch oft Standardkonstruktoraufrufe in die Initialisierungsliste, auch wenn sie nicht nötig wären.

[Gast]

Hallo

Nexus schrieb:

Ich sehe darin die Gefahr, dass man mehr und mehr die Übersichtlichkeit über die Typen verliert. Vor allem in der streng typisierten Sprache C++ sehe ich darin nicht nur einen Fortschritt. Gerade bei eingebauten Datentypen wäre auto das Letzte, was ich einsetzen würde!

Ich setze var sehr gerne ich c# ein udn hatte da noch nie Probleme. Da es nur bei lokalen Variablen geht, leidet auch die Übersicht nicht. Des weiteren sollte der Namen der Variable gut sein. Dann hilft einem auch die IDE. Ich sehe da gar kein Problem. Gerade bei eingebauten Datentypen oder Dicitionary in Schleifen wirklich sehr praktisch.

chrische

[Dravere]

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.

Den einzigen Einsatz sehe ich wirklich nur in sehr kleinen PODs.

asc schrieb:

Viel wichtiger würde ich ein einheitliches Speicherlayout ansehen, das zumindest auf einer Umgebung die Unproblematische Übergabe von Objekten ermöglicht. Dies sehe ich persönlich als viel größeres KO-Kriterium bei größeren Projekten an.

Wieso haben sie es eigentlich diesmal wieder nicht hinbekommen? Bei C hat man es ja auch geschafft, wieso also nicht auch in C++? Sowas fände ich extrem wichtig, das würde die Verbreitung von C++ extrem steigern. Vieles auch vereinfachen, wenn man über die Grenze hinaus arbeitet.

Nexus schrieb:

Ich sehe darin die Gefahr, dass man mehr und mehr die Übersichtlichkeit über die Typen verliert. Vor allem in der streng typisierten Sprache C++ sehe ich darin nicht nur einen Fortschritt. Gerade bei eingebauten Datentypen wäre auto das Letzte, was ich einsetzen würde!

Ich glaube das hat dir Shade Of Mine auch schon mal gesagt:
Der Typ ist unwichtig und interessiert den Programmierer meistens nicht. Was wichtig beim Typ ist, sind nur seine Konzepte, welche er unterstützt. Deshalb sind die Concepts und Conceptmaps etwas ganz wichtiges im neuen Standard oder sagen wir besser unteranderem

Nexus schrieb:

Aber mich interessiert es eben schon, welche Ideen dahinter stecken, denn momentan sehe ich besonders in der Klassendefinitions-Initialisierung keinen Vorteil.

Muss ich zustimmen, die genauen Beweggründe würden mich auch mal interessieren. Wäre lustige wenn das irgendwo als Zusammenfassung zur Verfügung stehen würde. Nur knapp in ein paar Stichwörter. Wäre wirklich sehr interessant zu lesen.

Grüssli

[asc]

Dravere schrieb:

asc schrieb:

Viel wichtiger würde ich ein einheitliches Speicherlayout ansehen, das zumindest auf einer Umgebung die Unproblematische Übergabe von Objekten ermöglicht. Dies sehe ich persönlich als viel größeres KO-Kriterium bei größeren Projekten an.

Wieso haben sie es eigentlich diesmal wieder nicht hinbekommen? Bei C hat man es ja auch geschafft, wieso also nicht auch in C++? Sowas fände ich extrem wichtig, das würde die Verbreitung von C++ extrem steigern. Vieles auch vereinfachen, wenn man über die Grenze hinaus arbeitet.

Wohl weil dazu der Standard deutlich genauer werden müsste, aber es steht soviel ich weiß auf der Liste des TR2 (wobei ich annehme das dieses Feature nicht in meiner aktiven C++ Zeit kommen wird - und zumindest die nächsten Jahre scheint es beruflich bei C++ zu bleiben). Ich rechne einfach nicht damit. Dies ist einer von zwei wesentlichen Gründen warum ich zumindest privat eher C# verwende.

cu André

[asc]

Dravere schrieb:

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

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.

[C++-Progger, ein]

Warum tut das Standardkomitee eigentlich so als würde C++ in einer Luftblase existieren? Es wäre doch allen geholfen, wenn man C++ mit der realen Welt im Hinterkopf entwickeln würde, schließlich will man ja auch dort die Sprache einsetzen.

[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.