December 20, 2011
On 2011-12-19 11:52:25 +0000, Alex Rønne Petersen said:

> On 18-12-2011 15:40, Somedude wrote:
>> Le 18/12/2011 15:07, Ruslan Mullakhmetov a écrit :
>>> 
>>> GC is just a mater of implementation. In presence of resources implement
>>> good GC algorithm offers no difficulty.
>>> 
>> 
>> Oh really ? Then please make us a favor and write one for D. Also I'm
>> sure the C++ guys will be pleased to hear that it's such an easy task.
> 
> Yeah, unfortunately, we can't just keep saying "it's an implementation issue". It's very much a real problem; D programmers are *avoiding* the GC because it just isn't comparable to, say, the .NET and Java GCs in performance at all.
> 
> - Alex

Thanks for you explanation. I'm quite far away from GC but where is the problem compare to Java and .NET? Resources (people), specific language features making hard to implement GC or something else?

When i said that this is just a matter of implementation i followed the idea that it's already implemented in say Java, C#, Erlang wich GC was declared to be good enough in this topic.

-- 
BR, Ruslan Mullakhmetov

December 20, 2011
On 12/20/2011 07:01 AM, Ruslan Mullakhmetov wrote:
> On 2011-12-19 11:52:25 +0000, Alex Rønne Petersen said:
>
>> On 18-12-2011 15:40, Somedude wrote:
>>> Le 18/12/2011 15:07, Ruslan Mullakhmetov a écrit :
>>>>
>>>> GC is just a mater of implementation. In presence of resources
>>>> implement
>>>> good GC algorithm offers no difficulty.
>>>>
>>>
>>> Oh really ? Then please make us a favor and write one for D. Also I'm
>>> sure the C++ guys will be pleased to hear that it's such an easy task.
>>
>> Yeah, unfortunately, we can't just keep saying "it's an implementation
>> issue". It's very much a real problem; D programmers are *avoiding*
>> the GC because it just isn't comparable to, say, the .NET and Java GCs
>> in performance at all.
>>
>> - Alex
>
> Thanks for you explanation. I'm quite far away from GC but where is the
> problem compare to Java and .NET? Resources (people), specific language
> features making hard to implement GC or something else?
>
> When i said that this is just a matter of implementation i followed the
> idea that it's already implemented in say Java, C#, Erlang wich GC was
> declared to be good enough in this topic.
>

The difference is that those languages are entirely type safe.
December 20, 2011
 I've only recently tried D out, but what I'd like to see..

-GC being truly optional
-being able to specify if the standard library should use GC or not, perhaps with allocators
-if D is going to have a GC, then a precise, compacting one would be cool, but not if it gets in the way of making the GC optional


 One thing I'm not sure about, D classes are virtual by default, but if you mark all functions as final does the class still contain a VFP or any other cruft?
 Also why are class functions virtual by default? My experience in C++ is that I rarely use virtual, so I don't really understand why that is the default.



December 20, 2011
On Sun, 18 Dec 2011 04:09:21 +0400, Ruslan Mullakhmetov wrote:

>   I want to ask you about D future, i mean next big iteration of D and
> propose some new feature, agent-based programming. Currently, after
> introducing C++11 i see the only advantages of D over C++11 except
> syntax sugare is  garbage collector and modules.

I do not think D (as a language) should be modified to support agent-
based programming. A Phobos module (or package) would do. I seriously do
not see what language changes we need for agent-based programming. :)
December 20, 2011
On Tuesday, December 20, 2011 11:21:41 Froglegs wrote:
>   I've only recently tried D out, but what I'd like to see..
> 
> -GC being truly optional
> -being able to specify if the standard library should use GC or
> not, perhaps with allocators

Some aspects of D will _always_ require a GC or they won't work. Array concatenation would be a prime example. I believe that delegates are another major example. I think that scoped delegates avoid the problem, but any that require closures do not. Other things be done but become risky - e.g. slicing arrays (the GC normally owns the memory such that all dynamic arrays are slices and none of them own their memory, so slicing manually managed memory gets dicey).

There are definitely portions of the standard library that can and should be useable without the GC, but because some aspects of the language require, some portions of the standard library will always require it. In general, I don't think that it's reasonable to expect to use D without a GC. You can really minimize how much you use it, and if you're really, really careful and avoid some of D's nicer features, you might be able to avoid it entirely, but realistically, if you're using D, you're going to be using the GC at least some.

In general, the trick is going to be allowing custom allocators where it makes sense (e.g. containers) and being smart about how you design your program (e.g. using structs instead of classes if you don't need the extra abilities of a class - such as polymorphism). So, if you're smart, you can be very efficient with memory usage in D, but unless you really want to hamstring your usage of D, avoiding the GC entirely just doesn't work.

- Jonathan M Davis
December 20, 2011
On 12/20/2011 11:21 AM, Froglegs wrote:
>
> I've only recently tried D out, but what I'd like to see..
>
> -GC being truly optional
> -being able to specify if the standard library should use GC or not,
> perhaps with allocators
> -if D is going to have a GC, then a precise, compacting one would be
> cool, but not if it gets in the way of making the GC optional
>
>
> One thing I'm not sure about, D classes are virtual by default, but if
> you mark all functions as final does the class still contain a VFP or
> any other cruft?

The class will still have a vptr. The vtable will contain only the type info.

> Also why are class functions virtual by default? My experience in C++ is
> that I rarely use virtual, so I don't really understand why that is the
> default.
>

In C++, class and struct are essentially the same. In D, you use classes if you want polymorphism and structs if you don't need it. structs cannot participate in inheritance hierarchies or contain virtual functions. If you don't need virtual functions, you should probably use structs instead of classes. (you are not doing OOP anyway.)

structs don't contain a vptr.
If you want to use extensible with final methods, class C{final: /* method declarations */} will do the job. But it is not the most common case, so it should not be the default. (IIRC C# takes a different stance on this, they have final methods by default to force the programmer to make dynamic binding explicit. It has both benefits and drawbacks.)
December 20, 2011
On 12/20/2011 11:48 AM, Jonathan M Davis wrote:
> On Tuesday, December 20, 2011 11:21:41 Froglegs wrote:
>>    I've only recently tried D out, but what I'd like to see..
>>
>> -GC being truly optional
>> -being able to specify if the standard library should use GC or
>> not, perhaps with allocators
>
> Some aspects of D will _always_ require a GC or they won't work.

This is not a huge problem. They just wont work if the programmer chooses not to use the GC. There is nothing absolutely essential to writing working D programs that requires the GC.

> Array
> concatenation would be a prime example. I believe that delegates are another
> major example. I think that scoped delegates avoid the problem, but any that
> require closures do not. Other things be done but become risky - e.g. slicing
> arrays (the GC normally owns the memory such that all dynamic arrays are
> slices and none of them own their memory, so slicing manually managed memory
> gets dicey).
>
> There are definitely portions of the standard library that can and should be
> useable without the GC, but because some aspects of the language require, some
> portions of the standard library will always require it. In general, I don't
> think that it's reasonable to expect to use D without a GC. You can really
> minimize how much you use it, and if you're really, really careful and avoid
> some of D's nicer features, you might be able to avoid it entirely, but
> realistically, if you're using D, you're going to be using the GC at least
> some.
>
> In general, the trick is going to be allowing custom allocators where it makes
> sense (e.g. containers) and being smart about how you design your program
> (e.g. using structs instead of classes if you don't need the extra abilities
> of a class - such as polymorphism). So, if you're smart, you can be very
> efficient with memory usage in D, but unless you really want to hamstring your
> usage of D, avoiding the GC entirely just doesn't work.
>

Note that you can use manual memory management for classes.


December 20, 2011
Froglegs:

>   One thing I'm not sure about, D classes are virtual by default,
> but if you mark all functions as final does the class still
> contain a VFP or any other cruft?

Even D final classes, that do not have virtual methods, have a pointer to virtual table. It's used to know what class the instance is (for reflection too and for the destructor).


>   Also why are class functions virtual by default? My experience
> in C++ is that I rarely use virtual, so I don't really understand
> why that is the default.

Maybe because D OO design copies Java OO design a lot. But even in C# methods are not virtual on default.

Bye,
bearophile
December 20, 2011
Timon Gehr:

> If you don't need virtual functions, you should probably use structs instead of classes. (you are not doing OOP anyway.)

I don't agree with both that statements.

Bye,
bearophile
December 20, 2011
> The class will still have a vptr. The vtable will contain only the type info.

No way to disable type info(like in most C++ compilers you can disable RTTI)? I get that GC might want it, but if I disable GC why would I want type info?

I saw that D is planning to make the standard containers into classes with final methods, why do this instead of using structs if it bloats each instance of the container?


> Some aspects of D will _always_ require a GC or they won't work. Array concatenation would be a prime example. I believe that delegates are another major example. I think that scoped delegates avoid the problem, but any that require closures do not. Other things be done but become risky - e.g. slicing arrays (the GC normally owns the memory such that all dynamic arrays are slices and none of them own their memory, so slicing manually managed memory gets dicey).

The array concatenation requiring GC I get, but why does a delegate require it?

This link says D allocates closures on the heap

http://en.wikipedia.org/wiki/Anonymous_function#D

I don't really get why, C++ lambda works well(aside from broken lack of template lambda's) and do not require heap usage, even binding it to std::function can generally avoid it if it doesn't exceed the  SBO size