Eure Wünsche an Sprachfeatures für den nächsten Standard (nach C++11)

[314159265358979]

Ich habe mir gerade Gedanken gemacht, welche Sprachfeatures ich nach C++11 gerne hätte. Hier eine Liste, gebt mir euer Feedback dazu und ergänzt auch eure Wünsche, würde mich mal interessieren.

1.) Expliziter Aufruf von default-Argumenten

void foo(int a = 42, double d = 3.14);
foo();
foo(default, 123.456);
foo(123456, default);
foo(default, default);
foo(default...);
foor(123, default...);

2.) "Variadic typedef"

template <typename... Args>
struct bar
{
    typedef... Args MyTypes;
};

MyTypes ist ein Parameter-Pack, das wiederverwendet werden kann, z.B.:

std::function<void(bar<int, double, bool>::MyTypes...)> func;

Zugriff mit typename innerhalb eines Templates:

typename bar<int, double, char>::MyTypes...

3.) "Forward typedef"
Deklariert einen Typen, allerdings können auch typedefs deklariert werden, z.B.:

typedef std::string;
typedef std::istream;

4.) Beliebige values als Templateparameter (sowohl für Klassen, als auch für Funktionen)

template <auto T> void baz();

baz<5>();
baz<'c'>();

Variadic:

template <auto... Values> struct qux {};

qux<5, 'c'> q;
qux<'c', 5> r;

Der Typ des Arguments bzw der Argumente ist dann

decltype(T)

bzw

decltype(Values)...

5.) Typen mit constexpr Konstruktor als Template-Parameter Wert

struct quuux { constexpr quuux(int); };

template <quuux Q> void foobar();
foobar<quuux(42)>();

Das einzige Problem dabei ist, dass man Konstruktoren ohne Parameter nicht sinnvoll aufrufen kann. quuux() wäre ein Funktion, die quuux zurückgibt.

Die Liste ist übrigens nicht nach Priorität sortiert. Irgendwas hab ich bestimmt vergessen.

Grüße,
PI

[Ethon]

1. Module statt Headerfiles.
2. Ne richtig dicke Standardbibliothek.

2 wird warscheinlich kommen (Boost.Filesystem + Boost.Asio klingen ja schonmal gut), 1 mit Glück.

[Tachyon]

Aktual-Funktionsparameter über Namen:

void foo(int a = 42, double d = 3.14);

foo(a := 10); //d = default
foo(d := 0.707); // a = default
foo(d := 10.2, a := 2.7182) //Reihenfolge egal

Das würde auch die Sache mit den Defaults aus Deinem Beispiel überflüssig machen. Außerdem werden Aufrufe besser lesbar, weil man direkt sieht, welcher Wert zu welchem Parameter gehören soll. Muss nur eine ordentliche Syntax her.

"Strenge" typedefs:

typedef unsigned int new some_type;
typedef unsigned int new other_type;

some_type a = 42;
other_type b = a; //Fehler b nicht in a konvertierbar
other_type b = static_cast<b>(a); //okay, explizite Konvertierung

[Tomahawk]

Tachyon schrieb:

"Strenge" typedefs:

typedef unsigned int new some_type;
typedef unsigned int new other_type;

some_type a = 42;
other_type b = a; //Fehler b nicht in a konvertierbar
other_type b = static_cast<b>(a); //okay, explizite Konvertierung

Genau das suche ich seit einiger Zeit! Ein Workaround hierfür ist aufwendig. Alle Operationen müssen überladen werden.

enum some_type {
};

inline some_type operator+ (some_type s, int i) {
  return static_cast<some_type> (static_cast<int> (s) + i);
}

inline some_type operator+ (some_type s1, some_type s2) {
  return static_cast<some_type> (static_cast<int> (s1) + static_cast<int> (s2));
}

inline void operator++ (some_type& s) {
  s = static_cast<some_type> (static_cast<int> (s) + 1);
}

/// etc.

[audacia]

Reflection.

[Tomahawk]

Habe auch so etwas gesehen, ist das C++11 ?

enum Selection : unsigned int {
  None = 0,
  Single = 1,
  Multiple = 0xFFFF0000UL
};

[krümelkacker]

Sprachkern:
Ich möchte direkter das aufschreiben können, was ich meine. Möglichst wenig Redundanz und möglichst wenig Boilerplate. Konkreter:
- Concepts (Ersatz für enable_if-Hack + Type-Checking für Templates)
- Einfachere "Metaprogrammierung", beispielsweise syntaktisch schönere Typ-Transformationen ohne typename/::type
- Modules

Die ersten beiden Punkte lassen sich vielleicht gemeinsam elegant erschlagen. Die Concepts-Entwürfe, die es vorher gab, haben mir aber nicht gefallen und ich bin froh, dass wir in C++2011 nicht so etwas halbgares angedreht bekommen haben.

Bibliothek:
- File System

[Gast]

Ethon schrieb:

1. Module statt Headerfiles.
2. Ne richtig dicke Standardbibliothek.

Gibt's schon, heißt Python. :p

[Artchi]

1. Concepts
2. Header für sinnlos machen, also wohl so was wie Module einführen
3. TR2 vorher fertig stellen und danach übernehmen

Die Sprache selbst sollte vorerst nicht weiter aufgebohrt werden, da die C++11 Features in der C++ Community erst mal heimisch werden sollten.

[asc]

Was ich mir wünschen würde, und was vermutlich niemals kommt wäre eine ABI-Änderung die zumindest auf dem jeweiligen Betriebsystem Bibliotheken (wie lib/dll unter Windows) direkt ermöglich, die auch vom Compiler unabhängig sind und Klassen etc. über die Schnittstellen hinweg zulassen.

Ebenso fände ich eine Abkehr von der C-Kompatibilität nicht schlecht, und damit verbunden ein Aufräumen im C++ Standard. Sinnvoll wäre dann natürlich ein Schlüsselwort das Übergänge definiert um mit C kommunizieren zu können (Vergleichbar mit z.B. C# und "unsafe" das Bereichsweise Zeiger zulässt).

Und zu guter letzt wäre es schön wenn es neben der C++ Standardbibliothek noch weitere Standardisierte Bibliotheken geben würden, die spezielle Bereiche, die zwar nicht auf jeder aber doch auf einem großen Teil aller Plattformen laufen würden (Konkret denke ich z.B. an ein standardisiertes UI-Framework im Stile der Standardbibliothek, und mit Nutzen derselben).

[Tachyon]

Module fände ich zwar auch gut, jedoch sollte man es bei einer Trennung zwischen Interface und Implementierung belassen. So wie es z.B. in Java gehandhabt wird, finde ich es eher suboptimal. Vielleicht ein System ähnlich wie in Ada.
Ein einheitliches ABI wäre wirklich toll, ja.

[Gast]

LINQ

[Burkhi]

- Eigenshaften
- Funktionszeiger auf Methoden eines Objekts

ja ich weiss, sind typische C++ Builder Erweiterungen, die ich persönlich aber für sinnvoll halte.

[Gast]

Zwei kleine schöne C++ LINQ Beispiel:

struct Kunde { string name; int alter; };

vector<Kunde> kunden = ...
auto alleKundenNamen = kunden.select(x => x.name);

struct Kunde { string name; int alter; };

vector<Kunde> kunden = ...
auto alleMinderjaehrigenKunden = kunden.where(x => x.alter < 18);

[314159265358979]

Burkhi schrieb:

- Funktionszeiger auf Methoden eines Objekts

Wenn du Methodenzeiger meinst, die gibts doch schon. Oder meinst du was anderes?

[krümelkacker]

314159265358979 schrieb:

Burkhi schrieb:

- Funktionszeiger auf Methoden eines Objekts

Wenn du Methodenzeiger meinst, die gibts doch schon. Oder meinst du was anderes?

Er meint Funktionszeiger auf "gebundende" Funktionen -- die also schon mit einem bestimmten Objekt verknüpft sind -- quasi den this-Parameter mit beinhalten.

[Burkhi]

krümelkacker schrieb:

314159265358979 schrieb:

Burkhi schrieb:

- Funktionszeiger auf Methoden eines Objekts

Wenn du Methodenzeiger meinst, die gibts doch schon. Oder meinst du was anderes?

Er meint Funktionszeiger auf "gebundende" Funktionen -- die also schon mit einem bestimmten Objekt verknüpft sind -- quasi den this-Parameter mit beinhalten.

So ist es.

[Tachyon]

krümelkacker schrieb:

314159265358979 schrieb:

Burkhi schrieb:

- Funktionszeiger auf Methoden eines Objekts

Wenn du Methodenzeiger meinst, die gibts doch schon. Oder meinst du was anderes?

Er meint Funktionszeiger auf "gebundende" Funktionen -- die also schon mit einem bestimmten Objekt verknüpft sind -- quasi den this-Parameter mit beinhalten.

Bekommt man das nicht quasi mit std::bind und std::function ?

[Ethon]

Tachyon schrieb:

krümelkacker schrieb:

314159265358979 schrieb:

Burkhi schrieb:

- Funktionszeiger auf Methoden eines Objekts

Wenn du Methodenzeiger meinst, die gibts doch schon. Oder meinst du was anderes?

Er meint Funktionszeiger auf "gebundende" Funktionen -- die also schon mit einem bestimmten Objekt verknüpft sind -- quasi den this-Parameter mit beinhalten.

Bekommt man das nicht quasi mit std::bind und std::function ?

Nichts, was man an C-APIs übergeben könnte.

[Bashar]

Burkhi schrieb:

- Funktionszeiger auf Methoden eines Objekts

Das wird es nicht geben. C++11 zeigt doch eindeutig, dass variable(?) Funktionen durch Funktionsobjekte ausgedrückt werden, und damit ist das was du brauchst jetzt schon möglich.

Ethon schrieb:

Nichts, was man an C-APIs übergeben könnte.

Geht das etwa mit den gebundenen Methodenzeigern aus dem C++-Builder? Würde mich a) wundern und b) stark interessieren, wie die das realisieren.