From: David Abrahams (dave_at_[hidden])
Date: 2004-01-23 08:07:47
"Giovanni Bajo" <giovannibajo_at_[hidden]> writes:
> David Abrahams wrote:
>>> - http://aspn.activestate.com/ASPN/Mail/Message/boost/1614864 means
>>> that we cannot rely on wchar_t for ICC before 7.0, so we should
>>> always define BOOST_NO_INTRINSIC_WCHAR_T for it.
>> That's not clear to me. Anything we say is a lie under some
>> circumstance for ICC6, right? Is it better to lie in the affirmative?
>> We should at least give people a macro they can define on the
>> command-line to undo the lie.
> More than a lie, the problem seems that wchar_t support is buggy. I
> don't think we're better off lieing with the affermative:
I think you mean the opposite of what I meant here. An affirmative
for BOOST_NO_INTRINSIC_WCHAR_T would mean that we're saying "there's
no intrinsic wchar_t"
> if we say that wchar_t is a native type when it's not, we will break
> existing code (specializations with wchar_t conflicts with
> specializations with unsigned short). If my code is committed,
> people can still define "_WCHAR_T_DEFINED = 1" on the command line
> and force Boost into believing that wchar_t is a native type.
> We can document it this way, or if you prefer
> BOOST_INTEL_FORCE_WCHAR_T. Anyway, I don't have access to Intel
> so I can't really test it. My patch (conservatively) doesn't modify
> the Intel 6.x configuration.
>>> We basically have:
>>> #ifndef _WCHAR_T_DEFINED
>>> #define BOOST_NO_INTRINSIC_WCHAR_T
>>> Net result is that our intel-win32 toolset is totally broken if we
>>> don't specify /Zc:wchar_t.
>> How so? /Zc:wchar_t is specified by the toolset itself.
> I wrote "toolset" but I meant "compiler". If you open your own
> project with VC IDE and try to compile something that includes
> ublas.hpp (or you try to compile it from the command line), it's
> broken. The "toolset" as in the build system works because it forces
> /Zc:wchar_t, and in fact I stumbled upon my problem trying to
> compile from the command line.
> With my patch, Intel C++ can be used also without /Zc:wchar_t.
>>> The other hunk of the patch fixes a compatibility issue with
>>> STLport. In fact, there are many versions of STLport which are
>>> pre-configured with _STLP_WCHAR_T_IS_USHORT, even if the compiler
>>> was making it a builtin type. The point is that we (Boost) must
>>> acknowledge if STLport was configured without wchar_t support and
>>> disable our support as well. Otherwise, we will fail because we
>>> wouldn't find specializations such as basic_string<wchar_t> and the
>>> likes. Hartmut verified for me that this patch fixes the regression
>>> failures in Spirit in the intel-stlport-win32 toolset.
>> I think we'd better have a separate macro which determines whether
>> the standard library is supporting wchar_t.
> I agree that, in the longer run, that's the correct solution, but I
> don't have resources to implement it now, and change the existing
> codebase. Meanwhile, my solution should help fixing the problems we
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk