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 boost::filesystem::detail::status_api(class 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.
Uli _______________________________________________ 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.