[boost] Re: More on Serialization Link Issue

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-02-07 18:20:42

Jared McIntyre wrote:

> Honestly, I'm not sure why
> I can wstring working in the demo code, but not my code.  It might
> have to do with wchar_t not being set as a built-in type, but I've
> been unable to validate that since my codebase won't work that way.

That is a very curious circumstance.  FYI the msvc 6 compiler uses a 16 bit
int as wchar_t and it all still works (except for a bunch if compilers
ICE's - but thats another problem)

I don't know which compiler you're using.  I havnt built the package with
out wchar_t being its own type with VC 7.1

The best I can do is to provide demos and tests that I know work so that
they can be used as a basis for comparison.

If your building the libraries with bjam for VC 7.1 then they are going to
be build with wchar_t as its own separarte real type.  If you then go build
your own executable with wchar_t set up to be an identical type to 16 bit
integet then you won't be able to link with the library as the function
prototypes won't match up.  That is f(wchar_t x) in the library isn't going
to be the same as f(wchar_t x) in your program and you're going to get
linker errors. Of course building the demos with bjam wouldn't manifest this
problem.

If you do discover that this is indeed the problem, you would have two
choices:

a) rebuild the libraries with wchar_t set to be the same as a 16 bit
integer.
b) alter your app to use wchar_t as an intrinsic type.

Personally I would recomment the latter.  VC 8.0 uses wchar_t as an
intrinsic type so you're going to be on the losing side of the tide of
history if you don't make the change.  Your program will be more correct and
more portable as well.  And you'll have less problems like this in the
future..

Of course, I'm just speculating as to what the problem is - your free to
ignore this if its doesn't apply.

Robert Ramey