January 06, 2013
Am 05.01.2013 05:24, schrieb ixid:
> On Monday, 31 December 2012 at 14:40:48 UTC, Benjamin Thaut wrote:
>> Am 31.12.2012 15:02, schrieb DypthroposTheImposter:
>>>   Do you find that D without GC is more effective than C++? Seems like
>>> you would be stuck using structs which seems somewhat limiting, even
>>> compared to C++...
>>>
>>>  UE4 has similar reloading capabilities(using DLLs), though they use
>>> C++ and rely more on the ability to serialize everything
>>>
>>
>> Why should I be stuck with structs? Its the exact same as in C++. I
>> did build my own new and delete operators (as templates). It's not
>> that hard and works pretty well, only the syntax is not ideal in some
>> cases. I can use everything you can use with D+GC. Sometimes you have
>> to be carefull with implict allocations (e.g. closures, array
>> literals) but I have a leak detector that points me to these directly
>> and usually its easy to free these manually.
>>
>> And I'm quite a bit more productive then in C++. Module constructors
>> with a defined order instead of random static initalizers,
>> code generation isnstead of huge amounts of boilerplate code and many
>> other features are the cause of this.
>>
>> Kind Regards
>> Benjamin Thaut
>
> Is D moving away from your sort of use? Games and bioinformatics
> would seem to be the areas the language should be trying to get
> people to start using it in. The features you're using seem very
> much like they should be a part and mode of using the language.

I wouldn't say its moving away from it. Some recent changes to druntime have made it significantly less leaking. But on the other hand a API design like toString() which pretty much does leak in almost all cases don't exactly help a GC free D. In Summary it feels to me that GC free D is not important to the community or the active contributors.

I also see D's biggest chances in becoming popular in the performance critical fields of programming. Which would be systems programming, Gaming and others. For programming fields in which a GC is applicable people tend to use languages like C# or Java, because they are truly safe (see the recent "ref is unsafe" discussion in the newsgroup), they have nice productivity features like runtime code changing through the VM and have a way better GC because the language was designed from the beginning to support a advanced GC.

Kind Regards
Benjamin Thaut
January 06, 2013
Benjamin Thaut:

> In Summary it feels to me that GC free D is not important
> to the community or the active contributors.

I think it will become more important for them, in future. At the moment the work is mostly on finishing immutability, purity, shared, and other parts of the core language, and working on process characteristics (like GIT workflows) that are needed to make everything else work efficiently.


> they have nice productivity features like runtime code changing through the VM

Some of those productivity features are important, and despite D doesn't run on a virtual machine I think some of them can be added to D, once enough attention and work is given on them.

Bye,
bearophile
January 06, 2013
On 2013-01-06 11:37, Benjamin Thaut wrote:

> I wouldn't say its moving away from it. Some recent changes to druntime
> have made it significantly less leaking. But on the other hand a API
> design like toString() which pretty much does leak in almost all cases
> don't exactly help a GC free D. In Summary it feels to me that GC free D
> is not important to the community or the active contributors.

The design of toString() has been up for debate a couple of times. Many are not happy with the design.

-- 
/Jacob Carlborg
January 06, 2013
On 2013-01-06 11:30, Benjamin Thaut wrote:

> Yes I know flectioned. But I did not require that much RTTI information.
> No I'M not manually triggering the code for generating the RTTI. As
> mentioned in the article it is done via the RTInfo template inside
> object_.d / object.di which is automatically instanciated for each type
> used during compilation.

Ah, so you modified the existing RTInfo? I didn't know that existed.

-- 
/Jacob Carlborg
January 06, 2013
Am 06.01.2013 12:17, schrieb Jacob Carlborg:
> On 2013-01-06 11:30, Benjamin Thaut wrote:
>
>> Yes I know flectioned. But I did not require that much RTTI information.
>> No I'M not manually triggering the code for generating the RTTI. As
>> mentioned in the article it is done via the RTInfo template inside
>> object_.d / object.di which is automatically instanciated for each type
>> used during compilation.
>
> Ah, so you modified the existing RTInfo? I didn't know that existed.
>

It does not exist. The current RTInfo template just outputs a null pointer for every type. It is planned that the RTInfo template will be used for a percise GC in the future. (Did you read the article? ^^)

Kind Regards
Benjamin Thaut
January 06, 2013
On 2013-01-06 12:28, Benjamin Thaut wrote:

> It does not exist. The current RTInfo template just outputs a null
> pointer for every type.

Yes, but it still exists.

> It is planned that the RTInfo template will be
> used for a percise GC in the future. (Did you read the article? ^^)

Yes, I've read the article. How do you think I otherwise could have come up with these questions :)

I can see now that you wrote:

"This template is instanciated for every type that is used during compilation and thus is ideal to generate RTTI information"

I get it now.

-- 
/Jacob Carlborg
January 06, 2013
Am Sun, 06 Jan 2013 12:10:38 +0100
schrieb Jacob Carlborg <doob@me.com>:

> On 2013-01-06 11:37, Benjamin Thaut wrote:
> 
> > I wouldn't say its moving away from it. Some recent changes to druntime have made it significantly less leaking. But on the other hand a API design like toString() which pretty much does leak in almost all cases don't exactly help a GC free D. In Summary it feels to me that GC free D is not important to the community or the active contributors.
> 
> The design of toString() has been up for debate a couple of times. Many are not happy with the design.
> 

some modules already provide the (scope void delegate(const(char)[])
sink overload, it's also supported by to, format and writefln, afaik.
https://github.com/D-Programming-Language/phobos/blob/master/std/uuid.d#L806

I guess when we have custom allocators we can also provide toString methods templated on allocators.
January 06, 2013
> I guess when we have custom allocators we can also provide toString methods templated on allocators.
> 

Custom allocators released together with HL3?
January 06, 2013
Am 06.01.2013 12:50, schrieb Jacob Carlborg:
> On 2013-01-06 12:28, Benjamin Thaut wrote:
>
>> It does not exist. The current RTInfo template just outputs a null
>> pointer for every type.
>
> Yes, but it still exists.
>
>> It is planned that the RTInfo template will be
>> used for a percise GC in the future. (Did you read the article? ^^)
>
> Yes, I've read the article. How do you think I otherwise could have come
> up with these questions :)
>
> I can see now that you wrote:
>
> "This template is instanciated for every type that is used during
> compilation and thus is ideal to generate RTTI information"
>
> I get it now.
>

Here is the full implementation if you are interested:
https://github.com/Ingrater/druntime/blob/master/src/rtti.d

Kind Regards
Benjamin Thaut
January 06, 2013
On 2013-01-06 13:19, Benjamin Thaut wrote:

> Here is the full implementation if you are interested:
> https://github.com/Ingrater/druntime/blob/master/src/rtti.d

Thanks. Is that possible to do without having to modify the runtime?

-- 
/Jacob Carlborg