Classes or stucts :: Newbie

[Jonathan M Davis]

On Sunday 19 December 2010 18:13:54 Nick Voronin wrote:
> On Sun, 19 Dec 2010 17:26:20 -0800
> 
> Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> > On Sunday 19 December 2010 16:50:34 Nick Voronin wrote:
> > > On Sun, 19 Dec 2010 14:38:17 -0800
> > > 
> > > Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> > > > On Sunday 19 December 2010 14:26:19 bearophile wrote:
> > > > > Jonathan M Davis:
> > > > > > There will be a library solution to do it, but again, it's
> > > > > > unsafe.
> > > > > 
> > > > > It can be safer if the compiler gives some help. For me it's one of
> > > > > the important unfinished parts of D.
> > > > 
> > > > Whereas, I would argue that it's completely unnecessary. structs and
> > > > classes serve different purposes. There is no need for scoped
> > > > classes. They may perodically be useful, but on the whole, they're
> > > > completely unnecessary.
> > > 
> > > How do you define a need for scoped classes?
> > > 
> > > I see two aspects there: first is having destructor called at known
> > > point rather than arbitrarily, second is performance.
> > > 
> > > It looks perfectly reasonable for me to want to have first. Do you know
> > > why things which makes program act more deterministic are shunned from
> > > D? Does it really add so much to safety that it is worth reducing
> > > programmer's control?
> > 
> > Then use a struct.
> 
> Here is where we diverge. Choosing struct vs class on criteria of their
> placement makes no sense to me. Difference in default placement hardly
> matters at all, you can perfectly put structs in heap or in static segment
> yet still maintain same properties. It's those properties which matter
> when I choose one or another, not where it will reside in particular part
> of program.
> 
> > That's one of the reasons that they exist. And if you
> > _really_ want to make sure that a class' destructor gets run, you can
> > always use clear() (which is arguably an abomination in its own right).
> 
> This is what I don't understand. Fine. structs are meant for stack, class
> for heap. Conceptually, anyway. Still there will be ways to put class on
> stack and struct in heap. And there is(will be) clear(). Now I do see
> benefit of scope storage. It looks clean, it is supported by compiler
> meaning reasonable level of protection against misuse, it is extremely
> effective. What are benefits of _not having_ it?

Except that the compiler _can't_ protect against misuse. That's one of the main 
reasons that it's going away as part of the language. Structs are intended to 
their lifetime be the same as their scope. The lifetime for classes, on the 
other hand, is essentially as long as the program is running (though the garbage 
collector can obviously collect them in cases where they aren't used anymore). 
By trying to force a reference type to have a scoped lifetime, you're going 
against how they work, and it's just asking for trouble. Yes, it _can_ be done, 
but no, it _can't_ be done safely.

As I understand it, Andrei isn't even entirely happy that clear() exists. I 
believe that pretty much the only reason that it exists is because there are 
cases where classes hold resources and you want to make sure that they get 
released rather than waiting for the object to get destroyed at some 
indeterminate point in the future. But really, the garbage collected heap is 
supposed to be managed by the garbage collector. And with scope, you're trying 
to take something that's designed to live on the garbage collected heap and put 
it on the stack. You're taking something that is designed to be used in one type 
of storage and using it in another. It's going to cause problems.

C++ has a number of issues pricely because it allows classes to live on both the 
stack and the heap. By separating types that live on the stack from those that 
live on the heap, you avoid those problems.

And actually, the fact that structs can live in the heap in D can be 
problematic, as evidenced by the bugs relating to destructors for structs on the 
heap. Not only do their destructors not get run, it's questionable whether the 
language will _ever_ be such that the destructors of structs on the heap will be 
run. The result is that in many cases, structs should either be designed to be 
on the stack or on the heap.

D was designed so that classes live on the heap, and that's the way it works. 
Putting them on the stack is going against how classes are intended to work, and 
it's asking for trouble.

- Jonathan M Davis