(Fehlt nur noch, dass die die Template-Argumente bei Konstruktoren deduzieren, ich frag mich, was daran so schwer sein soll)

(Fehlt nur noch, dass die die Template-Argumente bei Konstruktoren deduzieren, ich frag mich, was daran so schwer sein soll)

Was meinst du genau? Deduktion ist die einzelne Möglichkeit, du kannst Konstruktoren nicht mit explizit angegebenen Template-Argumenten aufrufen.

Oder meinst du, dass man beim std::set nur das erste Template-Argument angeben soll? Wenn du das brauchst, schreib dir einen Maker (wenn du willst, kannst du auch noch Perfect Forwarding einbauen):

template <typename T, typename Compare, typename Alloc>
std::set<T, Compare, Alloc> make_set(const Compare& c, const Alloc& a)
{
    return std::set<T, Compare, Alloc>(c, a);
}

auto set = make_set<int>(myComp, myAlloc);

Das sind keine Ersetzungen, das sind zusätzliche Konstruktoren. Die sind nützlich, wenn du den Default-Comparator willst, aber einen speziellen Allocator.

Argh, facepalm.
Danke.

Tipp: Bei den Ersetzungen steht in grün "(until C++14)"

Ja, das weiß ich (eigentlich).
War nur verwirrt wegen der gleichen Nummer.

Wenn du das brauchst, schreib dir einen Maker (wenn du willst, kannst du auch noch Perfect Forwarding einbauen):

Genau das brauche ich. Und Maker find ich mühsam und doof.

Ich will http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3602.html und zwar schon seit Jahren.

tuple t(4, 3, 2.5);

halten sich die Verschönerung und die durch die Verschleierung des Templates entstandene Verwirrung die Waage. Mit anderen Worten,

auto t = make_tuple(4, 3, 2.5);

ist zuweit von einem echten Problem entfernt, als dass ich hier Handlungsbedarf sähe. Die angesprochene Konsistenz, die damit erreicht würde, ist ohnehin fragwürdig -- statt

auto p = make_unique<int>(4);

kann man nämlich nicht

unique_ptr p(4)

schreiben, da die Auflösung spätestens bei Zeigern mehrdeutig (oder höchst verwirrend) ist.

unique_ptr q(new int);
/* ist das */ unique_ptr<int> q(new int);
/* oder */    auto q = make_unique<int*>(new int);

Bei diesen Proposals habe ich zunehmend das Gefühl, dass Leute eher ihre persönlichen Syntaxvorlieben befriedigen als die Sprache verbessern möchten. Viele Leute sehen auch nicht ein, dass jedes Feature, das die Sprache komplexer macht, langfristig negative Auswirkungen hat: Der Lernprozess dauert nochmals länger, Leute verstehen neueren Code nicht mehr, Entwickler wenden sich bei zu grosser Komplexität potentiell ab, Compiler werden schwieriger zu implementieren und enthalten mehr Bugs, der Sprachstandard selbst wird schwieriger konsistent und widerspruchslos zu halten. Für Features mit echtem Mehrwert kann sich das lohnen, aber für solche syntaktischen Oberflächlichkeiten bin ich klar dagegen. Das if-for von kürzlich ist da noch einige Stufen schlimmer.

...aber das ist nur meine Meinung.