We have recently had some wierd problems with stringstream on MSVC6.0
Some of the uses of stringstream in our internal code started giving the multiply defined symbol
errors for some of the hidden objects in sstream.h (e.g. stringbuf::stringbuf(string))
LNK2005: "public: void __thiscall std::basic_stringstream<char,struct std::char_traits<char>,class
std::allocator<char> >::`vbase destructor'(void)"
(??_D?$basic_stringstream@...?$char_traits@...@std@@V?$allocator@...@2@@std@@QAEXXZ) already defined in
They started sometime between three weeks and five days ago, but I can't track it down more
accurately than that, largely because the errors appears somewhat intermittently. Nevertheless, I
can't see any changes to vcl in that time period that are obviously related.
Each case can be locally solved by tracing the #includes and making sure that <vcl_sstream.h> is
included before <vcl_string.h> However, this is a very tedious, and not very robust solution. It
doesn't happen for every use of stringstream, and my attempts to produce a cut down version of a
file that displays the problem have completely failed.
Has anyone else had any similar problems, made any mods in VXL that might be relevent, or got any
This is nothing but a wild guess: perhaps the explicit instantiations
in vcl are interfering somehow? (Or explicit instantiations somewhere?)
Since vcl uses implicit instantiations by default, I think all the
explicit instantiations can be safely removed. (I.e., the
AUX_SOURCE_DIRECTORY in vcl/CMakeLists.txt can be commented out.) I've
done so for my local build, and nothing seems to be broken. I haven't
made a commit, because I don't have the time right now to deal with
any potential problems.
From: Peter Vanroose <Peter.V<anroose@es...> - 2003-02-28 20:17:44
> Has anyone else had any similar problems, made any mods in VXL that might
> be relevant, or got any suggestions.
The first suggestion that I can think of: try to avoid using stringstream