|
Boost : |
From: nbecker_at_[hidden]
Date: 2002-03-08 15:33:50
>>>>> "rwgk" == rwgk <rwgk_at_[hidden]> writes:
rwgk> --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
>> From: "Howard Hinnant" <hinnant_at_t...>
>> > Meanwhile vector<double> v(10, uninitialized_flag) breaks no
rwgk> vector
>> > invariants. The vector is destructible. The vector elements can
rwgk> be
>> > assigned into. If your hardware doesn't mind (mine doesn't), you
rwgk> can
>> > even assign from this uninitialized vector. I can't think of a
rwgk> reason
>> > why you would want to do that though.
>>
>> You can't v.insert(v.begin(), 5.0) because copying the
rwgk> uninitialized doubles
>> is undefined behavior. The insert() preconditions do not say that
rwgk> you can't.
>> Something is wrong. :-)
rwgk> In my mind
rwgk> vector<double> vec(100000, uninitialized_flag());
rwgk> means these things:
rwgk> 1. I do not want to waste time for something that I am
rwgk> absolutely sure I do not need (the default construction)
rwgk> because
rwgk> 2. I am about to fill the memory with the given number
rwgk> of elements by some other facility, and
rwgk> 3. I am taking responsibility and I have read the
rwgk> documentation for uninitialized_flag() which told me
rwgk> to initialize the memory before doing /anything/ else
rwgk> with it.
rwgk> Being safe by default is great, but IMO forcing everyone to
rwgk> waste time only to be safe under any conceivable eventuality
rwgk> is misguided and may be one of the reasons why C++ still has
rwgk> a bad reputation among many (non-computer) scientists.
I completely agree. That's one reason I have not really understood
all of the conversation on this subject (the other being that some of
it is over my head). I get the impression that much discussion has
been on how to prevent undefined things from happening if I use
unitialized memory. I was under the impression that I couldn't care
less what happens. That's a programming error. Too bad. If it
segfaults, that's a good thing.
Or maybe I misunderstood.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk