[boost] Re: Re: [Config] proposal of new macro, BOOST_DECL :follow up for boost::noncopyable & vc7.1 & dll

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-11-05 14:29:53

I've had to deal with this to some extent in the serialization library.   I
used decl export to guarentee the instantiation of code not referenced
explicitly by name which some compilers will optimise out.  (Its not clear
to me whether or not this is standard conforming behavior).  In any case I
made a header boost/serialization/force_include.hpp which handles the legal
combinations for the compilers I've been testing on.   I had a lot problem
with this and it seems to work - but I'm not really happy with it. Anyone
who wants to comment on this is welcome to do so.

Robert Ramey

"Michael Glassford" <glassfordm_at_[hidden]> wrote in message
news:cmgiqh$2vu$2_at_sea.gmane.org...
> "John Maddock" <john_at_[hidden]> wrote in message
> news:02c501c4c329$f3b9c4d0$38eb0352_at_fuji...
> >> It has been suggested to me that it would be better (for other
> >> reasons) to mark individual member functions as exported rather
> >> than marking whole classes. Would that also help in this situation?
> >> I haven't looked closely yet, but if the individual member
> >> functions of the thread classes are exported then this warning may
> >> no longer be generated.
> >>
> >> Would there be any problems with changing to this approach?
> >
> > Is it supported by all compilers that use __declspec(dllexport)?
> > What happens on 64-bit platforms, do we have different class layouts
> > for exported and non-exported classes (like we used to on Win-16)?
> > I'm assuming that there is some kind of logic for the warning being
> > issued in the first place, or maybe not?
>
> I'm afraid I don't currently know the answers to these questions. I
> was hoping someone else here would be able to answer questions like
> these.
>
> Mike
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>