typename sagt, dass der abhängige Name ein Typ ist, gut. Aber irritiert bin ich noch von T::template. Das sagt, dass der abhängige Name ein Template ist, aber mich stört das etwas. Man würde ja sagen:

T::template C<int> z;  // decreed template (Code von zwei verschiedenen Stackoverflow-Threads)

in einer Funktion/Klasse/..., die T als Templateparameter erwartet. Es wird also gesagt: C ist ein Template. Also ist der Bezug des template-Schlüsselwortes quasi:

(T::template C)<int> z; // mir geht es hier nicht um korrekte Syntax, sondern wie gesagt um den Bezug

Schließlich ist C<int> kein Template, sondern ein Typ.

Wenn ich jetzt aber eine nested Klasse habe:

template<typename T> 
struct outer 
{ 
	template<typename U> 
	struct inner 
	{ 
	}; 

	template<typename U>
	inner<U> createInner(); 
}; 

template<typename T> 
template<typename U>
typename /* <-- dort! */ outer<T>::inner<U> outer<T>::createInner() 
{ 
	return inner(); 
}

, so wird dort offensichtlich ein typename verlangt. An dieser Stelle soll ich also inner<U> als Typ klassifizieren, nicht aber inner als Template (was in Codefetzen 1 genau umgekehrt war). Das wirkt für mich inkonsequent, wobei es das mit Sicherheit nicht ist. Welches Detail führt dazu, dass man das hier anders ausweist?

Daran, dass da ein <U> steht, kann es nicht liegen, schließlich ist das in Codefetzen 1 ja auch der Fall. Auch bin ich nicht ganz sicher, welche Irritation für den Compiler man in Codefetzen 1 erledigt, was sollte C denn sein wenn kein Template? Eine Funktion? (ist Funktion ein anderes Tier als Wert/Typ/Template, oder zählt das als Typ? Wenn es als Typ zählt, könnte das doch auch wieder Rückgabe der Methode in Codefetzen 3 sein).

Vielen Dank im Voraus und beste Grüße!

An dieser Stelle soll ich also inner<T> als Typ klassifizieren, nicht aber inner als Template (was in Codefetzen 1 genau umgekehrt war).

Auch dort ist nat. das Schlüsselwort template erforderlich

template<typename T>
template<typename U>
typename outer<T>::template inner<U> outer<T>::createInner()
{
    return inner<U>(); 
}

oder

template<typename T>
template<typename U>
auto outer<T>::createInner() -> inner<U>
{
    return inner<U>(); 
}

error C2244: 'outer<T>::createInner': Keine Übereinstimmung für Funktionsdefinition mit vorhandener Deklaration gefunden
1> Definition
1> 'outer<T>::inner<U> outer<T>::createInner(void)'
1> Vorhandene Deklarationen
1> 'outer<T>::inner<U> outer<T>::createInner(void)'
1>
1>Fehler beim Erstellen

Lasse ich das template hingegen weg, so kompiliert es.

--

Variante2 gefällt mir natürlich am besten, hatte ich mir noch gar nicht angewöhnt, habe aber Mal einen Artikel über die "nachgelagerte return type"-Notation gelesen und mich gefreut, danke für den Hinweis.

Ist das dann MSVC10s Fehler?

Ja, template ist an dieser Stelle auch in C++03 erlaubt.

Ich korrigiere allerdings meine vorherige Aussage:
weder template noch typename sind an dieser Stelle erforderlich (aber einzeln oder zusammen zulässig), weil
outer<T>::inner ein member der current instantiation ist und damit bereits in der Templatedefinition
beim Namelookup gefunden und als Klassentemplate identifiziert werden kann.
Das ist allerdings für den Compiler schwer zu parsen (g++ weigert sich, clang hat kein Problem).
Da es beim flüchtigen Lesen auch verwirren kann, würde ich an dieser Stelle immer beide Schlüsselwörter verwenden.

ah, verstehe! Erfordert das dieselben Parse-Fähigkeiten wie z.B. hier:

class Test
{
    enum SomeEnum {A, B} enum;

public:
    SomeEnum GetEnum() const;
};

SomeEnum Test::GetEnum() const // will Test::SomeEnum
{
    return enum;
}

was bei mir auch nie kompiliert? Da erscheint die auto-Notation für Rückgabetypen ja fast auch als Reaktion darauf in den Standard aufgenommen worden zu sein, dass die Compiler "unfähig" (will nicht urteilen) sind (wobei ich damit natürlich nicht meine, dass das der einzige Vorteil dieser Notation ist).

Hi,

ah, verstehe! Erfordert das dieselben Parse-Fähigkeiten wie z.B. hier:

class Test
{
    enum SomeEnum {A, B} enum;

public:
    SomeEnum GetEnum() const;
};

SomeEnum Test::GetEnum() const // will Test::SomeEnum
{
    return enum;
}

was bei mir auch nie kompiliert? Da erscheint die auto-Notation für Rückgabetypen ja fast auch als Reaktion darauf in den Standard aufgenommen worden zu sein, dass die Compiler "unfähig" (will nicht urteilen) sind (wobei ich damit natürlich nicht meine, dass das der einzige Vorteil dieser Notation ist).

Dieses Beispiel ist definitv ill-formed und nicht vergleichbar (wobei ich verstehe, dass es wie ein verwandtes Problem aussieht). SomeEnum wird hier durch unqualifiziertes Lookup gesucht, und der Stadard ist klar, das erst nach dem Funktionsnamen (also ab der öffnenden Klammer, folglich funktioniert es auch hier mit einem trailing Returntyp) dieses Lookup im Scope der Klasse stattfindet.

"nachgelagerte return type"

trailing-return-type.

weder template noch typename sind an dieser Stelle erforderlich (aber einzeln oder zusammen zulässig), weil
outer<T>::inner ein member der current instantiation ist und damit bereits in der Templatedefinition
beim Namelookup gefunden und als Klassentemplate identifiziert werden kann.

Ich kann die Standardstelle nicht genau finden. Ich denke, es ist

[temp.dep.type]/1 schrieb:

A name refers to the current instantiation if it is
— in the definition of [...]a member of a class template [...] the injected-class-name (Clause 9) of the [...] nested class,

// will Test::SomeEnum

Jo, aber natürlich wird SomeEnum nicht gefunden. Ich finde, das würde auch sehr komisch sein, wenn das tatsächlich so funktionieren würde

Dieses Beispiel ist definitv ill-formed und nicht vergleichbar

dass die Compiler "unfähig" [...] sind

Ich denke, daran liegt es nicht. Wäre das so schwer, hätte man es aus dem Standard entfernt (wie export ).
Aber der Standard definiert es ähnlich:

A trailing-return-type is most useful for a type that would be more complicated to specify before the
declarator-id.

(camper meint übrigens die declarator-id)

Hat es besondere Gründe, dass beim Rückgabetyp kein ADL [...] greifen darf?

Ich dachte, ADL ist nur für Funktionsaufrufe und hat hier gar nix verloren - aber wie so oft kann ich mich ja auch irren

When the postfix-expression in a function call is an unqualified-id, other namespaces not considered
during the usual unqualified lookup (3.4.1) may be searched [...]

Hast Du dich jetzt bzgl. ADL geirrt oder nicht? Klingt für mich doch, als hättest Du damit recht gehabt. Hat hier wohl wirklich überhaupt nichts verloren.

Trotzdem erscheint es mir nach wie vor intuitiv, dass er auch im Klassenscope sucht, wenn es um den Rückgabetypen geht. Für mich gehört der einfach zur Methode dazu und die Methode gehört für mich zur Klasse. Bin ich da allein?

Der Rückgabewert wird aber bereits bei der ersten Deklaration der Funktion geparst und steht damit vor jedem Funktionsaufruf fest, bzw. bei der Instantiierung der entsprechenden Spezialisierung einer Funktion.

Edit: Du Schlingel! Hast ja die Anmerkung wegeditiert :p

Bleibt also nach wie vor nur meine Anmerkung:

Trotzdem erscheint es mir nach wie vor intuitiv, dass er auch im Klassenscope sucht, wenn es um den Rückgabetypen geht. Für mich gehört der einfach zur Methode dazu und die Methode gehört für mich zur Klasse. Bin ich da allein?

Bleibt also nach wie vor nur meine Anmerkung:

Trotzdem erscheint es mir nach wie vor intuitiv, dass er auch im Klassenscope sucht, wenn es um den Rückgabetypen geht. Für mich gehört der einfach zur Methode dazu und die Methode gehört für mich zur Klasse. Bin ich da allein?

Leider habe ich, und wahrscheinlich auch du, zu wenig Erfahrung um darüber eine vernünftige Aussage machen zu können. Ich sage mal pauschal nein, weil ich es erstens, wie camper, unübersichtlich finde. Und zweitens da ich denke dass das öfters, gerade bei Programmen die davon Gebrauch machen, zu Mehrdeutigkeit führen kann.*

*Natürlich ist das nur eine Qualifizierung nötig um alles wieder ins Lot zu bringen - aber dann haben wir dadurch auch nichts gewonnen.

Innerhalb einer Templatedeklaration sind diese Regeln auch einfach:
es sind die Gleichen (außer dass ein zweiter ADL-Pass ggf. erst bei der Instantiierung vorzunehmen ist).

Erfolgt eine Deklaration eines Members außerhalb der Klasse, so ist der lexikalische Scope der Deklaration (die bei Membern auch eine Definition sein muss) zu beachten, nur die Teile, die der deklarator-id folgen befinden sich im Scope der Klasse.

namespace foo
{
    struct bar
    {
        typedef int type;
        type fun();
    };
}
typedef char type;
type foo::bar::fun(); // ill-formed - type ist ::type

Sowohl im Nicht-Template- als auch im Templatefall muss also im Allgemeinen ein qualifizierter Bezeichner verwendet werden, wenn diese Syntax benutzt wird.

Wesentliche Unterschiede zwischen Nicht-Templates und Templates gibt es hingegen, wenn es um qualifizierte Bezeichner oder Memberzugriffe geht, und dieser Bezeichner von einem Templateparameter abhängt.
Im Wesentlichen:
Abhängige Bezeichner sind solche, die
1. von einem Templateparameter abhängig sind,
2. nicht Member der current instantiation sind (ich traue mich nicht das zu übersetzen, ich finde auch den englischen Begriff furchtbar)
Abhängige Bezeichner benötigen jeweils die Schlüsselworte typename oder template, wenn es sich um Typen bzw. Templates handelt, es sei denn der Kontext verbietet sie ausdrücklich. Bezeichner, die von einem Templateparameter abhängen aber keine Abhängigen Bezeichner sind (also Member der current instantitiation) dürfen, wenn der Kontext es erlaubt mit typename/template versehen werden (sowohl in C++03 als auch C++11) - und das ist gut so, weil man ggf. erst 10mal hinschauen muss, um die Unterscheidung machen zu können.
Und C++11 erlaubt typename/template ausserdem noch an fast allen anderen Stellen, an denen die Syntax es hergibt, insbesondere auch ausserhalb von Templates.

2. nicht Member der current instantiation sind (ich traue mich nicht das zu übersetzen, ich finde auch den englischen Begriff furchtbar)

Er ist auch nicht korrekt. Die Instantiierung ist ein Prozess. Was sie meinen ist die aktuell instantiierte Spezialisierung.

2. nicht Member der current instantiation sind (ich traue mich nicht das zu übersetzen, ich finde auch den englischen Begriff furchtbar)

Er ist auch nicht korrekt. Die Instantiierung ist ein Prozess. Was sie meinen ist die aktuell instantiierte Spezialisierung.

Das macht ihn furchtbar aber nicht inkorrekt.
Er wird so kursiv im Standard an dieser Stelle verwendet, was auf einen explizit definierten Begriff verweist (schließe ich mal, ich vermute das wird in einem der in 1.2 genannten Standards (2382 hab ich nicht) so vorgegeben, in 1.6 wird nur gesagt, was Kursivschrift innerhalb von grammatikalischen Spezifikationen bedeuten soll).

Deine Übersetzung geht in die richtige Richtungg, ist aber auch nicht korrekt. Weil des um Bezeichner innerhalb einer Templatedefinition geht. Nicht um die Instantiierung derselben (nat. ist da eine Verbindung).