Re: [boost] Re: Re: Re: Filesystem library updated

From: Alan Bellingham (alan_at_[hidden])
Date: 2002-07-19 08:07:20

"Anthony Williams" <anthony_w.geo_at_[hidden]>:

>Which, though it looks harmless, might affect a program that uses the
>windows API --- previously CharLower named a single function, but now it
>names an overloaded set. e.g.
>
>_bstr_t fileName;
>
>CreateFile(fileName,GENERIC_READ,0,NULL,OPEN_EXISTING,0,NULL); // oops, now
>ambiguous
>
>This is a problem, because _bstr_t has both char* and wchar* conversion
>operators.

Well, three possibilitites:

a) the programmer doesn't define ALLOW_OVERLOAD [*] (thereby not
   enabling, yes, the overloads) 
b) she uses a static_cast<>() to resolve the ambiguity, 
c) she explicitly uses CreateFileA() or CreateFileW() as desired.

Given that the first option would be the default behaviour, I'd
recommend this to anybody doing project conversion. As you and Bill
point out, this leads to the least surprise.

The third option would seem strange  - why is she having to do this when
using a _bstr_t, but not other types?.

(_bstr_t is a surprisingly old-fashioned design - not only does it have
implicit conversion to both char* and wchar_t *, but it constructs
implicitly from both.)

The second option is what I'd be doing, since I like the overloading. I
do have predefined constants equal to static_cast<char const*>(0) and
static_cast<wchar_t const*>(0), though.

Alan
[*] See <19ndjuk7pior6avom6s0dlf2f7pd88h2f4_at_[hidden]>, 2002-07-18