Boost logo

Boost :

Subject: Re: [boost] [uuid] Interface
From: Michael Marcin (mike.marcin_at_[hidden])
Date: 2008-12-23 02:09:58

Vladimir Batov wrote:
>> Just to drop my 2 cents.
>> I'd like to have the following use case be efficient.
>> class foo
>> {
>> foo( const char* filename )
>> {
>> std::ifstream file(filename);
>> file >> m_uuid;
>> }
>> private:
>> uuid m_uuid;
>> };
>> This seems like a reasonable usage pattern to me and I would be very
>> surprised if it was more expensive than reading into a char array.
> Just for clarity I'll state the obvious -- in your example 'm_uuid' *is*
> initialized.

I never said otherwise.

> Only built-in types allow declaration without definition
> (as a place holder). Classes do not allow that behavior. Classes always
> require and call constructors. Therefore, IMHO making them *look* like
> they behave similarly to built-ins sends/enforces the wrong
> message/impression. Therefore, I prefer the following which does exactly
> the same -- 'm_uuid' initialized invalid -- but explicit about what it
> actually does.

I realize invalid vs nil/null was discussed earlier but I still don't
like using those terms interchangeably.

> As for efficiency I expect this variant to be at least as efficient (if
> not better) because uuid::nil() is likely to have and to return the same
> initialized-once instance, i.e. no byte initialization traversal as in
> uuid() /* throw() */
> {
> for (data_type::iterator i=data_.begin(); i!=data_.end(); *i = 0,
> ++i);
> }
> Then, when a copy constructor is applied, it'll likely to copy the
> internal data array not per-byte but per-integer (4 bytes), i.e. 4 times
> quicker (not to mention the traversal overhead).

Surely that should at the very least be a std::fill which gets optimized
down to the a memset when possible (by VC9 at least).

But is it more correct to do this initialization than applying
data_type's default initialization?

Just to be clear this does or doesn't seem like a reasonable use case to

Michael Marcin

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