Re: [boost] Re: compressed_pair requirements?

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-05-27 15:45:27

Howard Hinnant wrote:
> On May 27, 2005, at 1:47 PM, Peter Dimov wrote:
>
>> Howard Hinnant wrote:
>>
>>> 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.
>>
>> Technically... you can't put an uninitialized (non-character) scalar
>> in a container; copying an uninitialized scalar is undefined
>> behavior.
>
> <gets an evil look in his eye...>
>
> #include <array>
> #include <vector>
> #include <tupleio>
> #include <iterator>
> #include <algorithm>
> #include <iostream>
>
> int main()
> {
>     std::vector<std::tr1::array<int, 3> > v;
>     std::tr1::array<int, 3> a;
>     for (int i = 0; i < 10; ++i)
>         v.push_back(a);
>     std::ostream_iterator<std::tr1::array<int, 3> > out(std::cout,
> "\n");
>     copy(v.begin(), v.end(), out);
> }
>
> (1 0 3195936)
> (1 0 3195936)
> (1 0 3195936)
> (1 0 3195936)
> (1 0 3195936)
> (1 0 3195936)
> (1 0 3195936)
> (1 0 3195936)
> (1 0 3195936)
> (1 0 3195936)
>
> Ha, ha, did it!  And you can't stop me from doing it again! <evil
> laugh follows> :-)

But what for? If you want to print random values to stdout, it's easier to 
just use std::rand.

Didn't we already go over this some years ago? The result was a proposed 
vector constructor that left its members uninitialized and then called a 
user-supplied function that initialized them.

And in any event, compressed_pair leaving its members uninitialized when 
std::pair doesn't is a pretty elegant way to sneak bugs into innocent 
people's code when they aren't looking. An <evil laugh> would be entirely 
appropriate here as well. ;-)