Boost logo

Boost :

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
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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at