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

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

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

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

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

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

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

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

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

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

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

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

- Funktionszeiger auf Methoden eines Objekts

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

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.

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.

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 ?

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.

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

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

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.

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.

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!

Nur ist COM
a) unterschiedlich weit implementiert (OS-bezogen)
b) unschön zu programmieren, lieber wäre mir eine direkte Sprachintegration
c) nicht wirklich konsistent zum restlichen C++ (Betrifft auch dei Sprachintegration)

Artchi schrieb:

MS wird es mit Windows 8 noch weiter treiben.

Ja, aber dies ist kein Standard der einfach so mal auf alle OS portiert wird.

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 ?

Ja. Allerdings hat ein "gebundener Funktionszeiger" einen Platzvorteil als auch einen Geschwindigkeitsvorteil -- selbst dann, wenn std::function per "small function object optimization" implementiert wird -- also bei kleinen Funktionsobjekten ohne den Freispeicher auskommt.

Das Aufrufen einer Methode über Funktionszeiger und Objektzeiger erfordert ggf ein Pointer-Adjustment und ein vtable-Lookup. Speichert man beide Zeiger als "einen Kombizeiger", kann man diese Aktionen vorziehen, so dass später die Funktion "direkter" aufgerufen werden kann (ohne vtable-Lookup und ohne Pointer-Adjustment). Zeiger auf Elementfunktionen können dank virtueller Vererbung und solche Scherze schonmal etwas größer ausfallen (sizeof(void*)*3). Speichert man dazu den this-Zeiger, ist man schon bei sizeof(void*)*4, wohingegen ein einfacher "gebundener Funktionszeiger" nur sizeof(void*)*2 groß sein muss.

Für eine Sprache wie C++, die eine "zero overhead"-Sprache sein will, sehe ich das als eine kleine Lücke. Aber die Lücke ist scheinbar nicht groß genug, dass man dafür einen neuen Funktionszeigertypen hat einführen wollen. So etwas wurde zumindest nicht für C++2011 vorgeschlagen. Richtig wichtig finde ich das jetzt auch nicht.