Templates Portierungsprobleme Linux zu Windows

sjoe

Danke für die Antworten.

@pumuckl
Du meinst in Zeile 37 einfach folgendes hinschreiben:

VariableChildTreeIterator(weak_ptr<VariableChildTreeNode<S> > pWeakCurrNode, weak_ptr<VariableChildTree >  pWeakTree)

Geht leider nicht. Compiler meckert das er ausgehend von Zeile 56 keinen passenden Konstuktor mehr findet.

@drakon
Hm, im Kurztest funktioniert das erstmal. Ich werde mal unter Linux testen ob das auch dort funktioniert. Dann müsste ich allerdings sehr viel Code überarbeiten. Naja, so ist das Leben, mal verliert man und mal gewinnen die anderen.

Für andere Vorschläge bin ich offen.

Grüße, sjoe.

pumuckl

Ich sehs jetzt gerade erst - sicher dass das im Ctor vom iterator ein VariableChildTree<T> sein muss und kein VariableChildTree<S>? Wenn ich richtig liege braucht der Iterator dann allerdings garkeinen Zugriff auf die Interna des VCTree und kann sogar außerhalb der Klasse definiert werden.

sjoe

@pumuckl
Ja, das ist kein Schreibfehler. Der zweite Parameter ist bewusst von der Oberklasse abhängig. Also leider nichts mit auslagern.

Grüße, sjoe.

drakon

Bei Zeiten, werde ich mal im Standard nachschauen, welcher der beiden Compiler nicht standardkonform arbeitet. Aber wahrscheinlich wird das auf undefiniert hinauslaufen, obwohl ich eigentlich denke, dass das, was pumuckl meint doch auch gehen müsste..

pumuckl

drakon schrieb:

Bei Zeiten, werde ich mal im Standard nachschauen, welcher der beiden Compiler nicht standardkonform arbeitet. Aber wahrscheinlich wird das auf undefiniert hinauslaufen, obwohl ich eigentlich denke, dass das, was pumuckl meint doch auch gehen müsste..

Ggf. in der VCTree-Klasse T als value_type typedeffen bzw. VCTree<T> als tree_type typedeffen und den typedef in der Unterklasse nutzen.

sjoe

Ggf. in der VCTree-Klasse T als value_type typedeffen bzw. VCTree<T> als tree_type typedeffen und den typedef in der Unterklasse nutzen.

Unglaublich. Damit funktioniert es. Mal schauen ob das auch unter Linux läuft, aber diese Kleinigkeit kann man notfalls auch per ifdef erledigen.
Vielen Dank nochmals. Der Tip erspart mir eine Menge Arbeit.

Grüße, sjoe.

drakon

Ich habe jetzt im Standard nachgeschaut und nichts gefunden, was dagegen spricht. Dann bin habe ich gedacht, dass ich es selbst mal ausprobiere und das kompiliert bei mir wunderbar.. Sofern ich das hier auskommentiere:

friend class VariableChildTreeIterator<S>;

Ich benutze Visual C++ 2008EE.

camper

template <class T>
class VariableChildTree
{
...
    private:
        template<class S> class VariableChildTreeNode;
...
public:
        template <class S>
        class VariableChildTreeIterator
        {
            public:
...
                VariableChildTreeIterator(weak_ptr<VariableChildTreeNode<S> > pWeakCurrNode, weak_ptr<VariableChildTree<T> >  pWeakTree)
...
        }; // end class VariableChildTreeIterator
...
        friend class VariableChildTreeIterator<T>;

}; // end class VariableChildTree

Die Definition von VariableChildTreeIterator greift auf den in VariableChildTree private deklarierten Bezeichner VariableChildTreeNode zu, aber nur die Spezialisierung VariableChildTreeIterator<S> mit S=T ist friend von VariableChildTree<T>. Das ist möglicherweise ein Fehler, vermutlich aber nicht der Grund, weshalb der Compiler ins Stolpern gerät.

Ben04

Bei der Definition dessen auf das man von der inneren Klasse aus zugreifen kann ist der 98er Standard so weit ich weiß schlampig. (Das heißt er definiert gar nichts.) Im C++0x Standard wird so weit ich das überschauen kann das GCC Verhalten vorgeschrieben.

drakon

Ben04 schrieb:

Bei der Definition dessen auf das man von der inneren Klasse aus zugreifen kann ist der 98er Standard so weit ich weiß schlampig. (Das heißt er definiert gar nichts.) Im C++0x Standard wird so weit ich das überschauen kann das GCC Verhalten vorgeschrieben.

Er schreibt nichts spezielles vor. Sprich er besagt explizit, dass dieseleben Regeln, wie sonst gelten.

11.8 Nested classes schrieb:

The members of a nested class have no special access to members of an enclosing class, nor to classes or
functions that have granted friendship to an enclosing class; the usual access rules (clause 11) shall be
obeyed. The members of an enclosing class have no special access to members of a nested class; the usual
access rules (clause 11) shall be obeyed.

Ben04

Wie überall, heißt "kein Zugriff auf private Sachen". Zu mindest kann man das so auslegen und so wurde das auch gemacht. Man kann eine innere Klasse aber so weit ich weiß nicht legal friend machen, womit es keine Möglichkeit gibt den Zugriff zu erlauben. T ist jetzt zwar kein Member aber von Außen kann man trotzdem nicht drauf zugreifen. Ein public typedef T type und dann die Verwendung von type sollte aber pedantisch korrekt sein.