C++14 std::set Konstruktoren

Nathan

Ich bin grad hierüber gestolpert: http://en.cppreference.com/w/cpp/container/set/set
Kann mir einer erklären wieso in C++14 das Compare-Argument fehlen soll?

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

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

Nexus

stolpert schrieb:

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

Nathan

stolpert schrieb:

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.

Nexus

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

Nathan

Nexus schrieb:

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

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

Nexus schrieb:

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.

Nexus

Ich bin generell skeptisch gegenüber Sprachmitteln, die die Syntax minimal verschönern und dafür die Sprache komplexer und Compiler fehleranfälliger machen (Stichwort Deduktionsregeln). Ich persönlich finde, bei

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.