Re: The D Programming Language
PeteK wrote:
James Kanze wrote:
PeteK wrote:
My experience is that almost no classes have a logical owner.
Most classes which have a deterministic lifetime manage that
lifetime themselves. When I'm using garbage collection in C++,
I'd guess that about 90% of the deletes are "delete this".
Which is where our experience differs. For me, most classes are either
on the stack, in a collection or embedded in another class.
In terms of number of classes, you're probably right. In terms
of number of objects, however, it's less sure. Things like the
characters in a string, for example, can't be on the stack,
since they have variable size.
Only a small number of classes require the use of smart
pointers and in the end even these are bound to the lifetime
of a single class created to run the application. The word
"delete" usually only turns up in comments.
Or in a few special classes, such as smart pointers?
I do have entity objects which have more or less complicated
state, and for which one of the states means that no further
operations are legal on the object.
[...]
"abc" is "abc", regardless of scope or context. You're letting
implementation constraints of C++ color your conception.
Now you're losing me. Ultimately all objects are just an ordered
collection of chars, so you're basically saying that "everything is
always alive, regardless of scope or context".
No. Some objects have identity, others are just "values". The
value "abc", like the value 5, exists forever. It existed
before your program started running, and it will exist after it
stops.
At some point in the execution of your program, you create an
instance of this value, i.e. you allocate memory for it, and put
the correct bits in that memory to represent it. At some later
point, this instance ceases to exist.
In the case of an integer value, we create many, many instances,
copying the bits at the drop of a hat. No pointers and no
dynamic allocation and deallocation are involved. But that's
only because 1) the size of an integer is fixed (in C++---it's
an artificial restriction), and 2) copying is cheap. In the
case of a string of text, the size of the representation isn't
known before hand, and copying it could be expensive. So we
allocate dynamically to create the first instance, and we copy
pointers, rather than the object---with regards to the code, in
many ways, the pointer is the value.
In C++ we can extend that logical lifetime by using
smart pointers and the like, but there is still a defined point when
the object is logically dead.
Yes. When no other object can possibly access it.
No!
int * f()
{
int
x = 3;
return &x;
}
x logically dies at the end of the function, but you can still access
it (if you're talking about the memory location it occupies, and in the
context of zombies I can't see what other definition you can use).
You haven't understood what I'm saying. What I'm saying is that
the value 3 hasn't ceased to exist. In the above code, you've
given x an identity; it's no longer a simple value. And of
course, you're creating a circular argument. You're argument is
basically that all objects have a deterministic lifetime because
that's the way C++ currently works, and that C++ is right to
work that way because all objects have a deterministic lifetime.
In other languages, your code above would be perfectly legal; it
would be in Java for anything but a basic type, e.g. if you used
Integer instead of int.
The example I'm trying to point out is something like:
int f()
{
return 3 ;
}
Now write the same code where 1) the return value is a string,
and 2) it is read from a file, or calculated in some way that we
don't know the length before hand. Or write it simply replacing
int with a BigInteger, of undefined length.
All of the solutions I know in C++ involve either deep copy
(expensive), or some sort of reference counting (tricky, and
expensive if it has to be thread safe).
In C++ something is logically dead when it's destructor is
called. The fact that you've got live pointers to it doesn't
mean it's alive, it means you've probably got an error in your
program.
By definition, at the language level. C++ requires us to create
a deterministic lifetime for all objects, even if the design
doesn't require it. That's what I'm arguing against.
[...]
True, but in practice, you don't have to worry about objects
which aren't logically dead, but which are inaccessible, because
the program doesn't need them any more.
Unless these objects contain precious resources.
Which in practice they don't (except memory). How can a value
contain a resource?
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]