• dom (27/27) Sep 02 2016 from what i got Classes are always reference types and structs
• dom (3/3) Sep 02 2016 i haven't read it fully yet, but i think this DIP contains some
• Andrea Fontana (3/6) Sep 02 2016 Check this:
• dom (8/14) Sep 02 2016 thx that is very interesting. it seems like that can cover very
• Mike Parker (21/27) Sep 02 2016 How instances in an inheritance tree are allocated is actually an
• Andrea Fontana (5/9) Sep 02 2016 It depends by language you're using. In C++, for example you can
• ikod (3/15) Sep 02 2016 You can allocate class instance on stack:

dom <dschoerk gmx.at> writes:

from what i got Classes are always reference types and structs 
are value types in D. i am wondering why that is. for me the main 
difference between classes and structs is not how they are 
allocated, but that one has inhertiance, and the other hasn't. 
Supporting inheritance has some overhead, so at least the split 
between classes and structs makes sense to me.

I like garbage collection, but in many cases it's just 
unnecessary (like in the example below) or hurts performance on a 
bigger scale.

{
   FileReader reader = new .... // Annoy the garbage collector for 
no reason?
   auto blob = reader.read();
   delete reader;
}

Since garbage collection is a very nice feature that I wouldn't 
wanna miss for certain scenarios I think D should give us the 
opportunity to determine how an object is allocated. In the 
example above putting it on the stack is probably a good idea. 
Having a self managed reference to the heap can be good too if 
manual memory management is wanted. Or of course let the GC 
manage it ( i love it for prototyping code and also as a D 
beginner it is beneficial that i just dont need to care about 
memory management).

Could somebody explain to me if this is seen as a problem 
why/whynot and how I should address that kind of issues in my 
code?

dom <dschoerk gmx.at> writes:

i haven't read it fully yet, but i think this DIP contains some 
or all of my concerns
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md

Andrea Fontana <nospam example.com> writes:

On Friday, 2 September 2016 at 08:54:33 UTC, dom wrote:
 i haven't read it fully yet, but i think this DIP contains some 
 or all of my concerns
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md

Check this:
https://dlang.org/phobos/std_experimental_allocator.html

dom <dschoerk gmx.at> writes:

On Friday, 2 September 2016 at 08:59:38 UTC, Andrea Fontana wrote:
 On Friday, 2 September 2016 at 08:54:33 UTC, dom wrote:
 i haven't read it fully yet, but i think this DIP contains 
 some or all of my concerns
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md

 Check this:
 https://dlang.org/phobos/std_experimental_allocator.html

thx that is very interesting. it seems like that can cover very 
complex allocation schemes with a general interface!

i have also found this to allocate a class on the stack

class A { ... }
auto instance = scoped!A();

that has even quite a nice syntax!

Mike Parker <aldacron gmail.com> writes:

On Friday, 2 September 2016 at 08:43:45 UTC, dom wrote:
 from what i got Classes are always reference types and structs 
 are value types in D. i am wondering why that is. for me the 
 main difference between classes and structs is not how they are 
 allocated, but that one has inhertiance, and the other hasn't. 
 Supporting inheritance has some overhead, so at least the split 
 between classes and structs makes sense to me.

How instances in an inheritance tree are allocated is actually an 
important consideration, particularly when it comes to object 
slicing. In C++, this can be a problem:

```
class Foo {};
class Bar : public Foo {};

Bar bar;
Foo foo = bar;
```

All of the information about the type Bar is lost in the 
assignment to foo. The same thing is going to happen when passing 
bar to a function that takes a Foo by value as a parameter. The 
only way to avoid the problem is to pass by reference (or 
pointer). In Modern C++, with move semantics being a thing, 
passing by value is much more common than it used to be, but this 
is the sort of thing it's easy either not to know or to forget 
about. In D, you don't have to worry about it.

I read somewhere (in old forum discussions or an old article) 
that object slicing is one of the motivations behind the 
distinction in D.

Andrea Fontana <nospam example.com> writes:

On Friday, 2 September 2016 at 08:43:45 UTC, dom wrote:
 from what i got Classes are always reference types and structs 
 are value types in D. i am wondering why that is. for me the 
 main difference between classes and structs is not how they are 
 allocated, but that one has inhertiance, and the other hasn't.

It depends by language you're using. In C++, for example you can 
inherit both! The only difference AFAIK is that c++ structs has 
public default inheritance vs private for classes.

Andrea

ikod <igor.khasilev gmail.com> writes:

On Friday, 2 September 2016 at 08:43:45 UTC, dom wrote:


 Since garbage collection is a very nice feature that I wouldn't 
 wanna miss for certain scenarios I think D should give us the 
 opportunity to determine how an object is allocated. In the 
 example above putting it on the stack is probably a good idea. 
 Having a self managed reference to the heap can be good too if 
 manual memory management is wanted. Or of course let the GC 
 manage it ( i love it for prototyping code and also as a D 
 beginner it is beneficial that i just dont need to care about 
 memory management).

 Could somebody explain to me if this is seen as a problem 
 why/whynot and how I should address that kind of issues in my 
 code?

You can allocate class instance on stack:

https://dlang.org/phobos/std_typecons.html#.scoped