I just wondered, Walter, if you would explain your reasoning why all class objects are allocated on the heap?  Stack objects, not subject to garbage collection and automatically cleaned up when the reference goes out of scope, would give programmers some flexibility...and improve program performance by reducing the number of objects that must be considered by the garbage collector.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CF4F102.D7F03F0C@deming-os.org...

> I just wondered, Walter, if you would explain your reasoning why all class objects are allocated on the heap?  Stack objects, not subject to garbage collection and automatically cleaned up when the reference goes out of scope, would give programmers some flexibility...and improve program performance by reducing the number of objects that must be considered by the garbage collector.

It was done because objects on stack will have to be cleaned up
properly in case of exceptions, thus complicating the rules
of objects finalization (when the destructors get called, etc).
Stack unwinding in C++ was quite a complex process, and I guess
Walter doesn't want to see it in D.

By the way, did you notice that many languages have also made the same decision? In Delphi, you can only declare objects on heap (unlike older Borland Pascal), the same in Java, C#...

Pavel Minayev wrote:

> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CF4F102.D7F03F0C@deming-os.org...
>
> It was done because objects on stack will have to be cleaned up
> properly in case of exceptions, thus complicating the rules
> of objects finalization (when the destructors get called, etc).
> Stack unwinding in C++ was quite a complex process, and I guess
> Walter doesn't want to see it in D.

I read about that on the garbage collection page.  But I thought that he was saying that since the garbage collector reduces the need for destructors, we get simpler unwinding.  I guess I see how it makes the exception code simpler without stack objects, but the price of not having stack objects seems high.

As I see it, declaring a stack objects means two things:
    * The compiler adds a "delete obj;" line in the "finally" block for that
block of code.
    * The compiler doesn't add the object to the garbage collection table.

Since the compiler already supports "finally" blocks, how much complexity does this really add?

> By the way, did you notice that many languages have also made the same decision? In Delphi, you can only declare objects on heap (unlike older Borland Pascal), the same in Java, C#...

I must admit that my knowledge of languages (other than C/C++/D) is limited. I found one and stuck with it.  I've done a little Java (when college classes required it) and learned the basics of PERL for work...but I head back to C++ as soon as I get a chance.  (And C++ will vanish as soon, in favor of D.)

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3CF503BB.90F84DA1@deming-os.org...
> Pavel Minayev wrote:
 > "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message
> > news:3CF4F102.D7F03F0C@deming-os.org...
> >
> > It was done because objects on stack will have to be cleaned up
> > properly in case of exceptions, thus complicating the rules
> > of objects finalization (when the destructors get called, etc).
> > Stack unwinding in C++ was quite a complex process, and I guess
> > Walter doesn't want to see it in D.
>
> I read about that on the garbage collection page.  But I thought that he
was
> saying that since the garbage collector reduces the need for destructors,
we
> get simpler unwinding.  I guess I see how it makes the exception code
simpler
> without stack objects, but the price of not having stack objects seems
high.
>
> As I see it, declaring a stack objects means two things:
>     * The compiler adds a "delete obj;" line in the "finally" block for
that
> block of code.
>     * The compiler doesn't add the object to the garbage collection table.
>
> Since the compiler already supports "finally" blocks, how much complexity does this really add?

Good point. Since D already have to do "finally-unwinding", I don't see much
difference in destructing objects on the stack with stack unwinding.
Is there a problem with pointers stored
 inside non-garbage collected objects pointing to garbage collected ones?

> > By the way, did you notice that many languages have also made the same decision? In Delphi, you can only declare objects on heap (unlike older Borland Pascal), the same in Java, C#...

IMHO, in these languages this decision was made because the designers
thought
that this will help people to learn the language, and understand other
developers code.
They simply removed a feature, because it can be replaced by an other
already
implemented one (heap). I don't think they considered compiler complexity
here.
This was an important decision.
They made great success in the domain of the beginners with it, and similar
ones.
But professionals don't like to see useful features disappear.
Easy usage for the beginner is not the
same as easy usage for the professional.
The kind of thinking that resulted in removing stack objects among others,
blocks all these languages way to become a truly general purpose language.

Yours,
Sandor

> Is there a problem with pointers stored
>  inside non-garbage collected objects pointing to garbage collected ones?

Does D support automatic copy constuctors that traverse the object tree (ptrs and stuff)?  Because if it does, I'd have-it-a-guess that copy and del would be quite simular operations (not in function but in general design). But correct me if I'm wrong.

"anderson" <anderson@firestar.com.au> wrote in message news:ad5d48$1kdd$1@digitaldaemon.com...

> Does D support automatic copy constuctors that traverse the object tree (ptrs and stuff)?  Because if it does, I'd have-it-a-guess that copy and
del
> would be quite simular operations (not in function but in general design). But correct me if I'm wrong.

D doesn't have copy constructors at all because you never work with objects, but always with references. So "A = B" means "let A point to the same object as B". No copy occures.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:ad5kl4$24tc$1@digitaldaemon.com...
> "anderson" <anderson@firestar.com.au> wrote in message news:ad5d48$1kdd$1@digitaldaemon.com...
>
> > Does D support automatic copy constuctors that traverse the object tree (ptrs and stuff)?  Because if it does, I'd have-it-a-guess that copy and
> del
> > would be quite simular operations (not in function but in general
design).
> > But correct me if I'm wrong.
>
> D doesn't have copy constructors at all because you never work with objects, but always with references. So "A = B" means "let A point to the same object as B". No copy occures.
>

But it should have an assignment operator!
Yes, I keep trying... :)


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail

Oh, I really liked the copy constructor. I suppose I can create one manually using a method called copy, but that's not standarised like the copy and conversion constructors.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:ad5kl4$24tc$1@digitaldaemon.com...
> "anderson" <anderson@firestar.com.au> wrote in message news:ad5d48$1kdd$1@digitaldaemon.com...
>
> > Does D support automatic copy constuctors that traverse the object tree (ptrs and stuff)?  Because if it does, I'd have-it-a-guess that copy and
> del
> > would be quite simular operations (not in function but in general
design).
> > But correct me if I'm wrong.
>
> D doesn't have copy constructors at all because you never work with objects, but always with references. So "A = B" means "let A point to the same object as B". No copy occures.
>

I used the copy constuctor for pointers in C++ like,
class A = new class(B);

And I do no that D defaults all objects to pointers.

"anderson" <anderson@firestar.com.au> wrote in message news:ad7a38$1r7f$1@digitaldaemon.com...

> Oh, I really liked the copy constructor. I suppose I can create one
manually
> using a method called copy, but that's not standarised like the copy and conversion constructors.

I guess what Walter wants is to standartise this. I guess you'll have a method named dup(), which is supposed to copy an object. So it is standartized.

I've heard from everybody but Walter, it seems.  What is your reasoning, Walter?

Russ Lewis wrote:

> I just wondered, Walter, if you would explain your reasoning why all class objects are allocated on the heap?  Stack objects, not subject to garbage collection and automatically cleaned up when the reference goes out of scope, would give programmers some flexibility...and improve program performance by reducing the number of objects that must be considered by the garbage collector.
>
> --
> The Villagers are Online! villagersonline.com
>
> .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
> .[ (a version.of(English).(precise.more)) is(possible) ]
> ?[ you want.to(help(develop(it))) ]

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]