Am 06.04.2013 06:16, schrieb Adrian Mercieca:
> Hi,
>
> Is it possible to switch off the GC entirely in D?
> Can the GC be switched off completely - including within phobos?
>
> What I am looking for is absolute control over memory management.
> I've done some tests with GC on and GC off and the performance with GC is
> not good enough for my requirements.
>
> Thanks.
> - Adrian.
>

It is possible, but it heavily crippeles the language and requires modifications to druntime.

See: http://3d.benjamin-thaut.de/?p=20

Also see my GC free version of druntime:
https://github.com/Ingrater/druntime

My GC free version of phobos (heavily crippeled):
https://github.com/Ingrater/phobos

And my little GC free "standard library":
https://github.com/Ingrater/thBase

Its quite fun doing it when you want to learn new things, but I would not recommend doing so in a real wordl project.
-- 
Kind Regards
Benjamin Thaut

On 4/10/13, Manu <turkeyman@gmail.com> wrote:
> The _problem_ is that functions are virtual by default.
> It's a trivial problem to solve, however it's a major breaking change, so
> it will never happen.

I wouldn't say never.

In fact, it might go hand-in-hand with changing how protection attributes affect virtuality (currently they do, I'd argue they shouldn't)

For example one argument against allowing private and package methods the ability to be virtual is performance, namely these methods are now non-virtual and would suddenly become virtual if we allowed private/package overrides (because users typically don't mark private/package methods as final).

However if we at the same time introduced a virtual keyword, then the private/package methods would remain non-virtual.

What would break are public methods which are overriden but don't use the virtual keyword. So it's a breaking change but at least you won't get any performance degradation by accident.

Another reason I like the idea of a virtual keyword is that it documents the method better. The user of a library would clearly see a method can be overriden because it's marked as virtual, rather than having to guess whether the method was left non-final on purpose or by accident (accidents like that can happen..).

On Wednesday, 10 April 2013 at 12:44:34 UTC, Manu wrote:
> On 10 April 2013 22:37, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org>wrote:
>
>> On 4/10/13 2:02 AM, Manu wrote:
>>
>>> I do use virtual functions, that's the point of classes. But most
>>> functions are not virtual. More-so, most functions are trivial
>>> accessors, which really shouldn't be virtual.
>>>
>>
>> I'd say a valid style is to use free functions for non-virtual methods.
>> UFCS will take care of caller syntax.
>
>
> Valid, perhaps. But would you really recommend that design pattern?
> It seems a little obscure for no real reason. Breaks the feeling of the OO
> encapsulation principle somewhat.
>
> I've started using UFCS more recently, but I'm still wary of overuse
> leading to unnecessary obscurity.


It depends what model of OO you refer to.

I have been reading lately about multi-methods usage in languages like Dylan and Lisp, which is similar to UFCS, although more powerful because all parameters are used when deciding which method to bind.

OO is not only what Java/C#/C++ offer, there are other models that for whatever reason did not make it into mainstream.

--
Paulo

Am 09.04.2013 14:00, schrieb Johannes Pfau:
> Am Tue, 09 Apr 2013 11:29:09 +0100
> schrieb "Regan Heath" <regan@netmail.co.nz>:
>>> A good & simple start would be a -vgc switch, similar to -vtls which
>>> prints out all hidden memory allocations. Custom allocators are
>>> still important for the library (toString etc). Apart from that I
>>> would just stay away from language features which allocate. For
>>> example instead of using the concatenate operators I'd just use
>>> something like appender (which should then support custom
>>> allocators).
>>
>> Did you see Manu's problem case?  I can't recall the method name but
>> it was not one which suggested it would allocate, and it didn't in
>> the general case but in a very specific case it did.  As it stands,
>> it's very hard to tell which language features allocate (without code
>> inspection of the compiler and standard library) so it's hard to
>> avoid.
>>
>> R
>>
>
> toUpperInPlace IIRC? Yes, -vgc would not directly help here as
> toUpperInPlace is a library function. But I think this is a library /
> documentation bug:
>
> 1: We should explicitly document if a function is not supposed to
>     allocate
> 2: If a function is called "inPlace" but can still allocate, it needs a
>     huge red warning.
>
> Those kind of things can be solved partially with correctly documented
> functions. But hidden allocations caused by the language (closures,
> array literals) are imho more dangerous and -vgc could help there.
> Without -vgc it's very difficult to verify if some code could call into
> the gc.
>
> Btw: implementing -vgc shouldn't be too difficult: We have to check all
> runtime hooks ( http://wiki.dlang.org/Runtime_Hooks ) for allocations,
> then check all places in dmd where calls to those hooks are emitted.
>

It's actually very easy to find hidden allocations. If you remove the gc entierly from the runtime hidden allocations will cause linker errors.

Kind Regards
Benjamin Thaut

-- 
Kind Regards
Benjamin Thaut

On 10 April 2013 23:15, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:

> On 4/10/13, Manu <turkeyman@gmail.com> wrote:
> > The _problem_ is that functions are virtual by default.
> > It's a trivial problem to solve, however it's a major breaking change, so
> > it will never happen.
>
> I wouldn't say never.
>

... don't get my hopes up!


In fact, it might go hand-in-hand with changing how protection
> attributes affect virtuality (currently they do, I'd argue they
> shouldn't)
>
> For example one argument against allowing private and package methods the ability to be virtual is performance, namely these methods are now non-virtual and would suddenly become virtual if we allowed private/package overrides (because users typically don't mark private/package methods as final).
>
> However if we at the same time introduced a virtual keyword, then the private/package methods would remain non-virtual.
>
> What would break are public methods which are overriden but don't use the virtual keyword. So it's a breaking change but at least you won't get any performance degradation by accident.
>

Rather, you'll gain innumerably, thanks to every property/accessor now
being non-virtual as it should be.
You make a compelling argument, although I'm easily sold on sich matters!
It could be staggered in over a few releases... ie, in one release,
'virtual' is introduced - does nothing - encouraged to update code, next
release, complain that missing virtual is deprecated, next release, turn it
on proper; compile errors...
Walter would have a meltdown I think :P

Another reason I like the idea of a virtual keyword is that it
> documents the method better. The user of a library would clearly see a method can be overriden because it's marked as virtual, rather than having to guess whether the method was left non-final on purpose or by accident (accidents like that can happen..).
>

Hmm, this sounds familiar... where have I heard that before? ;)

On 10 April 2013 23:45, Benjamin Thaut <code@benjamin-thaut.de> wrote:

> Am 09.04.2013 14:00, schrieb Johannes Pfau:
>
>  Am Tue, 09 Apr 2013 11:29:09 +0100
>> schrieb "Regan Heath" <regan@netmail.co.nz>:
>>
>>> A good & simple start would be a -vgc switch, similar to -vtls which
>>>> prints out all hidden memory allocations. Custom allocators are still important for the library (toString etc). Apart from that I would just stay away from language features which allocate. For example instead of using the concatenate operators I'd just use something like appender (which should then support custom allocators).
>>>>
>>>
>>> Did you see Manu's problem case?  I can't recall the method name but it was not one which suggested it would allocate, and it didn't in the general case but in a very specific case it did.  As it stands, it's very hard to tell which language features allocate (without code inspection of the compiler and standard library) so it's hard to avoid.
>>>
>>> R
>>>
>>>
>> toUpperInPlace IIRC? Yes, -vgc would not directly help here as toUpperInPlace is a library function. But I think this is a library / documentation bug:
>>
>> 1: We should explicitly document if a function is not supposed to
>>     allocate
>> 2: If a function is called "inPlace" but can still allocate, it needs a
>>     huge red warning.
>>
>> Those kind of things can be solved partially with correctly documented functions. But hidden allocations caused by the language (closures, array literals) are imho more dangerous and -vgc could help there. Without -vgc it's very difficult to verify if some code could call into the gc.
>>
>> Btw: implementing -vgc shouldn't be too difficult: We have to check all
>> runtime hooks ( http://wiki.dlang.org/Runtime_**Hooks<http://wiki.dlang.org/Runtime_Hooks>) for allocations,
>> then check all places in dmd where calls to those hooks are emitted.
>>
>>
> It's actually very easy to find hidden allocations. If you remove the gc entierly from the runtime hidden allocations will cause linker errors.
>

Not a particularly user-friendly approach. I'd rather think of some proper tools/mechanisms to help in this area :)

On Wed, 10 Apr 2013 13:51:18 +0200, Jacob Carlborg <doob@me.com> wrote:

> On 2013-04-10 11:44, Regan Heath wrote:
>
>> They just start out "virtually" virtual until
>> the compiler is finished compiling them and all derived classes, at that
>> point all non-override base methods should be non-virtual.
>
> The compiler doesn't perform that optimization, at all.
>
And, as Manu has tried pointing out, it can't.

-- 
Simen

On 4/10/13 7:30 AM, Manu wrote:
> The _problem_ is that functions are virtual by
> default. It's a trivial problem to solve, however it's a major breaking
> change, so it will never happen.

I agree. We may as well save our breath on this one.

> Hence my passing comment that spawned this whole thread, I see it as the
> single biggest critical mistake in D, and I'm certain it will never be
> changed. I've made my peace, however disappointing it is to me.

I disagree with the importance assessment, but am soothed by your being at peace.


Andrei

> It is possible, but it heavily crippeles the language and requires modifications to druntime.
>
> See: http://3d.benjamin-thaut.de/?p=20
>
> Also see my GC free version of druntime:
> https://github.com/Ingrater/druntime
>
> My GC free version of phobos (heavily crippeled):
> https://github.com/Ingrater/phobos
>
> And my little GC free "standard library":
> https://github.com/Ingrater/thBase
>
> Its quite fun doing it when you want to learn new things, but I would not recommend doing so in a real wordl project.

Given what you have learned about GC-free D how practical would it be to modify D's core to work without garbage collection and then build libraries on top of this which make their GC use explicit? It seems to me that this is a level of modularity that should have been built in from the start.

On 4/10/13 8:44 AM, Manu wrote:
> On 10 April 2013 22:37, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org <mailto:SeeWebsiteForEmail@erdani.org>>
> wrote:
>
>     On 4/10/13 2:02 AM, Manu wrote:
>
>         I do use virtual functions, that's the point of classes. But most
>         functions are not virtual. More-so, most functions are trivial
>         accessors, which really shouldn't be virtual.
>
>
>     I'd say a valid style is to use free functions for non-virtual
>     methods. UFCS will take care of caller syntax.
>
>
> Valid, perhaps. But would you really recommend that design pattern?
> It seems a little obscure for no real reason. Breaks the feeling of the
> OO encapsulation principle somewhat.

It may as well be a mistake that nonvirtual functions are at all part of a class' methods. This has been quite painfully seen in C++ leading to surprising conclusions: http://goo.gl/dqZrr.

> I've started using UFCS more recently, but I'm still wary of overuse
> leading to unnecessary obscurity.

UFCS is a "slam dunk" feature - simple and immensely successful. The only bummer is that UFCS arrived to the scene late. If I designed D's classes today, I'd only allow overridable methods and leave everything else to free functions.


Andrei