[Boost-users] Changes breaking behavior of operators /, /= and << in filesystem v3?

Subject: [Boost-users] Changes breaking behavior of operators /, /= and << in filesystem v3?
From: Roel Vanhout (roel.vanhout_at_[hidden])
Date: 2010-10-25 03:41:02

Hello,

I enabled filesystem v3 after upgrading to 1.44. The api changes that
caused the compiler to signal errors were rather easy to fix. However
when running my program, it behaves differently from the way it used
to. I narrowed it down to the following:

char buf[MAX_PATH];
HRESULT res = ::SHGetFolderPath(NULL, CSIDL_APPDATA, NULL,
SHGFP_TYPE_CURRENT, buf);
boost::filesystem::path result(buf);    // 'result' is after this
"C:\Documents and Settings\rvanhout\Application Data"
result /= "MyCompany";

At this point, 'result' *still* contains "C:\Documents and
Settings\rvanhout\Application Data" whereas with v2 it used to contain
"C:\Documents and Settings\rvanhout\Application
Data\MyCompany\MyProduct".

(environment: Windows (obviously) with VS 2008 (vc9))

There seem to be two way to get the desired behaviour:
  - initialize the path with a trailing slash, like this:
boost::filesystem::path result(buf + std::string("/"));
  - convert 'buf' into a std::string first:  std::string str(buf);
boost::filesystem::path result(str);

So I guess my code broke because the path is not initialized with the
platform's native path encoding (although std::string is char also and
it does work). Is this by design? It seems quite unintuitive to me.

Second thing I was bit by is that the io streaming operator now seems
to add quotes to a path with spaces in it when streaming a path object
to an ostringstream. The string that is returned with .string() isn't
quoted, of course, so my 'fix' is to not stream path objects anymore
but add the .string() call.

What's more important, is there a way to let the compiler signal these
situations in my code? The way it is now, everything compiles but I
have no way to know if it will actually work as it used to/should.
Otherwise, it might be an idea to add #pragma warning statements to
those parts for a release or two, to give people a heads up. Thanks.

regards,

Roel Vanhout