Was würdet ihr an C++ verbessern?

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.

freaky

Ich als C# Nutzer finde Properties aber auch besser

class CSharp
{
    public int Zahl { get; private set; } 
}

Etc...

Artchi

SideWinder schrieb:

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.)?

Hem, ist für mich echt ein konstruiertes Beispiel. Was ist, wenn neben dem reinen return und assignment noch was anderes passieren soll?

Michael E.

Regex-Literale. Reguläre Ausdrücke sind sowieso schon schwer zu lesen, da will ich nicht noch jedes zweite Symbol escapen müssen.