Hello Carsten,
Thanks for your time. I hoped it would be something simple, something
someone else has already stumbled upon ...
But did anybody ever try this? My FC-derived classes are in a Lib which is
then statically linked to the app, but the OpenSG DLLs are dynamically
linked. I don't quite understand why the error message says something about
missing dllimport, that just doesn't make sense.
However, I tried explicit template instantiation like this:
#define OSG_INSTANTIATE_PTR(CLASST) \
template class TransitPtr < CLASST > ; \
template class MTRefCountPtr< CLASST, \
NoRefCountPolicy > ; \
template class RefCountPtr < CLASST, \
RecordedRefCountPolicy > ; \
template class RefCountPtr < CLASST, \
UnrecordedRefCountPolicy> ; \
template class RefCountPtr < CLASST, \
WeakRefCountPolicy > ; \
template class MTRefCountPtr< CLASST, \
RecordedRefCountPolicy > ; \
template class MTRefCountPtr< CLASST, \
WeakRefCountPolicy > ;
OSG_BEGIN_NAMESPACE
OSG_INSTANTIATE_PTR(Type1)
OSG_END_NAMESPACE
Which interestingly doesn't compile and complains about it could not deduce
a template argument. See OSGRefCountPolicies.h, struct NoRefCountPolicy,
line 198:
template<class T, class U>
static void convertTransitPtr(T *&pOut, T *&pIn)
{
OSG_ASSERT(false);
}
Is that really correct, or should it be U*& pIn ?
Aloha, Andi
> -----Original Message-----
> From: Carsten Neumann [mailto:[email protected]]
> Sent: Dienstag, 24. November 2009 20:54
> To: [email protected]
> Subject: Re: [Opensg-users] FieldContainer derived class problem?
>
> Hello Andreas,
>
> Andreas Halm wrote:
> >> Anyway, if including OSGAtom.h does not help, I'm wondering if there
> is
> >> perhaps some problem with the dllimport/dllexport decoration. Both
> your
> >> types live in MyLib, does the compiler get the OSG_COMPILEMYLIB
> define
> >> passed on the command line? Is the OSGMyLibDef.h file correctly
> setting
> >> up the dllimport/dllexport defines?
> >
> > That is definitely not the problem, my lib is linked statically with
> the
> > application. Only the OSG dlls are used dynamically.
>
> ok. hm, as you said earlier, the operator in question is defined and
> inline so if the compiler does not complain about it the linker should
> not either. Perhaps looking at the preprocessed source of
> OSGResidue.cpp/OSGResidueBase.cpp could give a clue (at least it should
> reveal if the relevant headers are really seen).
> Perhaps putting an inline in front of the operators declaration in
> class
> PointerMFieldBase would help too, i seem to recall weird behaviour of
> the MS compiler wrt to inlined functions before and that seemed to help
> for some reason.
> Sorry if these suggestions sound a bit helpless, but I'm running out of
> ideas for this problem. For sure MFields of pointers to other
> FieldContainer are used in many places inside OpenSG, so this should
> work...
>
> Cheers,
> Carsten
>
> -----------------------------------------------------------------------
> -------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Opensg-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/opensg-users
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
