3. Problem mit Loki

Problem mit Loki

  • D

    Also wenn ich mir mal die VC Version von SmartPtr.h in Zeile 783 ansehe...

    template
    <
        typename T,
        class OwnershipPolicy,
        class ConversionPolicy,
        class CheckingPolicy,
        class StoragePolicy
    >
    class SmartPtr
        : public StoragePolicy::In<T>::type
        , public OwnershipPolicy::In<typename StoragePolicy::template PointerType<T>::type>::type
        , public CheckingPolicy ::In<typename StoragePolicy::template StoredType<T>::type>::type
        , public ConversionPolicy
    {

    ... muss ich feststellen, dass z.B. StoragePolicy, in unserem Fall ja Loki::RefLinked, kein "In" kennt... :| :| :|

    So kann des ja auch nicht funktionieren... Oder sehe ich da was falsch???

    0
  • ?

    habt ihr überhaupt den VC7 Port genommen oder die normale Version?

    0
  • D

    Je nach Compiler wird automatisch geswitched..

    #ifdef LOKI_USE_REFERENCE
#   include "Reference/SmartPtr.h"
#else
#   if (__INTEL_COMPILER)
#       include "Reference/SmartPtr.h"
#   elif (__MWERKS__)
#       include "Reference/SmartPtr.h"
#   elif (__BORLANDC__ >= 0x560)
#       include "Borland/SmartPtr.h"
#   elif (_MSC_VER >= 1301)
#       include "Reference/SmartPtr.h"
#   elif (_MSC_VER >= 1300)
#       include "MSVC/1300/SmartPtr.h"
#   elif (_MSC_VER >= 1200)
#       include "MSVC/1200/SmartPtr.h"
#   else
#       include "Reference/SmartPtr.h"
#   endif
#endif

    mit anderen Worten "Ja" *g*

    [ Dieser Beitrag wurde am 24.04.2003 um 00:07 Uhr von DerSensemann editiert. ]

    0
  • D

    Ok, das scheinen also 2 verschiedene Fehler gewesen zu sein...

    Der VC Fehler scheint oben zu liegen... Ob des nu ein Fehler im Loki Code ist oder unserer weiß ich nicht...

    Der andere Fehler vom Intel Compiler wird von was anderem hervorgerufen.. Und zwar von der CreateStatic Policy aus Singleton.h (verwendet von SmallObj.h, verwendet von SmartPtr.h und Functor.h)

    Dort heißt es:

    template <class T> struct CreateStatic
    {
// ...
        union MaxAlign
        {
            char t_[sizeof(T)];
            short int shortInt_;
            int int_;
// ... noch weitere Typen ...
        };
// ...

        static T* Create()
        {
            static MaxAlign staticMemory_;
            return new(&staticMemory_) T;
        }

        static void Destroy(T* p)
        {
            p->~T();
        }
    };

    Soo, das ganze nun getestet in einem eigenen Programm:

    Folgenden Code habe ich in eine eigene Headerdatei geschrieben:

    template<typename T>
    class Test
    {
    public:
        union MaxAlign
        {
            char t_[sizeof(T)];
            short int shortInt_;
            int int_;
            long int longInt_;
            float float_;
            double double_;
            long double longDouble_;
        };

        void TestIt()
        {
            static MaxAlign t;
            t.int_ = 0;
        }
    };

    und dann

    Test<int> test;
test.TestIt();

    jeweills in 2 verschiedene Cpp Files zum Testen... Resultat: Erfolg...

    ABER: Ändere ich die Struktur MaxAlign um in:

    union MaxAlign
        {
            char t_[sizeof(T)];
            short int shortInt_;
            int int_;
            long int longInt_;
            float float_;
            double double_;
            long double longDouble_;
            struct TestX;
            int TestX::* pMember_;
            int (TestX::*pMemberFn_)(int);
        };

    kommt folgender Fehler:
    ABC error LNK2005: "union Test<int>::MaxAlign `public: void __thiscall Test<int>::TestIt(void)'::`2'::t" (?t@?1??TestIt@?$Test@H@@QAEXXZ@4TMaxAlign@2@A) already defined in test1.obj

    ... Und genau das selbe passiert im CreateStatic Policy in Singleton.h

    Intel Compiler Fehler? Mein Fehler? Lokis Fehler?

    [ Dieser Beitrag wurde am 24.04.2003 um 00:51 Uhr von DerSensemann editiert. ]

    0
  • D

    Shitmist, mit dem VC lässt sich der TestCode erstellen >( *grummel*

    Wäre also die Frage, wieso der Intel bei dem Code meckert bzw. wie ich den Fehler am besten kille... Ich könnte ja theoretisch die 3 Zeilen auskommentieren aus Loki... hmpf...

    0
  • D

    Ok, wenn ich die Zeilen 196 und 197 aus der aktuellen Singleton.h von http://sourceforge.net/projects/loki-lib (die letzte Version ist übrigens vom 12. April 03)

    int Test::* pMember_;
            int (Test::*pMemberFn_)(int);

    auskommentiere wird der Code vom Intel Compiler wieder übersetzt..

    Das ist weder elegant, noch gefällt mir diese Lösung.. Hat wer andere Vorschläge hierzu oder zu Posting #6?

    0
  • C

    Also im IntelCompiler stellt sich unter dieser Konfiguration der Fehler ein:

    Test.h

    #ifndef TEST_H
#define TEST_H
#include <Functor.h>
#endif

    File1.cpp

    #include "Test.h"

int funcb()
{
    return 0;
}

void func()
{
    Loki::Functor<int> test = funcb;
}

    File2.cpp

    #include "Test.h"

int funca()
{
    return 0;
}

int main()
{
    Loki::Functor<int> test2 = funca;
    return 0;
}

    Und letztendlich noch die beiden cpp Dateien in Loki ins Projekt einfügen
    Loki.cpp

    #ifdef LOKI_USE_REFERENCE
#   include "Reference/Singleton.cpp"
#   include "Reference/SmallObj.cpp"
#else
#   if (__INTEL_COMPILER)
#       include "Reference/Singleton.cpp"
#       include "Reference/SmallObj.cpp"
#   elif (__MWERKS__)
#       include "Reference/Singleton.cpp"
#       include "Reference/SmallObj.cpp"
#   elif (__BORLANDC__ >= 0x560)
#       include "Borland/Singleton.cpp"
#       include "Borland/SmallObj.cpp"
#   elif (_MSC_VER >= 1300)
#       include "MSVC/1300/Singleton.cpp"
#       include "MSVC/1300/SmallObj.cpp"
#   elif (_MSC_VER >= 1200)
#       include "MSVC/1200/Singleton.cpp"
#       include "MSVC/1200/SmallObj.cpp"
#   else
#       include "Reference/Singleton.cpp"
#       include "Reference/SmallObj.cpp"
#   endif
#endif

    Dem VC bereitet das alles keine Probleme !
    Der hat allerdings an einer anderen Stelle ein Problem.
    Simples Beispiel:

    #include <SmartPtr.h>

int main()
{
    Loki::SmartPtr<int, Loki::RefLinked> test;
    return 0;
}

    'RefLinked' : class template invalid as template argument for template parameter 'OwnershipPolicy', expected a real type

    Anscheinend hat er ein Problem mit dem WrapTemplate SmartPtr.h ll.712

    Nachtrag:
    Beim VC taucht das ganze nur auf wenn man den zweiten (und/oder weitere) template Parameter explizit mit angibt ...
    Wenn man die DefaultWerte nimmt klappt es !

    Es klappt auch so !!!

    Loki::SmartPtr<int, Loki::WrapTemplate<Loki::RefLinked>, Loki::DisallowConversion, Loki::WrapTemplate<Loki::RejectNull> > test;

    Also wenn man WrapTemplate als Policy übergibt. Wäre zumindest nen Workaround, aber nicht wirklich das wahre !!! Erkennt jemand das Problem generell ???
    Wir können doch nicht wirklich zu blöd sein die Loki-lib zu verwenden !!!!

    [ Dieser Beitrag wurde am 24.04.2003 um 14:39 Uhr von ChaosAngel editiert. ]

    0
  • H

    Hallo,
    ich denke das Beste wäre, wenn ihr einfach mal im Hilfe-Forum der Loki-Seite fragen würdet. Ich könnte euch nur bei Problemem mit dem VC 6 Port helfen und scheinbar gibt es hier nicht soviele Leute die Loki mit dem VC 7 einsetzen.

    0
  • C

    Werden wir dann ja wohl müssen, allerdings sieht es nicht so aus als ob man dort schnelle Hilfe erwarten kann 😞

    PS: Hab hier noch nen kleinen Workaround für den VC7 und SmartPointer, allerdings nicht wirklich edel 😃

    #include <SmartPtr.h>

using namespace Loki;

template< typename T,
          template<typename> class OwnerShipPolicy = RefCounted,
                             class ConversionPolicy= DisallowConversion,
          template<typename> class CheckingPolicy = AssertCheck,
          template<typename> class StoragePolicy = DefaultSPStorage
        >
    struct SmartPointer
    {
        typedef SmartPtr<T,WrapTemplate<OwnerShipPolicy>,ConversionPolicy,WrapTemplate<CheckingPolicy>,WrapTemplate<StoragePolicy> > impl;
    };

    Zu benutzen wäre der SmartPointer dann so...

    SmartPointer<int,Loki::RefLinked>::impl test;

    Aber wenn das Ding auf verschiedenen Compilern laufen soll stört das impl doch irgendwie ...

    0
  • C

    Mit dem Port den Shade oben genannt hat funktioniert es nun für den VC7 ...
    Allerdings immernoch nicht für den Intel 7.0 ... 😞 Falls jemand da also nen Port kennt ?

    Nachtrag:
    Falscher Alarm ... Sorry, funktioniert doch nicht der Port ... hatte Intel zum Compilieren eingestellt, und der hat ja nen anderes Problem, einfache SmartPointer funktionieren dort ja 😞

    erneuter Nachtrag:
    Das geheimnis um den VC port wäre gelöst. Beim VC 7 muss man SmartPtrDef<bla,bla>::type benutzen statt dem normalen SmartPointer ...
    Is der gleiche Fix den ich oben geschrieben habe nur das er in beiden Ports schon drin stand. Nur leider nicht das man ihn auch benutzen soll (eine Kommentarzeile im Code, verdammt versteckt)

    Nunja, das ganze ist dann zwar sehr inkompatibel mit anderen Compilern und mit dem Intel funktioniert es immernoch nicht (dort gibts übrigens auch kein SmartPtrDef, da funzt "nur" der normale SmartPtr)

    [ Dieser Beitrag wurde am 24.04.2003 um 16:07 Uhr von ChaosAngel editiert. ]

    0
Anmelden zum Antworten