3. Was fehlt in C++11?

Was fehlt in C++11?

  • D

    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? 😉

    0
  • V

    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,<);
    0
  • D

    volkard schrieb:

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

    Das wär allerdings echt schick. 👍

    0
  • A

    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.

    0
  • W

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

    0
  • E

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

    0
  • W

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

    0
  • V
     

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

    Leider gibt es schon den Kommaoperator.

    0
  • E

    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;
}
    0
  • W

    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;
}
    0
  • E

    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);
}
    0
  • W

    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.
    0
  • E

    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.

    0
  • W

    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.

    0
  • V

    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.

    0
  • ?

    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.

    0
  • S

    Irgendwer schrieb:

    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.

    Solcherlei Probleme hat man in C++ dauernd, und das zeigt nicht nur, dass die Sprache alt ist sondern auch, dass sie syntaxmäßig viel zu alt ist. Alleine auch schon der Mehraufwand um für C++ IDE-Features wie Refactoring umzusetzen ist erheblich höher als bei modernen Sprachen (im Sinne der Syntax) wie Java oder C#.

    MfG SideWinder

    0
  • C

    volkard schrieb:

    #C++-.

    Damit ist aber der Gag im Namen weg. Ich wäre für C#er++ 😃

    0
  • 3

    Bin ich der einzige, der solche Container vermisst? 😮

    0
  • N

    SideWinder schrieb:

    Alleine auch schon der Mehraufwand um für C++ IDE-Features wie Refactoring umzusetzen ist erheblich höher als bei modernen Sprachen (im Sinne der Syntax) wie Java oder C#.

    Das liegt aber eher daran, dass die Sprache semantisch viel komplexer ist, oder? Alleine schon die ganzen Templates (welche einen grossen Teil der Standardbibliothek ausmachen), die Trennung von Deklaration und Definition, Zeiger, Referenzen, const , ... Syntaktisch ist C++ recht ähnlich wie Java oder C#, zumindest wenn man "ganz normal" (ohne Metaprogrammierung etc.) programmiert.

    Ich finde es langsam Zeit für Pointer-Container, auch wenn mir Boosts Umsetzung nicht wahnsinnig gefällt. Es gibt zwar jetzt unique_ptr , aber damit hat man keine Kopiersemantik.

    0
Anmelden zum Antworten