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

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

[Nexus]

314159265358979 schrieb:

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

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

Dazu hab ich hier mal was geschrieben.

audacia schrieb:

Reflection.

Wird eher nicht kommen, siehe z.B. hier. Aber eine kontrollierte Form der Reflection (z.B. für einzelne Klassenhierarchien) wäre ab und zu schon praktisch.

asc schrieb:

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

Fände ich auch gut. Nicht das ganze C (Zeiger oder Makros sind z.B. sehr sinnvoll), aber Features wie Variadic Arguments, register , von mir aus auch C-Casts halte ich nicht für nötig. Aber auch C++-Features wie Exceptionspezifikationen, alternative Schlüsselwörter. Oder Teile der Standardbibliothek, wie z.B. std::bind1st() , std::ptr_fun() , std::auto_ptr . Teilweise sind sie ja schon deprecated.

Ethon schrieb:

Tachyon schrieb:

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

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

Ja gut, aber nur aus diesem Grund würde ich keine Sprachmittel einführen. Viele C-Callback-APIs haben eh einen void* userData -Parameter...

[Artchi]

asc schrieb:

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.

Nennt sich COM, und gibt es sogar auf Windows, Mac OS X und VMS implementiert!

Muß nur auf weiteren Plattformen implementiert werden und natürlich müssen COM-Objekte bereit gestellt werden. Und schon kann man zumindest auf einer Plattform Compiler-unabhängig OO-APIs nutzen.

MS wird es mit Windows 8 noch weiter treiben.

[audacia]

Aber COM in C++ ist einfach nur fürchterlich. Insofern finde ich die Forderung nach einem einheitlichen ABI auch sinnvoll, wenngleich mindestens so weltfremd wie die Forderung nach Reflection

Gebundene Funktionszeiger in C++Builder (Stichwort __closure ) können auch nicht an C-APIs übergeben werden. In C++-Code ist bind() eine Alternative, allerdings ist ein __closure deutlich effizienter und kommt ohne zusätzliche Allokationen aus. Der eigentliche Grund für die Einführung des Sprachmittels war aber die Binärkompatibilität zu Delphi. Und mit der Einführung von anonymen Funktionen in Delphi einerseits und Lambda-Funktionen in C++ andererseits werden diese gebundenen Funktionszeiger vermutlich an Bedeutung verlieren.