LPCTSTR is not "from MFC".
I didn't say it is. I said this:
which it does, though it's the part that comes from ATL now. In
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
LPCTSTR is not "from MFC". It is part of the Windows base data types, and
it is simply a
typedef for const TCHAR *, and when TCHAR is resolved it is either const
char * or const
wchar_t *, and therefore is standard conforming to the C++ standard.
Since CArray is
defined in MFC, the operator LPCTSTR is of course defined by the class
(and therefore
defined by MFC) but in this case the phrase "and not by the standard"
makes no sense
because there is no standard that defines MFC.
The real problem is that they did not provide a template that accepts any
integral type as
a subscript.
joe
On Fri, 9 Mar 2007 09:13:14 +0900, "Norman Diamond"
<ndiamond@community.nospam> wrote:
"Tom Walker" <nobody@nowhere.com> wrote in message
news:uZGrxgbYHHA.944@TK2MSFTNGP06.phx.gbl...
[Norman Diamond:]
CString s = _T("ab");
short i = 1;
_TCHAR c = s[i];
Error C2666, ambiguous overload.
The compiler sees an ambiguity between these two possibilities:
_TCHAR c = s.operator[](i);
_TCHAR c = s.operator LPCTSTR()[i];
Thank you, though i am short of complete understanding. If i is changed
to
an int then it works. So disambiguation occurs before the integral
promotion, and disambiguation fails because the conversion from short to
int
ranks equally with the user-defined cast operator? ("user-defined" from
the
standard's point of view because operator LPCTSTR comes from MFC not from
the standard.)
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm