Boost :

gennaro_prota_at_[hidden]

---
"_WCHAR_T_DEFINED - Defined when wchar_t is defined. Typically,
wchar_t is defined when you use /Zc:wchar_t or when typedef unsigned
short wchar_t; is executed in code"
---
>>>Using VC++ 6.0 (no intrinsic wchar_t), and debug output:
>>>
>>>Test - Succeeded (line 270)
>>>Source type      = unsigned short (49)
>>>Destination type = int (1) (Should have been (1))
>>>
>>>As you can see, Intel C++, with and without intrinsic wchar_t, works as
>it's
>>>supposed to. VC++ 6.0, however, behaves weird. It shows L'1' as "49", yet
>>>when passing it to stringstream, it interprets it as if it's actually
>>>wchar_t, and writes it as "1".
>
>>Very odd!
>
>It's surprising how many subtle issues a supposedly simple component like
>lexical_cast may have, at least if you want it fully generic, being able to
>take any type, including any character type.
>
>It reminds me a little of the exception-safety debate, where it was found to
>have a lot of issues. For example, I saw a simple code-snipped, once, just a
>few lines, which was found to have 23 possible execution paths through it (3
>normal ones, and 20 in case of exceptions). Luckily, these issues have now
>been resolved, and collected in a book like "Exceptional C++" (A fitting
>title, when 10 items are devoted to exception safety. :) ).
>
>>Well, the different behaviour boils down to what overload of
>>
>>    basic_ostream<_CharT, _Traits>& operator<< ()
>>
>>gets called. Let's stick with the STLport.
>>
>>VC++ 6.0 always call
>>
>>   (a)   operator <<(basic_ostream & , _CharT __c)
>>                                     [line 206, stl/_ostream.h]
>>
>>which of course inserts a char.
>>
>>Intel C++ 6.0 instead calls the same with the /Zc:wchar_t switch, and
>>
>>   (b)   _basic_ostream & operator<<(unsigned short __x)
>>                                                      [line 99]
>>
>>which outputs numbers without the switch.
>>With MSVC's library things are analogous.
>>
>>The real questions are why VC++ doesn't choose (b) and why Intel C++
>>with the switch calls (a).
>
>I think the reason may be quite simple. Intel C++ has (the possibility of)
>intrinsic wchar_t. Therefore, when it's turned on, it calls the
>char-version, and when it's turned off, it becomes a synonym of unsigned
>short, like VC++, and therefore calls the other function.
>
I find it quite horrible. It doesn't have an intrinsic wchar_t, even
with the switch. It only acts as if it had in some situations. Which
situations is very difficult to say.
Also, I expected "microsoft emulation" without the switch and
"compliance" with the /Zc:wchar_t (or with some other switch, I don't
know what the /Zc:wchar_t does with .NET). Instead, _maybe_ there's no
way to make it compliant (of course I've tried invoking it from the
command line, after editing the icl.cfg file).
Type identity is absolutely fundamental for the language and for
program semantics. The fact the Intel with the switch gives true with
this
     typeid(wchar_t) == typeid(unsigned short)
means that wchar_t and unsigned short _are_ the same type (and let's
forget for a moment that this is non conforming). Also
    typeid(L'1') == typeid (unsigned short)
    typeid(L'1') == typeid (wchar_t)
both yield true. OTOH, the example about overloading (or what kind of
'over-stuff' is it now) tells that they are different, and also that
the 'best match' for the call
 dummy (L'1')
is void dummy (unsigned short)! 
I'm sorry to be a little harsh but I really spent (wasted) a lot of
time trying to rationalize the behaviour of the compiler. I expect
such things from MSVC but I was really astonished from Intel, so I
wandered through the documentation, the command line and the config
files, with a big "there must be a switch" that kept floating in my
mind. I didn't even think to compare type_infos because I really
trusted the dragon!
>VC++, on the other hand, doesn't have intrinsic wchar_t. Therefore, they
>have a few options: They could behave as Intel C++, using no intrisic
>wchar_t, and call the unsigned short version, too. That would never give any
>character behaviour for wchar_t. Or, they could do as apparently is done,
>treat "unsigned short" special, and call the char-version for it, getting
>some wide character support that way.
>
>This of course means that you can't output an unsigned short value, without
>having it output as a character. In essence, VC++ "hijacks" the unsigned
>short type, and uses it as if it was wchar_t, to compensate for compiler
>deficiencies. For this reason, lexical_cast works even if it has no
>intrinsic wchar_t.
Well, fortunately all these things don't affect lexical_cast :-)
My question was an aside in the context of this thread (that's why I
put it in the post-scriptum).
This doesn't prevent all the issue to be quite puzzling, though.
>However, that also means unsigned short is taken, so
>nobody can use it as another character type, for example.
>
>>It seems that both compilers treat wchar_t differently from an
>>unsigned short in certain situations.
>
>I think the answer, as explained above, is that Intel C++ treats wchar_t as
>a true intrinsic type, while VC++ treats it as a synonym for unsigned short,
>and attempts to remedy this by changing the library, as shown above.
>
>>Try for instance this trivial program (use the switch for icl):
>>
>>#include <sstream>
>>
>>int main(int argc, char* argv[])
>>{
>>using namespace std;
>>
>>basic_stringstream<unsigned short> str;
>>str << L'1';
>>
>>return 0;
>>}
>
>When I try this on Intel C++, with the switch, I get errors. It compiles on
>VC++, as expected
Eheheh :-) To me, it didn't compile with VC++, but only because I
forgot the Zc:wchar_t switch in the Project Settings dialog (try to
believe...)
>, as VC++ apparently uses "unsigned short" and "wchar_t" as
>aliases, whereas Intel C++, with the switch, does not. Trying it on Intel
>C++, without the switch, works there as well, again as expected, as it then
>emulates VC++.
>
>>Done it? Well, now change unsigned short to wchar_t....
>
>That works on Intel C++ and on VC++, as expected. For the same reason as the
>above.
>
>>> So it's kind of a partial wchar_t support,
>>>there, where they have made "unsigned int" to behave as "wchar_t".
>
>>You mean unsigned short as a distinct wchar_t type?
>
>Apparently, as mentioned, they are synonyms, for VC++. Instead, the library
>is changed, to let unsigned short work as if it's a character type.
>
>>Anyhow, I hope Intel didn't ruin a so good product with these kinds of
>>microsoft-related conundrums :-(
>
>No. As you can see, Intel C++ works fine with the switch. It's only without
>it that it emulates VC++.
>
>>What about the example I gave in my previous post and
>>typeid(wchar_t).name() on Intel C++ 7.0?
>
>It still gives "unsigned short". However, they are allowed to do this, as
>the result is implementation dependent. Still, it's not particularly
>helpful, so I'll mention this in an issue report to Intel.
I suggest in particular to point out the very dangerous duality (to be
polite) between compile-time identity and run-time identity. And with
a switch that is expected to enforce conformance. For instance
// use Zc:wchar_t
//
template <class T>
    void f (T ) {
    std::cout << "Is same?" <<
         boost::is_same<unsigned short, T>::value << '\n';
    std::cout << "Same typeinfo?" <<
         (typeid(unsigned short) == typeid(T)) << '\n';
}
int main() {
    f (L'1');
}
>
>>Wow, peer-review really works. :)
>>
>>Thanks. :)
>
>>I'm happy that you find all those pedantic comments useful! Ehmm...
>>Terje, are you sure? :-)
>
>Yes. :) And it's not pedantic. Your feedback is most valuable, as it has let
>me remove bugs in the version, and possible problems, such as the '\0' /
>L'\0' issue.
>
>This is not pedantic. This is precision. And that's a virtue. By the way,
>you've got credit as contributor in the lexical_cast file, as you may have
>seen.
>
Well, I'm a bit embarrassed because I think my comment were marginal.
But only because frankly I didn't see anything wrong in the
fundamental parts. In any case, thank you very much! :-)
Genny.