From: Minmin Gong (gongminmin_at_[hidden])
Date: 2007-05-20 10:34:03
Ulrich Eckhardt wrote:
> On Saturday 19 May 2007 10:41:31 Minmin Gong wrote:
>> If calling convention is changed to __stdcall in vc8
> You mean you changed the default calling convention? This is a recipe for
> disaster, because it changes the interface of every function not explicitly
> given a different calling convention. At the very least, it means you need to
> recompile all of the filesystem lib with equal settings.
>> link error like this: error LNK2019: unresolved external symbol "class
>> boost::filesystem::file_status __stdcall
>> std::basic_string<wchar_t,struct std::char_traits<wchar_t>,class
>> std::allocator<wchar_t> > const &,unsigned int &)" ...
> There's another possibility though: Looking at operations.cpp, the wchar_t
> version of that function is only compiled when BOOST_FILESYSTEM_NARROW_ONLY
> is not defined. Why that would change with the default calling convention is
> beyond me though.
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
My fault. The line 5 should be "boost::filesystem::wpath p(L"a.txt");"
so it's not because of wchar_t.
Yes I changed the default calling convention in my app but not changed
it in boost.filesystem. I just wonder if all the functions in
filesystem's interface can be declared explicitly to __cdecl to prevent
from this situation.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk