Boost logo

Boost :

From: jorg.schaible_at_[hidden]
Date: 2000-03-17 07:47:33

Just to add:

You cannot export a class from a DLL having member function templates
(especially not implicit, i.e. you cannot use a shared_ptr inside an
exported class), since the compiler claims to import any new template
instance from the original DLL, that is - as you might have expected -
not possible :((

At least my recommendation is: Do not activate the member function
templates for boost, MSVC is too bad ...


---------------------------------------- Message History

From: mborgerding_at_[hidden] on 17/03/2000 03:22

Please respond to boost_at_[hidden]

To: boost_at_[hidden]
Subject: [boost] Re: MSVC template weirdness, was Questions

Gavin Collings wrote:

> > VC++ has some limitations on member template support.
> >
> > Argh! There is an email sitting in my "Boost Action Needed" folder
> > from Mark Borgerding with VC++ workarounds. I need to apply them.
> > That isn't the only fix pending; I will try to work through the
> > backlog in the next few days.
> Mark,
> It sounds like you're the VC++ member template expert :) I'd be
> interested to know if you've been able to characterize exactly when
> they do and when they don't work. My own experience is that there's a
> rough correlation with code complexity but little else. The worst
> problem I've come up against, though, is silently compiled valid code
> which does nothing at run time. Something for anyone putting in
> work-arounds to be wary of - successful re-compilation is definitely
> not a guarantee of a successful work-around.

Well, I don't claim to be an expert, but there are a few things that pop
mind when dealing with MSVC's template "quirks".

1) member template functions work only when defined inside the class
definition -- compile error

2) template versions of assignment and copy construction functions must
defined before the non-template versions. -- ( weird ) compile error

3) explicit template specialization is allowed, but not partial
specialization-- compile error

4) function templates that do not have an argument that tells the
which specialization to use cannot be reliably called, -- RUNTIME error
        template <class T> T* makenew() {return new T();}
        template <> int * makenew<int>() {return new int(0);}
    If I were to explicitly call
        int * pI = makenew<int>();
    I believe the generic version would be called.
     This is really ugly because of it misbehaves so silently. I
avoid function templates that need to be specialized. I usually create
temporary template objects for the specializations I need. The
functionality is the same, it just tends to clutter up the code a bit.
above example would become
        template <class T> struct makenew{ T* operator () () { return
T();} };
        template <> struct makenew<int>{ int * operator() () {return
int(0);} };
       int * pI = makenew<int>()();

5) I seem to recall some trouble using static data within static methods
template classes. --RUNTIME error
I somehow got multiple definitions of the static data in different
libraries or different translation units (I can't remember which). This
was a bastard of a bug to find. I don't know if I could re-create it if
tried. I think the problem was something like the following that
in multiple translation units.
    template <class T>
    class singleton
        static T & instance() {
            static T t;
            return t;

To the best of my knowledge, all of these are true with 6.0. I haven't
tried some of them since earlier versions, and I don't have MSVC at
only work.

Has anyone found any other oddities dealing with MSVC and templates?

-- Mark

Get $50 free postage.
Print postage from your PC with E-Stamp.
Click here to sign up.

-- Check out your group's private Chat room

Boost list run by bdawes at, gregod at, cpdaniel at, john at