From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2002-07-19 10:38:46
"Alan Bellingham" <alan_at_[hidden]> wrote in message
> "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,
> >This is a problem, because _bstr_t has both char* and wchar* conversion
> 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
-- Anthony Williams Software Engineer, Nortel Networks Optical Components Ltd The opinions expressed in this message are not necessarily those of my employer
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk