O
HumeSikkins schrieb:
otze schrieb:
[...]
template<class ContainerType,class Traits>
class tree::treeIterator{
public:
treeIterator& operator=(treeIterator Operand);
//treeIterator kann hier templateparameter haben, muss aber nicht-wieso?
};
Innerhalb der Klassendefinition einer Templateklasse ist der Name der Templateklasse (template name) äquivalent zur Template-Id (Name + Liste von Templateargumenten). treeIterator ist innerhalb der Klassendefinition also äquivalent zu treeIterator<ContainerType, Traits>.
Diese "Injezierung" des Namens einer Klasse in ihren Scope gibt es genauso bei normalen Klassen. Das ganze wird bei Templates aber natürlich etwas komplizierter.
ok, das wusste ich nicht
otze schrieb:
//iterator.cpp
template<class ContainerType,class Traits>
tree::treeIterator& tree::treeIterator<ContainerType,Traits>::operator=(treeIterator Operand){}
//der rückgabetyp darf hierbei keine parameter haben, die bereichsangabe(nennt man das so?) braucht aber unbedingt die Parameter
Das ist kein gültiges C++.
Der Rückgabetyp gehört hier nicht zum Scope der Templateklasse.
der bcb 6.0 erlaubt es mir aber nicht so,wie es richtig wäre,deshalb wundere ich mich ja
template<class ContainerType,class Traits>
tree::treeIterator<ContainerType, Traits>& ...
Alles *nach* dem Scope-Operator (also nach tree::treeIterator<ContainerType,Traits>::) bezieht sich wiederum auf den Scope von treeIterator. Hier ist der Name der Klasse wieder äquivalent zur Template-Id und damit treeIterator äquivalent zu treeIterator<ContainerType, Traits>.
das wusste ich
wieso kann ich bei der deklaration des operators wählen,ob ich templateparameter benutzen will oder nicht, wieso darf ich sie im rückgabetyp der definition nicht benutzen
Du darfst sie nicht nur benutzen, du *musst* sogar. Wenn dein Compiler das auch ohne erlaubt, ist das ein Fehler deines Compilers.
cool, der bcb 6.0 hat fehler
standard gesgat:kommt,lasst die programmierer ruhig mal ne stunde rumprobieren,machts so unlogisch und uneinheitlich wie möglich
Bitte schieb dein Unverständnis jetzt nicht anderen in die Schuhe. Die Regeln sind zwar komplex, dennoch aber logisch und in sich geschlossen.
die regeln kenn ich ja, und die sind auch logisch, ich habs auchs chon 100 mal vorher gemacht, nur nie mit nested klassen, und da wars halt unlogisch(aber auf dem compiler basierend)
darf ich die schuld denn nun auf den compiler schieben?
