On 10/11/12 9:52 AM, deadalnix wrote:
Le 11/10/2012 14:19, Andrei Alexandrescu a écrit :
Temporary object are used to store temporary state coming from some
computation. In this case, the computation create the complexity, the
object isn't created via default constructor.
Or have you a use case in mind I don't think of ?
Here I meant a named temporary, such as e.g. a pivot in quicksort.
3. Two-phase object destruction (releasing state and then deallocating
memory), which is useful, is made more difficult by default
constructors. Essentially the .init "pre-default-constructor" state
intervenes in all such cases and makes it more difficult for language
users to define and understand object states.
This one is made worse by the current state. You have to assume
everywhere that your struct can be .init
Even when it doesn't make any sense. RefCounted is a pathologic case of
that.
One point I was making is that even with a default constructor, the
definition and existence of .init pops all over the place, like a bubble
in the carpet. I think it is a good engineering decision to simply make
it the default state.
4. Same as above applies to an object post a move operation. What state
is the object left after move? C++'s approach to this, forced by the
existence of default constructors and other historical artifacts, has a
conservative approach that I consider inferior to D's: the state of
moved-from object is decided by the library, there's often unnecessary
copying, and is essentially unspecified except that "it's valid" so the
moved-from object can continue to be used. This is in effect a back-door
introduction of a "no-resources-allocated" state for objects, which is
what default constructors so hard tried to avoid in the first place.
If we give struct a giveaway state (where the struct cannot be used
unless it is reinitilized to a correct value) this problem disappear.
It doesn't disappear - it manifests itself in a different way
(complexity in the language definition).
Except in the case 5. (and heap allocated struct in general), that in
fact seems to me the major issue.
I agree heaps with required allocated state are unpleasant to deal with
in the current design.
My overall point, which is worth repeating, is not that these problems
are insurmountable. Instead, we're looking at different choices with
distinct tradeoffs. There's no solution with all pluses.
Andrei
