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