Was würdet ihr an C++ verbessern?

ipsec

Nehmen wir an, ihr allein könntet den nächsten C++-Standard entwerfen und müsstet zudem nicht auf Kompitabilität mit den alten Sprachmitteln achten.
Was würdet ihr ändern? Egal, ob es jetzt nur Syntaxänderungen oder radikale Brüche sind. Lediglich das Endergebnis soll noch C++ heißen können.

Ich fang mal an, indem ich ein paar Begriffe in den Raum werfe:

Modulsystem
Arrays sind als Nicht-Typ-Templateparameter zulässig
"automatisch deduzierte Templateparameter". Beispiel (Syntax variabel):

template<auto typename T, T t> struct foo {};
foo<3>();  // T == int
foo<std::sin>();  // T == double(&)(double)

template<auto class T, auto int N, T a[N]> struct bar {};
bar<"Hallo">();  // T == char, N == 6

Umfangreiche Introspection und Reflection zur Compilezeit
Arrays sind First-Class-Values

Die Syntax könnte an fast allen Stellen noch stark verschönert und vereinfacht werden. Sei das die Syntax von Klassen oder die komplette Template-Syntax. Was mich aber so richtig stört, ist die Standardbibliothek. Was mir gerade einfällt:

Von Grund auf neu designte iostream-Lib (performanter, templatiger, ohne <<, transparenter und Zwang auf RAII)
Bessere STL (Ranges anstatt Iteratoren)
Bruch zur C-Library, gescheite Alternativen (bspw. zu cmath)
Mehr standardisierte Systemzugriffe (Prozesse? Dateisystem? usw.)
Integration vieler Boost-Bibliotheken
signals

Das mit den Arrays ist damit
übrigens auch gelöst, weil das perfekte array-Template bereitsteht.
Auch noch ganz wichtig:

Fest definierte Binärschnittstelle

Artchi

An der Syntax würde ich nicht viel ändern. Ich bin sie seit Jahren gewohnt, und da kann sie noch so unschön sein.

Was ich ändern würde:

Modulsystem einführen, damit man endlich die verdammten Headers los werden kann (ich hasse die Dinger wie die Pest)
Typeid soll endlich einen einheitlichen Typnamen liefern (kann doch nicht so schwer sein?)
API-Support, z.B. Tags für deprecated APIs, overwrite usw.
boost::any, boost::filesystem und boost::signals2 in die Standard-Lib

Sonst bin ich ganz zufrieden.

Cefour

Zu

Artchi schrieb:

Typeid soll endlich einen einheitlichen Typnamen liefern (kann doch nicht so schwer sein?)

Sonst bin ich ganz zufrieden.

würde ich auch noch um das Konstrukt typeswicth erweitern
in etwas so

Foo * foo = new Bla;
   typeswitch(foo)
   {
       case Bla: 
                       //mache irgendetwa
   }

und ich würde für die Switch Case Anweisung alle Typen erlauben wofür es ein == Operator gibt

Nexus

Schön, wieder mal ein Träumerthread
Die Syntax finde ich okay. Schon gar nicht würde ich irgendwelche Zeichen durch Worte ersetzen wollen (z.B. ref statt & oder begin statt { ). Im Folgenden einige Änderungen an Sprachfeatures, die noch nicht genannt wurden.

Was nützlich wäre und nicht in C++0x berücksichtigt wird

Automatisches explicit und ausdrückliches implicit (aber problematisch bei Kopierkonstruktoren)
Weiterleitungs-Feature ähnlich wie using , aber für Komposition statt Vererbung

Änderungen an C++0x

Wirklich einheitliche Initialisierung statt jeden Schrott zu erlauben (zweitletzter Beitrag hier)
Keine Direkt-Initialisierung von Klassenmembern (hier)
Intuitivere Semantik von RValue-Referenzen im Bezug auf Perfect Fowarding (hier)

Dem Erdboden gleichmachen

Variable Arguments
Exception Specifications
Speicherklasse register
Konvertierung Funktion -> Funktionszeiger (ohne &)
export
Digraphen, Trigraphen und alternative Bezeichner für Operatoren

Mir fällt momentan nicht mehr ein, aber ich habe sicher etliche Dinge vergessen. Womöglich werde ich diese nachtragen. Interessant ist auch, dass es viele Sprachfeatures gibt, die ich unheimlich selten brauche – aber wenn ich sie brauche, sind sie enorm praktisch. Deshalb würde ich auf sie nicht komplett verzichten wollen.

Nexus

Cefour schrieb:

würde ich auch noch um das Konstrukt typeswicth erweitern

Würde ich nicht. Zum einen ist scheint mir ein switch auf den Typ std::type_info (was es ja prinzipiell ist) willkürlich gewählt, zum anderen widersprechen explizite Typunterscheidungen dem Grundgedanken von Polymorphie. Abgesehen davon kann man das Verhalten leicht mit einer std::map nachbauen, zumindest ohne Derived-To-Base-Konvertierungen.

volkard

Zuweisungsoperatoren und Kopierkonstruktoren würden niemals automatisch erzeugt.

Nexus

volkard schrieb:

Zuweisungsoperatoren und Kopierkonstruktoren würden niemals automatisch erzeugt.

Das fändest du tatsächlich besser? Ich halte die automatische Erzeugung für ein sehr praktisches Feature. Ich versuche normalerweise, nur bei wenigen Klassen Kopierkonstruktor und Zuweisungsoperator selbst zu definieren und wo möglich auf die eingebaute Kopiersemantik zu vertrauen.

Ausserdem ist das automatische Kopierverhalten konsistent mit POD-Typen (auch Nicht-Klassen).

dot

Nexus schrieb:

Dem Erdboden gleichmachen

Exception Specifications

export

Die beiden Wünsche wurden dir mit C++0x erfüllt

volkard

Nexus schrieb:

volkard schrieb:

Zuweisungsoperatoren und Kopierkonstruktoren würden niemals automatisch erzeugt.

Das fändest du tatsächlich besser?

Ja. Ich mache es immer sofort aus. Und mache es erst wieder an, wenn ich es brauche.
Vielleicht abgeschwächtere Version: Sobald der Benutzer einen Destruktor definiert, werden sie nicht mehr automatisch erzeugt.

Aber ich will eher weniger Regeln als mehr.

Matzer

ipsec schrieb:

"automatisch deduzierte Templateparameter". Beispiel (Syntax variabel):

Hm, warum reicht dir nicht:

template<typename T>
struct foo{};

foo<decltype(5)> some_foo;

?

Ramsis

Auf die schnelle fehlt mir nur ...

// alte vorgehensweise

.h

class Foo
{
    static int a;
};

.cpp

int Foo::a = 0;

// neue vorgehensweise

.h

class Foo
{
    static int a;

    static Foo(int a = 0) : a(a)
    {}
};

.cpp

// die syntax gilt nicht wenn die klasse einen static constructor hat
// error static constructor definiert, benutze in zu init...
int Foo::a = 0;

ipsec

Matzer schrieb:

ipsec schrieb:

"automatisch deduzierte Templateparameter". Beispiel (Syntax variabel):

Hm, warum reicht dir nicht:
template<typename T>
struct foo{};

foo<decltype(5)> some_foo;
?

Dann hat man aber den Wert 5 nicht als Templateparameter. Ich will im Prinzip eine Vereinfachung von foo<int, 5> , foo<double(*)(double), &sin> usw. Damit und mit den Arrays sind dann auch Metastringverarbeitungen möglich. foo<"Hello World!"> ist dann eine Abkürzung für foo<char, 13, "Hello World!"> .

ipsec

Schön wären auch noch Properties. Da sehen zwar viele Nachteile durch Überraschungen ( a.name kann plötzlich die Festplatte formatieren), das trifft aber z.B bei Operatorenüberladung genauso zu. Ich sehe das als Feature, das man sicherlich missbrauchen kann (wie vieles in C++), das aber bei richtiger Anwendung manches eleganter macht.
Weiter muss man überlegen, wie man Sachen wie a.x += 2 auflöst, wenn x ein Property ist, aber da findet man sicher eine Lösung.

this-*gt*that

+ Weg mit den Scheiss Headern
+ Properties
+ Enum Konstanten nur qualifizierbar mit Namespacenamen (gibts vermutlich ab C++0x)
+ Syntaxvereinfachungen (vor allem bei Templates)
+ Hat nix mit der Sprache zu tun, aber gehoert dennoch in ihr Umfeld: Endlich eine gescheite Standard Library mit Threads, XML, Networking etc.

SideWinder

Darf man zusammenfassen, dass ihr eine Art syntaktisches C# mit Template-Metaprogrammierung und STL wünscht?

MfG SideWinder

ipsec

SideWinder schrieb:

Darf man zusammenfassen, dass ihr eine Art syntaktisches C# mit Template-Metaprogrammierung und STL wünscht?

Auf keinen Fall! Die C#-Syntax finde ich teilweise nicht gelungen, in fast allen Fällen finde ich die C++-Alternative besser. Auch würde ich z.B. Properties syntaktisch nicht wie in C# umsetzen wollen.

SideWinder

ipsec schrieb:

SideWinder schrieb:

Darf man zusammenfassen, dass ihr eine Art syntaktisches C# mit Template-Metaprogrammierung und STL wünscht?

Auf keinen Fall! Die C#-Syntax finde ich teilweise nicht gelungen, in fast allen Fällen finde ich die C++-Alternative besser. Auch würde ich z.B. Properties syntaktisch nicht wie in C# umsetzen wollen.

Nun aber raus mit der Sprache, Beispiele, Beispiele, Beispiele. Bitte

MfG SideWinder

volkard

properties halte ich für unnütz. machen nur die syntax komplizierter.

SideWinder

volkard schrieb:

properties halte ich für unnütz. machen nur die syntax komplizierter.

Ist es nicht komplizierter jede Klasse um hunderte Zeilen aufzublasen für:

class C {
        int _i;
        int _j;
    public:
        inline int getI() { return _i; }
        inline void setI(int i) { return _i = i; }

        inline int getJ() { return _j; }
};

vs

class C {
    property int i;
    property int j { get; }
}

? Auch im Hinblick auf Kommentare (oben 3x nötig, unten 1x, etc.)?

MfG SideWinder

Artchi

this->that schrieb:

+ Weg mit den Scheiss Headern

Dafür würde ich private 1000 EUR an das Komitee bezahlen, damit die Headers im ISO-C++ deprecated werden! Das Geld wäre gut angelegt, da es mich Nerven und vor allem Zeit für mein restliches Leben sparen würde. Als Firma würde ich mehr investieren. Unglaublich was für ein Haufen unsinnigen Code-Kot man in seinem (kostbaren) C++-Leben schreiben muss.

this->that schrieb:

+ Enum Konstanten nur qualifizierbar mit Namespacenamen (gibts vermutlich ab C++0x)

Nur logisch. Das erste mal, als ich Enums nutzen wollte, habe ich das intuitiv gemacht, und der Compiler hatte mich angemotzt.

this->that schrieb:

+ Hat nix mit der Sprache zu tun, aber gehoert dennoch in ihr Umfeld: Endlich eine gescheite Standard Library mit Threads, XML, Networking etc.

Die Std-Library gehört mit zum Sprachstandard. Darf man hier ruhig nennen. Threads kommen ja definitiv mit C++0x. Für XML gab es einen Aufruf vom Komitee für den TR2. Wurde aber nichts eingereicht. Networking, da könnte boost.asio ein Kandidat werden. Aber das wird wohl noch 10 Jahre dauern.