From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2002-07-19 10:38:46
"Alan Bellingham" <alan_at_[hidden]> wrote in message
news:5lifjug55pn43fefap7l8r3nt47jcn5hvm_at_4ax.com...
> "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.
These are all valid workarounds. I think I prefer option 1, but I wouldn't
like to maintain the de-macro-fying header, given that MS changes/extends
the API every few months...
Also, as Gennaro pointed out in another post, the MFC and ATL classes have
members that _pretend_ to be called MessageBox, GetWindowText... If you make
these real names, and not macros, then you will probably meet
problems.somewhere.
Anthony
-- Anthony Williams Software Engineer, Nortel Networks Optical Components Ltd The opinions expressed in this message are not necessarily those of my employer