Martin Zeng wrote:
Hi John,
Thanks for you help, and now my MFC is compiling without the link error. There are still some things I would still like to know.
I noticed that just by including the libs/regex/src/winstances.cpp file is enough to get rid of the the error
LNK2005: "public: static unsigned int __cdecl std::char_traits<unsigned short>::length(unsigned short const *)" (?length@?$char_traits@G@std@@SAIPBG@Z) already defined in msvcprtd.lib(MSVCP71D.dll)
so I was just wondering is it ok just to add only the winstances.cpp to my source directory as opposed to adding the entire libs/regex/src directory?
Probably :-)
I ask this because my static library was created with using stdafx.h (precompiled header), so I had to copy over the winstances.cpp file into my project directory and put in #include "stdafx.h" at the top as opposed to just referring to the libs/regex/src/winstances.cpp file directly. I prefer not to do this to every single file in the libs/regex/src directory if I don't need to include them anyway.
Also, what is the cause of this link error. Does it have anything to do with VC++ compiler and how it ignores inline directives in debug mode as this person seems to suggest: http://aspn.activestate.com/ASPN/Mail/Message/2509074
In my experience, it seems that by having: boost::wregex expression(L"[ab]"); will cause the link error to happen. Is there going to be a fix for this problem?
I hope it's fixed for Boost-1.34, but it's hard to test every possible build combination, so it's hard to be 100% sure :-( The problem is caused by certain template instances being declared as extern in the std lib headers (they're instantiated in the C++ runtime). Unfortunately, the std lib headers only declare *either* the unsigned short or wchar_t versions of these as external, even though the std lib actually contains *both*. In order to be link-compatible with as many build options as possible Boost.Regex instantiates *both* unsigned short and wchar_t variants of it's templates, but then when you build with certain specific build options this causes a conflict with the std lib :-( Basically I've made life easier for 90% of users, at the expensense of the 10%. The problem could be solved reduced but not completely solved by not putting any template instances in the lib, but that would be at the expense of some code-bloat and much longer compile times - currently compiling with Boost.Regex placed in a pre-compiled header is more or less instantanious, and I'd like to keep that if at all possible. HTH, John.