on Sun Dec 21 2008, "Vladimir Batov" <batov-AT-people.net.au> wrote:
I searched high and low and I was not able to find any hints about equivalency of the default-constructed objects (required, expected, assumed or otherwise). And I am still under impression that that requirement (or expectation) cannot be real as many classes are not even meant to be comparable.
I believe the general consensus about that is changing, at least somewhat.
Dave, would you please elaborate? In what "direction" that is changing? Are there plans to single the def. cnstr out and to impose some restrictions/requirements/assumptions onto it?
Not exactly, but concept Regular is going to be an important one in C++0x.
I do not think it makes them unusable with the std containers or breaking anything or second-class classes of no interest to the Standards committee.
You might Google for 'stepanov "regular types"'
Thank you for the pointers. I was able to download "Fundamentals of Generic Programming" and there they clearly consider the def. cnstr one of the fundamental operations for built-in types that they are extending on to "regular types". I have to say that my initial reaction is of a surprise. I would expect it the other way around -- I'd try making built-in types behave more like "normal" classes
? You don't get to change the way built-ins work.
or if we cannot do that for backward compatibility reasons, then acknowledge the difference and get on with it. Dragging "normal" classes down and squezing them in to the the procrustean bed of the built-in types (dragged into the present through C compatibility) seems like a step down.
I admit I'm ambivalent about that too. The ability to cheaply default-construct an object is so seldom important, and strong invariants are so valuable, that I am reluctant to adopt the default-constructability rule. However, for move semantics (and what could be more suited to that than a UUID?) the invariant often needs to include a "empty" moved-from state anyway, and you could argue that one might as well implement a cheap, non-throwing default ctor that produces that state. The argument I sometimes use against it is that even though the empty state technically becomes part of the class invariant, limiting that state to moved-from objects still offers some improved ability to reason about code... but that's a weaker argument than I'd like.
I am not sure of the practical importance of that Stepanov's view
Personally, I'm wary of underestimating the importance of Stepanov's views.
as in many years of writing code I always followed the view of only introducing necessary constructors and I do not remember being hampered by the fact that those classes were not "regular types". What in your view is the importance of t hat "regular type"-conformance (or non-conformance)?
I'm still trying to form an opinion on it. Certainly the copy-constructability, assignability, and equality comparison requirements are required for equational reasoning. Default constructability doesn't rise to the same level of importance for me, but I'm still unsure. -- Dave Abrahams BoostPro Computing http://www.boostpro.com