Was fehlt in C++11?

EOutOfResources schrieb:

Ein Dateisystem mit Ordnerstrukturen und dergleichen hab ich mir schon öfters gewünscht.

Gibts das immer noch nicht? Gibts wenigstens Threads?

ipsec

volkard schrieb:

Statische Destruktoren? Erkläre mal. Ist das, wenn man vor den Destruktor nicht virtual schreibt?

Statische Konstruktoren? Erkläre mal. Ist das, wenn man ein Objekt erzeugen will, dessen Typ man zur Compilezeit kennt?

Ich glaube er meint damit ein ähnliches Konzept wie in C#: der statische Konstruktor jeder Klasse wird zum Programmbeginn aufgerufen (seine Aufgabe ist, statische Member der Klasse zu initialisieren), entsprechend räumt der Destruktor am Ende des Programms die statischen Member wieder auf.

Brauche ich persönlich nicht.

Athar

Ich vermisse einen Weg, den Compiler in ganz bestimmten Situationen Parametertypen automatisch bestimmen zu lassen. Insbesondere möchte ich so etwas schreiben können:

sort(vec,[](&l,&r){return l.z<r.z;});

Lambda-Funktionen sind schön und gut, aber bis jetzt muss man immer noch die (oft recht langatmigen) Parametertypen selbst angeben, was gar nicht schön ist.

Eigentlich ist mir auch das return noch zu viel, besser sowas:

sort(vec,[](&l,&r){=> l.z<r.z;});

Aber gut, langsam wird's kryptisch.

wxSkip

diskette schrieb:

EOutOfResources schrieb:

Ein Dateisystem mit Ordnerstrukturen und dergleichen hab ich mir schon öfters gewünscht.

Gibts das immer noch nicht? Gibts wenigstens Threads?

Threads gibt es.
Allerdings funktionieren sie im GCC 4.5.2 noch nicht (es fehlen manche Implementierungen, weiß nicht, wie es mit 4.6 aussieht).

Dobi

Dateisystem fänd ich genau wie EOutOfResources ganz nett. Ich hab nix gegen boost, aber so würds mir noch besser gefallen.

Ne definierte Binärschnittstelle für libs wär toll, obwohl mir klar ist, dass das nicht so einfach geht.

@Athar: Bist du Golfer?

volkard

Athar schrieb:

Eigentlich ist mir auch das return noch zu viel, besser sowas:
sort(vec,[](&l,&r){=> l.z<r.z;});
Aber gut, langsam wird's kryptisch.

Smalltalk oder Perl halten es so, daß ganz schlicht der letze Ausdruck returnt wird.

sort(vec,[](&l,&r){l.z<r.z;});

Und dann braucht man die Parameter auch nicht zu nennen, denn alle Bezeichner, die nicht aufgelöst werden können, müssen ja von außen kommen.

sort(vec,[]{l.z<r.z;});

Und an {} innerhalb eines Ausdrucks ist auch schon klar genug gemacht, daß jetzt Code kommt.

sort(vec,{l.z<r.z;});

Geht leider nicht ganz. Die Übergabereihenfolge von l und r ist noch zu wichtig.
Also entweder mindestens

sort(vec,(l,r){l.z<r.z;});

oder standardisierte Namen

sort(vec,{lhs.z<rhs.z;});

oder

sort(vec,<);

Dobi

volkard schrieb:

sort(vec,{l.z<r.z;});

Das wär allerdings echt schick.

Athar

Dobi schrieb:

@Athar: Bist du Golfer?

Nicht unbedingt, aber ich finde schon, dass eine Sprache erlauben sollte, sich möglichst kurz zu fassen - vor allem in häufig vorkommenden Situationen.
Und das macht einem C++ nicht immer einfach.

Dobi schrieb:

volkard schrieb:
sort(vec,{l.z<r.z;});
Das wär allerdings echt schick.

Oh ja, das wäre eine feine Sache.
Fast schon schade, dass man bei C++ so stark auf Rückwärtskompatibilität achtet. Aber auch wenn man diese berücksichtigt, sollten da einige Verbesserungen drin sein, die C++ näher an diese schöne kleine Zeile bringen.

Edit:

volkard schrieb:

Geht leider nicht ganz. Die Übergabereihenfolge von l und r ist noch zu wichtig.

Da hätte ich angenommen, dass den unbekannten Bezeichnern von links nach rechts jeweils der nächste Parameter zugewiesen bekommen. Ist aber wahrscheinlich keine gute Idee.
Standardisierte Namen sind definitiv gut, diese könnten sich etwa an die schon bekannten Bezeichner _1, _2, ... anlehnen.

wxSkip

Was haben Lambdas mit Rückwärtskompatibilität zu tun?

EOutOfResources

Vielleich noch Mehrfach-Konvertierung:

class Vector
{
  private:
    double X, Y;
  public:
    Vector(double, double);
    operator double, double() const
    {
      return this->X;
      return this->Y; //Ich weis, nicht sehr intuitiv
    }
};
void Func1(const Vector&);
void Func2(double, double);
Func1(1.5, 3.2);
Func2(Vector(1.5, 3.2));

Wäre noch interessant...

wxSkip

Argh, damit wäre C++ noch schwieriger nachvollziehbar... Vielleicht das Ganze auch noch mit Variadic Templates?

volkard

operator double, double() const
    {
      return this->X,this->Y;//intuitiv
    }
};

Leider gibt es schon den Kommaoperator.

EOutOfResources

Wie wäre es mit dem Doppelpunkt? Ein Compiler sollte zwischen einer bedingten Zuweisung, der Initialisierungsliste und diesem Konstrukt unterscheiden können:

operator double, double() const
{
  return this->X : this->Y;
}

wxSkip

EOutOfResources schrieb:

Wie wäre es mit dem Doppelpunkt? Ein Compiler sollte zwischen einer bedingten Zuweisung, der Initialisierungsliste und diesem Konstrukt unterscheiden können:
operator double, double() const
{
  return this->X : this->Y;
}

Hier wird's schon schwieriger

operator double, double() const
{
  return rand()%2==0 ? this->X : this->Y : this->Y : this->X;
}

EOutOfResources

wxSkip schrieb:

Hier wird's schon schwieriger

operator double, double() const
{
  return rand()%2==0 ? this->X : this->Y : this->Y : this->X;
}

operator double, double() const
{
  return std::rand() % 2 == 0 ? (this->X : this->Y) : (this->Y : this->X);
}

wxSkip

EOutOfResources schrieb:

wxSkip schrieb:

Hier wird's schon schwieriger

operator double, double() const
{
  return rand()%2==0 ? this->X : this->Y : this->Y : this->X;
}

operator double, double() const
{
  return std::rand() % 2 == 0 ? (this->X : this->Y) : (this->Y : this->X);
}

Und was gibst du für eine Fehlermeldung aus, wenn der Benutzer das nicht klammert?

error: no difference in operator predence for two different operations. Please put parentheses around the operations.

EOutOfResources

wxSkip schrieb:

Und was gibst du für eine Fehlermeldung aus, wenn der Benutzer das nicht klammert?

Gar keine. Schlechte Formatierung ist Sache des Users. Der Compiler kennt ja die Anzahl der Rückgabewerte. Daraus sollte er es schon ableiten können.

wxSkip

Das schwierige für den Compiler wäre, dass die Argumentzahl plötzlich veränderlich wäre. Das bedürfte mindestens einer radikalen Neuimplementierung zahlreicher Compilerteile, wenn es überhaupt möglich wäre mit überladbaren Funktionen usw. Und das lohnt sich m.E. wirklich nicht im Verhältnis zum Nutzen.

volkard

Viele Möglichkeiten.
Zur Zeit ist zum Beispiel das geklammerte Plus noch frei.

operator double (+) double() const
{
  return this->X (+) this->Y;
}

Oder als echte Traditionalisten geben wir dem Schlüsselwort static eine weitere Bedeutung.

operator double static double() const
{
  return this->X static this->Y;
}

Aber mit {}-Codesequenzen innerhalb von Ausdrücken, wäre es angebracht, die Operatoren ?: und , abzuschaffen. Nur geht das nicht wegen der Abwärtskompatibilität. C++ muß geforkt werden. Ich schlage als neuen Namen #C++-. Das - soll ausdrücken, daß mache Sachen unter Aufgabe der Abwärtskompatimilität weggemacht werden und das # soll ausdrücken, daß sie total modern ist.

Und an {} innerhalb eines Ausdrucks ist auch schon klar genug gemacht, daß jetzt Code kommt.

sort(vec,{l.z<r.z;});

Gäbe das nicht ein Problem mit Initialisierungslisten? Schließlich könnte eine Funktion ja auch eine Überladung haben, die als zweiten Parameter ein Objekt übergeben bekommt, das mittels einer std::initializer_list konstruiert wird.