[boost] Re: compressed_pair requirements?

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2005-05-27 12:31:42

On May 27, 2005, at 11:35 AM, Peter Dimov wrote:

> John Maddock wrote:
>
>> OK, the following:
>> boost::compressed_pair<const int, long> cp2;
>> Gives me a compiler error with VC7.1 (it should as well, but it's not
>> really a compressed_pair issue).
>
> Why should it? std::pair works.

Oh, right.  This is the eternal struggle over what it means to default 
construct a scalar - do nothing or zero initialize.  This is so messed 
up in C++. :-\

std::pair zero initializes scalars on default construction.  And (at 
least the Metrowerks implementation of) compressed_pair does not zero 
initialize scalars on default construction.

People typically line up religiously on both sides of this issue:

1.  Zero initialization is better than uninitialized because it is 
safer.
2.  Uninitialized is better because it is much faster, especially if 
you have containers of such elements.  You can always explicitly 
initialize if you want.

The result today is that scalars are special when it comes to default 
construction, and you really can't count on consistent handling of 
default constructed scalars within class types (and there is no going 
back because of backwards incompatibility).

struct A
{
     A() {}
     int i_;
};

Default construct        and contained scalar is
std::vector<int>              zero-initialized
std::pair<int, T>             zero-initialized
std::complex<double>          zero-initialized
A                             uninitialized
std::tr1::array<int, N>       uninitialized
std::tr1::tuple<int, ...>     uninitialized ? (haven't double checked 
this one)
compressed_pair<int, T>       ???

I think it all started with map<key, int>:

std::map<std::string, int> m;
int& ir = m["one"];
// what value should ir have here?

We should document how we default construct scalars in compressed_pair. 
  Personally I fall into the Uninitialized (for efficiency) camp.  But 
at this point I don't think there are any very good answers.

-Howard