Re: [Boost-users] [array] VC++ 7.1 bug and a proposed fix

From: John Maddock (john_at_[hidden])
Date: 2006-08-08 06:38:27

AlisdairM wrote:
> John Maddock wrote:
>>
>> However the change should be restricted to VC7.1 just to be sure.
>
> Triple-checking, I believe you are correct. (and I have been through
> this dance more than once over the last 18 months)
>
> It does mean that array would never be a POD, and not be admissible in
> unions.  Those are lesser restrictions though, so I am less worried by
> them.

Actually if array ever became a non-POD that would be a serious breaking 
change: POD's are initialised in the static initialisation phase and we 
really do want:

boost::array<int 3> a = { 1, 2, 3 };

To be initialised before everything else.

However, section 12.8p9 says:

"A user-declared copy assignment operator X::operator= is a non-static 
non-template member function of class X with exactly one parameter of type 
X, X&, const X&, volatile X& or const volatile X&.109)"

So I think we are OK with a *template* assignement operator, as it doesn't 
count for considering whether a type is a POD or not.

> In principle the proposed workaround should be doing exactly the same
> as the implicitly declared copy-assignment operator, although it is
> potentially less efficient - especially in the POD case.
>
> The question is - should we make this the default behaviour - banning
> POD-behaviour and unions; accept these restrictions on the MS compiler
> only and deem such use non-portable; or specialize on MS only, purely
> for the pointer-to-member case?

Personally I would add the template-assignment op for BOOST_MSVC < 1400 
only, would we gain anything from adding it for other compilers?  It opens 
up an assignment that wasn't there before, so I guess it means array<double, 
N> becomes assignable to array<int, N> which may or may not be a good idea 
depending on your POV.

John.