Partielle Template-Spezialisierung

[Sebastian Pizer]

Dravere schrieb:

Es dürfen Erweiterungen existieren. Das Programm muss einfach nur well-formed bleiben. Es steht im Standard, dass std::map 4 Templateparameter haben soll. Man muss also schreiben dürfen: std::map<A, B, C, D> .

Sagt wer?
Ist das hier auch well-formed?

#include <map>
template<template<class,class,class,class> class Foo>
struct blupp {};
int main()
{
  blupp<std::map> x;
}

Wo ziehst Du denn da die Grenze?

Gruß,
SP

[pumuckl]

Sebastian Pizer schrieb:

Dravere schrieb:

Es dürfen Erweiterungen existieren. Das Programm muss einfach nur well-formed bleiben. Es steht im Standard, dass std::map 4 Templateparameter haben soll. Man muss also schreiben dürfen: std::map<A, B, C, D> .

Sagt wer?
Ist das hier auch well-formed?

#include <map>
template<template<class,class,class,class> class Foo>
struct blupp {};
int main()
{
  blupp<std::map> x;
}

Opops.Mein erstes Statement zu dem Thema war falsch. Natürlich kann man die Geschichte mit der map<X, Y> bzw. map<X, Y, C, A> machen - das ist kein Problem. Anders ists mit dem template template Parameter den du hier gezeigt hast. Ich weiß nicht mehr obs Meyers in einem der Effective C++ Bücher oder Sutter in einem der Exceptional C++ Bücher war - aber genau dieses Beispiel taucht dort auf. Eben weil die Standardcontainer zusätzliche (per default gesetzte) Templateparameter haben dürfen kann es passieren, dass der Compiler std::map nicht mit einem 4-Parameter-Template matchen kann.

[Dravere]

@Sebastian Pizer,
Es gibt nirgendwo eine Garantie, dass std::map genau 4 Templateparameter hat, nur dass man ganz sicher 4 angeben kann. Das ist ein Unterschied. Deshalb ist dein Programm einfach nicht Standardkonform.

Sebastian Pizer schrieb:

Wo ziehst Du denn da die Grenze?

Die Grenze zieht der Standard und zum Teil ist keine vorhanden.

@pumuckl,
Bist du sicher dass es funktioniert? Ich hatte irgendwas im Kopf, dass es unter speziellen Umständen nicht funktionieren kann. Shade Of Mine hat da mal vor langer Zeit etwas präsentiert gehabt. Kann mich nur nicht mehr richtig erinnern und finde es aktuell auch nicht mehr...
Deshalb habe ich, um meine Aussage abzusichern, den Satz noch dazugeschrieben

Grüssli

[Sebastian Pizer]

Dravere schrieb:

@Sebastian Pizer,
Es gibt nirgendwo eine Garantie, dass std::map genau 4 Templateparameter hat, nur dass man ganz sicher 4 angeben kann. Das ist ein Unterschied. Deshalb ist dein Programm einfach nicht Standardkonform.

Wieso ist es das nicht? Woran machst Du das fest? Welcher Satz aus dem Standard lässt Dich das glauben? Du ziehst willkürlich eine Grenze zwischen map<int,int,comp,my_alloc> muss funktionieren aber als std::map muss nicht als template<class,class,class,class>class-Parameter benutzbar sein.

So, wie ich das sehe, beziehen sich die Zitate, die Du gebracht hast, auf Definitionen (Räpresentierung ist implementierungsabhängig), und nicht die Deklarationen.

Gruß,
SP

[moagnus]

Absolute Klasse! Echt.

Am elegantesten finde ich Nexus' zweite Lösung mit den überladenen Ausgabeoperatoren.
Draveres Vorschlag dagegen hat mir in Sachen generischer Programmierung wirklich weitergebracht: Da wurde mir erstmal klar, dass ein

template<typename K, typename V, typename C, typename A>
struct print_functor<std::map<K, V, C, A> >

mit

print_functor<ContainerT> a_print_functor;

instanziiert werden kann und der Compiler dann die Zeile mit "template<typename... >" ganz automatisch anhand der übergebenen map "ausfüllt".

Die Diskussion über den Standard war auch ganz informativ.

Danke natürlich auch an alle anderen!

[Dravere]

*gerade noch bemerkt, dass er da noch nicht geantwortet hat*

Da dem moagnus nun geholfen ist, dürfen wir hier auch sicher ohne Gewissensbisse weiterdiskustieren

Sebastian Pizer schrieb:

Wieso ist es das nicht? Woran machst Du das fest? Welcher Satz aus dem Standard lässt Dich das glauben?

Ich wiederhole mich:
Es gibt im ganzen Standard keinen Satz, welcher aussagt, dass std::map genau 4 Templateparemeter haben muss. Es werden 4 präsentiert, aber nirgends gesagt, dass es nicht mehr sein dürfen. Ich kann dir daher keinen Satz zeigen, weil es eben keinen gibt.
Es gibt nur den Code, allerdings ist dieser nicht verbindlich, sondern soll nur zur Verdeutlichung dienen, was wunderbar auch im Standard steht. Im Standard steht aber eben nicht, dass er verbindlich ist.

Sebastian Pizer schrieb:

Du ziehst willkürlich eine Grenze zwischen map<int,int,comp,my_alloc> muss funktionieren aber als std::map muss nicht als template<class,class,class,class>class-Parameter benutzbar sein.

Wenn hier jemand willkürlich ist, dann bist es du, da du einfach willkürlich annimmst, dass der präsentierte Code verbindlich ist.

Sebastian Pizer schrieb:

So, wie ich das sehe, beziehen sich die Zitate, die Du gebracht hast, auf Definitionen (Räpresentierung ist implementierungsabhängig), und nicht die Deklarationen.

Und das ist dann auch deine willkürliche Interpretation. So steht es nicht im Standard. Du fügst dies einfach dazu, weil es dir logisch erscheint, aber so steht es nicht da. Und entscheidend ist im Standard, was dort steht. Der Standard geht nicht davon aus, dass jemand logische Zusätze reinbaut, so dass es einem besser gefällt. Sonst wäre der Standard ja sinnlos

Am einfachsten machen wir es also so, dann bin ich sofort bereit dir zu glauben:
Zeig mir eine Stelle im Standard, wo steht, dass der angegebene Code verbindlich ist.

Grüssli

[Sebastian Pizer]

Dravere, ich verstehe Deine Position, stimme Dir aber nicht zu, weil es für mich einfach nicht nach einer schlüssigen Argumentation aussieht. Du leitest von Kapitel 1.4 irgendwie ab, dass ein Klassentemplate zusätzliche Defaultparameter haben darf weil angeblich nur

typedef std::map<dings,bums,comp,alloc> t;

bei entsprechenden Typen dings,bums,comp,alloc funktionieren müsse, nicht aber die Verwendung des Klassentemplates als Template-Parameter des Typs template<class,class,class,class>class . Ich finde das ganz schön weit hergeholt, wenn man sich dazu nochmal Absatz 3 und 8 anguckt:

3 For classes and class templates, the library clauses specify partial definitions. Private members (clause 11) are not specified, but each implementation shall supply them to complete the definitions according to the description in the library clauses.

8 A conforming implementation may have extensions (including additional library functions), provided they do not alter the behavior of any well-formed program. Implementations are required to diagnose programs that use such extensions that are ill-formed according to this International Standard. Having done so, however, they can compile and execute such programs.

Absatz 3 --> Der Standard spezifiert partielle Definitionen. Partiell heißt hier, dass es Lücken und Platzhalter gibt, die eine Implementierung sinvoll zu füllen hat um die anderen Spezifikationen zu erfüllen. Hier steht nichts, was einem suggerieren könnte, dass eine konforme Implementierung veränderte Deklaration verwenden kann.

Absatz 8 --> Wenn ich mich richtig erinnere, hast Du diesen Absatz auch zitiert und das Hinzufügen von weiteren Defaultparametern als "Extension" gewertet. Der Standard fordert, dass Erweiterungen nicht das Verhalten von wohlgeformten Programmen ändern dürfen. Ein Programm, welches std::map als template-template-parameter mit 4 eigenen template parametern benutzen will, ist ohne diese Erweiterung wohlgeformt, mit aber leider nicht. Daraus schließe ich, dass eine konforme Implementierung keine zusätzlichen Defaultparameter für Klassentemplates einführen kann.

Gruß,
SP

[Dravere]

Sebastian Pizer schrieb:

Du leitest von Kapitel 1.4 irgendwie ab, dass ein Klassentemplate zusätzliche Defaultparameter haben darf weil angeblich nur

typedef std::map<dings,bums,comp,alloc> t;

bei entsprechenden Typen dings,bums,comp,alloc funktionieren müsse, nicht aber die Verwendung des Klassentemplates als Template-Parameter des Typs template<class,class,class,class>class .

Das ist genau der Fehler, ich leite nichts ab. Ich sage nur, dass nichts drin ist. DU bist der, welcher irgendwelche Dinge probiert herzuleiten

Du hast mir zum Beispiel immer noch nicht gezeigt, wo im Standard steht, dass der präsentierte Quellcode verbindlich ist. Du hast mir im Standard nicht gezeigt, wo steht, dass es genau 4 Parameter sein müssen. Zeig mir diese Stellen!

Sebastian Pizer schrieb:

Absatz 3 --> Der Standard spezifiert partielle Definitionen. Partiell heißt hier, dass es Lücken und Platzhalter gibt, die eine Implementierung sinvoll zu füllen hat um die anderen Spezifikationen zu erfüllen. Hier steht nichts, was einem suggerieren könnte, dass eine konforme Implementierung veränderte Deklaration verwenden kann.

Kannst du mir sagen, woher du dies nimmst? Ist das deine freie Interpretation des Satzes? Mit ein wenig zusätzlichen Pfeffer und Salz, sonst würde es nicht so schmecken?
Und ja, in dem Satz steht nicht viel. Grundsätzlich steht da nur, dass der Standard für Klassen und Klassentemplates eine partielle Definition liefert. Private Member werden nicht gezeigt, es ist Aufgabe der Implementation diese gemäss den Angaben im Standard zu ergänzen.
Es steht nirgends, dass es Lücken und Platzhalter hat.

Das ist der einzige Ort, wo irgendetwas über den gezeigten std::map Code steht. Hier steht nicht, dass der gezeigte Code verbindlich ist. Es relativiert sogar den gezeigten Code um einiges.

Sebastian Pizer schrieb:

Absatz 8 --> Wenn ich mich richtig erinnere, hast Du diesen Absatz auch zitiert und das Hinzufügen von weiteren Defaultparametern als "Extension" gewertet. Der Standard fordert, dass Erweiterungen nicht das Verhalten von wohlgeformten Programmen ändern dürfen. Ein Programm, welches std::map als template-template-parameter mit 4 eigenen template parametern benutzen will, ist ohne diese Erweiterung wohlgeformt, mit aber leider nicht. Daraus schließe ich, dass eine konforme Implementierung keine zusätzlichen Defaultparameter für Klassentemplates einführen kann.

Das ist einfach nur falsch. Es ist nicht im Standard definiert, dass std::map genau 4 Templateparameter hat. Du hast mir dies ja auch immer noch nicht gezeigt.
Was du hier machst, ist rekursiv. Du definierst für dich, dass std::map genau 4 Templateparameter hat, obwohl es nirgends im Standard so steht, und mit dieser fehlerhaften oder nicht bewiesenen Annahme beweist du dir dann, dass std::map genau 4 Templateparameter haben muss.

Ich wiederhole mich nocheinmal:
BEWEISE MIR, DASS IRGENDWO IM STANDARD STEHT, DASS STD::MAP GENAU 4 TEMPLATEPARAMETER HAT.
(nicht als schreien auffassen, sondern als jedes einzelne Wort klar und deutlich ausgesprochen :D)

Denn du hast dies bisher nicht getan. Weil man dies nicht beweisen kann. Weil es nicht im Standard steht.

Grüssli

[Sebastian Pizer]

Dravere schrieb:

Ich wiederhole mich nocheinmal:
BEWEISE MIR, DASS IRGENDWO IM STANDARD STEHT, DASS STD::MAP GENAU 4 TEMPLATEPARAMETER HAT.

Ich mach hier gar nichts mehr. Wir drehen uns nur im Kreis. Zeitverschwendung.

Gruß,
SP

[Old McDonald]

Hier die Lösung:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#94

Library Working Group schrieb:

There is no ambiguity; the standard is clear as written. Library implementors are not permitted to add template parameters to standard library classes. This does not fall under the "as if" rule, so it would be permitted only if the standard gave explicit license for implementors to do this. This would require a change in the standard.

Allerdings war man sich wohl auch bei der LWG zunächst nicht sicher, ob der Standard weitere Templateparameter zulässt, wie man an der Bemerkung in eckigen Klammern sieht.

[Badestrand]

Ich gehe hier mit Sebastian Pizer konform. Der Satz "A conforming implementation may have extensions (...), provided they do not alter the behavior of any well-formed program." bedeutet für mich bei diesem (imo well-formed) Codestück

#include <map>
#include <iostream>

template< template<typename,typename,typename,typename> class T, class Key, class Elem, class Comp, class Allocator>
void whatever( T<Key,Elem,Comp,Allocator>& t )
{
	std::cout << "Gonna do peace and love\n";
}

template< template<typename,typename,typename,typename,typename> class T, class Key, class Elem, class Comp, class Allocator, class Additional>
void whatever( T<Key,Elem,Comp,Allocator,Additional>& t )
{
	std::cout << "Gonna destroy the world\n";
}

int main()
{
	std::map<int,int> m;
	whatever( m );
}

, dass eine std::map mit der Extension "zusätzliche, optionale Template-Parameter" das Verhalten verbotenerweise verändern würde. Daraus folgere ich (genauso wie auch Sebastian), dass zusätzliche optionale Template-Parameter bei std::map gemäß dem Standard nicht erlaubt sind.
Und nein, es steht nicht direkt im Standard, sondern indirekt, was aber deshalb nicht weniger gilt.

[Badestrand]

Ok, da hätte ich mir meinen Post ja sparen können. Aber gut, dass das jetzt klar ist.

[Dravere]

@Badestrand,
Dein Beweis zieht aber nicht. Schau dir mal an, wie du es beweisen willst:
(1) Du nimmst an, std::map hat genau 4 Templateparamter
(2) Du erstellst aufgrund dieser Annahme ein Well-formed Programm.
(3) Du nimmst eine std::map welche mehr als 4 Templateparameter hat.
(4) Dein Programm ist nicht mehr Well-formed .
(5) Daraus schliesst du, dass es 4 Templateparameter sein müssen.

Du hast aber nie die Nummer (1) bewiesen! Das ist eine Annahme ohne Beweis. Daher kannst du auch nicht davon ausgehen, dass das Programm well-formed ist. Dadurch funktioniert der Beweis in Nummer (5) nicht mehr.

Kann ja sein, dass ich wirklich falsch liege, nur ist der Beweis von Badestrand und Sebastian Pizer falsch. Da sie ihre ursprüngliche Annahme nicht beweisen. Ich möchte ja wirklich verstehen, wieso ich falsch liege. Aber das ist keine gültige Erklärung. Das ist kein Beweis.

Old McDonald schrieb:

Hier die Lösung:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#94

Library Working Group schrieb:

There is no ambiguity; the standard is clear as written. Library implementors are not permitted to add template parameters to standard library classes. This does not fall under the "as if" rule, so it would be permitted only if the standard gave explicit license for implementors to do this. This would require a change in the standard.

Allerdings war man sich wohl auch bei der LWG zunächst nicht sicher, ob der Standard weitere Templateparameter zulässt, wie man an der Bemerkung in eckigen Klammern sieht.

Kann mir einer den Teil ab "This does not fall under ..." erklären? Leuchtet mir nicht so ein, was die da reden. Wieso wird da plötzlich über eine Änderung im Standard geredet? In welchem Zusammenhang stehen diese Sätze?
Denn wenn man in den eckigen Klammern oben liest, dann ist dort die Frage, ob man sowas explizit erlauben möchte, was abgelehnt wurde. Man ist sich allerdings darüber einig, dass es eine Verdeutlichung brauche. Woraus ich persönlich schliesse, dass es nicht so klar im Standard steht.
In dem von Old McDonald zitierten Satz steht aber, dass es klar sei. Und es würde explizit im Standard stehen. Ich frage nochmals: Wo? Ich möchte doch nur wissen, wo? Ich finde es nämlich nicht.

Grüssli

[Badestrand]

Dravere schrieb:

(4) Dein Programm ist nicht mehr Well-formed .

Nene, das bleibt well-formed, nur das Verhalten des Programms ändert sich.

Irgendwie hab ich das Gefühl, du verrennst dich da etwas. Ich versuch's nochmal: In 23.3.1 ist die Deklaration von std::map vorgestellt, mit 4 Templateparametern. Und in dem hier viel-zitierten Absatz 8 aus 1.4 steht, dass der Library-Hersteller std::map gerne verändern darf, solange Programme dann noch genauso ablaufen. Genauso ablaufen wie ...? Ja, imo genauso ablaufen wie wenn das Interface aussieht wie im Standard.
So, das scheint mir eine halbwegs schlüssige Argumentation zu sein. Weil du ständig Beweise willst und wir dir nichts liefern können was dir gefällt, drehen wir den Spieß doch mal um: Erklär doch mal, was du wo und wie anders interpretierst oder mit welchen Schlussfolgerungen du nicht einverstanden bist. Sonst macht die Diskussion nämlich keinen Sinn.

[Dravere]

Badestrand schrieb:

Nene, das bleibt well-formed, nur das Verhalten des Programms ändert sich.

Ja, stimmt, aber nicht so wichtig, kommt dann trotzdem auf dasselbe raus.

Badestrand schrieb:

Ja, imo genauso ablaufen wie wenn das Interface aussieht wie im Standard.

Und nun kommt die Frage der Fragen:
Wo steht im Standard, wie das Interface genau auszusehen hat? Also wo steht, dass es explizit 4 Templateparameter sein müssen?

Badestrand schrieb:

Erklär doch mal, was du wo und wie anders interpretierst oder mit welchen Schlussfolgerungen du nicht einverstanden bist. Sonst macht die Diskussion nämlich keinen Sinn.

Das habe ich schon oft getan. Aber gerne nochmals, denn wenn ich von euch die entsprechende Geduld abverlange, dann von mir auch
- Ich aktzeptiere eure Schlussfolgerungen nicht, weil ihr einfach davon ausgeht, dass der präsentierte Code verbindlich ist. Dabei steht nirgends, dass dies der Fall ist. Ihr geht auch einfach davon aus, dass explizit 4 Templateparameter sein müssen, obwohl nirgends steht, dass es nicht mehr sein dürfen.
- Und interpretieren tue ich eigentlich überhaupt nichts. Ich sage nur, dass es nicht im Standard steht, dadurch nicht geregelt ist und deshalb erlaubt ist.

Grüssli

[Badestrand]

Gut, ich versuch's mal formaler, vielleicht kann ich mich damit besser ausdrücken

1. Im Standard ist eine Deklaration von std::map enthalten, mit vier Template-Parametern.
2. Es steht nirgendwo, dass std::map mit genau vier Template-Parameter deklariert sein muss.
3. Eine Standard-konforme Implementierung darf "Erweiterungen" zu den Deklarationen im Standard haben.
4. Das Vorhanden-sein dieser "Erweiterungen" darf das Verhalten von Programmen nicht verändern.
5. Das Verhalten von Programmen kann sich ändern, abhängig von zusätzlichen Template-Parametern für std::map.

1-2 sind logisch, 3-4 resultieren aus meinem Verständnis von 1.4.8 des Standards, 5 wurde dargelegt. Aus 4 und 5 folgere ich, dass zusätzliche Template-Parameter für std::map keine gültige "Erweiterungen" sind, std::map also deshalb genau vier Template-Parameter besitzen muss.

Ich könnte mir vorstellen, dass unsere Meinungen bezüglich der Erweiterungen divergieren. Ich bin der Meinung, dass die im Standard vorgestellten Deklarationen relativ verpflichtend sind, bis auf mögliche Erweiterungen eben. Und Code, der auf der Deklaration von std::map im Standard beruht, muss sich trotz eventuell vorhandener Erweiterungen identisch verhalten. Imo wäre z.B. eine zusätzliche non-const Version von "empty" eine gültige Erweiterung.

[Sebastian Pizer]

Badestrand schrieb:

1. Im Standard ist eine Deklaration von std::map enthalten, mit vier Template-Parametern.
2. Es steht nirgendwo, dass std::map mit genau vier Template-Parameter deklariert sein muss.
3. Eine Standard-konforme Implementierung darf "Erweiterungen" zu den Deklarationen im Standard haben.
4. Das Vorhanden-sein dieser "Erweiterungen" darf das Verhalten von Programmen nicht verändern.
5. Das Verhalten von Programmen kann sich ändern, abhängig von zusätzlichen Template-Parametern für std::map.

1-2 sind logisch, 3-4 resultieren aus meinem Verständnis von 1.4.8 des Standards, 5 wurde dargelegt. Aus 4 und 5 folgere ich, dass zusätzliche Template-Parameter für std::map keine gültige "Erweiterungen" sind, std::map also deshalb genau vier Template-Parameter besitzen muss.

Bravo!

Badestrand schrieb:

Imo wäre z.B. eine zusätzliche non-const Version von "empty" eine gültige Erweiterung.

Auf jeden Fall kann das Hinzufügen von Überladungen ein Programm ungültig machen. Beispiel:

void foo(int);   // #1
void foo(int*);  // #2 (neu hinzugefügt)

template<typename T>
void sink(T t) {}

void bar()
{
   void (*p)(int) = &foo; // OK, Zeiger auf #1
   sink(p);               // OK, T = void(*)(int)
   sink(&foo);            // Fehler, Mehrdeutigkeit
}

Ohne #2 kann Typ und Wert von &foo für sink(&foo) eindeutig bestimmt werden.

Gruß,
SP

[Old McDonald]

Und um das Bild noch zu vervollständigen, es gibt meiner Meinung nach noch zwei andere wichtige Stellen im Standard, die eine Rolle spielen.

Zunächst zur Bedeutung des C++-Codes:

ISO-C++ 17.5.2.3/6 schrieb:

In some cases the semantic requirements are presented as C++ code. Such code is intended as a specification
of equivalence of a construct to another construct, not necessarily as the way the construct must be
implemented.

Wenn man also etwas Gleichwertiges verwendet, das sich so verhält wie der präsentierte C++-Code, so kann man das tun. Was ist nun gleichwertig? Dafür gibt's die "as if"-Regel, die dort in der Erklärung der LWG genannt wird:

ISO-C++ 1.9/1 schrieb:

The semantic descriptions in this International Standard define a parameterized nondeterministic abstract
machine. This International Standard places no requirement on the structure of conforming implementations.
In particular, they need not copy or emulate the structure of the abstract machine. Rather, conforming
implementations are required to emulate (only) the observable behavior of the abstract machine as explained
below.

Solange also das, was beobachtet werden kann, sich gleichwertig verhält, ist es implizit erlaubt. Da es aber, sobald Template-Templateparameter verwendet werden, eben nicht mehr gleichwertig ist und sich das beobachtbare Verhalten ändert, sind weitere Templateparameter bei Standardbibliothekklassen verboten.

Weil das aber um ein paar Ecken herum implizit festgelegt wird, war das wohl eine gewisse Zeit lang nicht klar, ob nun weitere Templateparameter erlaubt sind. Ich kann mich auch daran erinnern, dass ich an verschiedenen Stellen gelesen habe, dass weitere Templateparameter möglich sind.

[hustbaer]

Deswegen haben die Standard-Jungs ja auch dazugeschrieben "agreed that clarification is required" (sinngemäss).
(siehe Link von dir)

[Dravere]

@Badestrand,
Es nützt nichts, wenn du nochmals das gleiche wiederholst, das ändert an meiner Kritik von Punkt 1 nichts. Du gehst davon aus, dass der Code verbindlich ist, ich sage, dass es nicht im Standard steht.
Wenn der Code nicht verbindlich ist, dann ist folgender Programm Code nicht well-formed :

#include <map>

template<template<typename, typename, typename, typename> class MapT>
struct Foo
{
};

int main()
{
  Foo<std::map> foo;
}

Dann gilt auch Punkt 4 nicht mehr, weil es nur das Verhalten von well-formed Programmen nicht verändern darf.

Um die Argumentation zu rechtfertigen, muss du Punkt 1 beweisen, also dass der Code verbindlich ist.

@Sebastian Pizer,
Was soll das nun mit den Überladungen? Das ist schon klar, aber darum geht es hier ja nicht.

@Old McDonald,
Danke! Du bist der erste, welcher in die richtige Richtungen geht
Allerdings so ganz verstanden habe ich es immer noch nicht. Ich wäre da echt noch froh, wenn mir jemand das übersetzen könnte, was die Leute vom Standard als Antwort hingeschrieben haben.

Allerdings überzeugen mich deine weiteren Argumente nicht so wirklich. Der Code muss gleichwertig sein, dass ist sehr wage, was damit gemeint ist. Wenn eine std::map einen zusätzlichen Templateparameter mit Defaultparameter hat, ist er meiner Meinung nach gleichwertig.
Später kommt dann diese Definition mit dem as-if . Und zwar steht dort, die Implementationen können die Dinge verändern, solange das Resultat den Anforderungen entspricht. Ist die Anforderung an std::map , dass sie genau 4 Templateparameter hat? Meiner Meinung nach eben nicht.

Ihr seid grauenhaft überzeugt davon, dass es ganz klar ist, da bin ich mir einfach nicht so sicher. Ich bin mir dagegen sehr sicher, dass die Standardleute es nicht so gewollt haben. Also grundsätzlich wollten sie nicht, dass jemand zusätzliche Templateparameter in seiner Implementation dazufügt. Allerdings schliesst dies meiner Meinung nach der formulierte Standard nicht ganz aus.

Naja, der nächste Standard steht vor der Tür. In diesem soll es klarer sein und zusätzlich kann man sich dort mit Variadic Templates Abhilfe schaffen

Grüssli