View mode: basic / threaded / horizontal-split · Log in · Help
December 20, 2011
Re: d future or plans for d3
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
Re: d future or plans for d3
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
Re: d future or plans for d3
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
Re: d future or plans for d3
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
Re: d future or plans for d3
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
Re: d future or plans for d3
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
Re: d future or plans for d3
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
Re: d future or plans for d3
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
Re: d future or plans for d3
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
Re: d future or plans for d3
> 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
3 4 5 6 7 8 9 10
Top | Discussion index | About this forum | D home