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 you? -- Michael Marcin