On 9 April 2013 13:09, Rob T <alanb@ucora.com> wrote:

> On Monday, 8 April 2013 at 08:21:06 UTC, Manu wrote:
>
>>
>> The C++ state hasn't changed though. We still avoid virtual calls like the
>> plague.
>> One of my biggest design gripes with D, hands down, is that functions are
>> virtual by default. I believe this is a critical mistake, and the biggest
>> one in the language by far.
>>
>
> My understanding of this is that while all of your class functions will be virtual by default, the compiler will reduce them to non-virtual unless you actually override them, and to override by mistake is difficult because you have to specify the "override" keyword to avoid a compiler error.
>

Thus successfully eliminating non-open-source libraries from D... Making a dependency on WPO is a big mistake.


I'd like to see that understanding confirmed as it was only implied in here:
> http://dlang.org/overview.html
>
> For extra safety you have to specify "final" which would be a pain if that's what you want by default, but I'm not so sure it's really necessary if the compiler really does optimize virtual functions away.
>
> BTW, the red code/green code concept sounds like the most promising route towards a generalized solution. I'll try and find the time to watch it as well.
>
> --rt
>

On Mon, 08 Apr 2013 19:02:19 +0100, Johannes Pfau <nospam@example.com> wrote:

> Am Mon, 08 Apr 2013 11:57:08 +0100
> schrieb "Regan Heath" <regan@netmail.co.nz>:
>
>> On Mon, 08 Apr 2013 09:58:15 +0100, Manu <turkeyman@gmail.com> wrote:
>> > I suspect Andrei for one knows this, and that's why the D
>> > containers are so... barely existing. The language is not yet ready
>> > to say with confidence
>> > how they should look.
>>
>> That, and before you can design the containers you need a concrete
>> allocator interface design.  Actually, this is likely the same
>> blocker for GC-free D as well.
>>
>> D should have a set of global allocator hooks.  If it did, you could
>> easily catch unexpected allocations in tight loops and realtime
>> code.  If it did, GC-free D would be trivial - just replace the
>> default GC based allocator with a malloc/free one, or any other
>> scheme you like.
>>
>
> IIRC stuff like closures and dynamic array appending rely on a gc and
> it wouldn't be trivial to change that to a normal alloc/free allocator.

True, my comment actually contained 2 ideas, neither of which I explained properly :p

Idea #1.  Have alloc/realloc/free hooks for use /with/ the GC.  Allowing Manu to catch unexpected allocations, or provide the GC with memory from a pre-allocated block etc.  In this case we'd probably want the allocator to control when the GC performed collection - to avoid it in realtime code.

I think this rather simple idea would give a lot more control and flexibility to applications with realtime requirements.  As Manu himself said (IIRC) he doesn't mind the GC, what he minds is the hidden allocations which themselves cause a delay, and I would imagine he would mind even more if a collection was triggered by one :p


Idea #2.  Replace the GC with allocators.  In this case, as you say, without a GC we would have problems catching the 'free' for objects like closures and arrays (as we'd have no reference to them in user code upon which to call 'destroy' or similar.

So, we'd either have to replace the GC with reference counting /and/ have some compiler support for triggers on references leaving scope, for example.  Or, we could require code to call 'destroy' on everything to be freed and force users to keep references to closures and arrays and 'destroy' them.

There are likely cases where the user code never sees the closure reference, in this case the allocator itself could perform some object tracking.  We could aid this by having an allocation 'type' allowing the allocator to track only closure or array allocations - for example, and ignore user allocations where it assumes the user code will call 'destroy' on the reference (as delete/free would be called in C/C++).

> 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

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On 04/09/2013 12:18 PM, Manu wrote:
> ...
>
> Thus successfully eliminating non-open-source libraries from D...
> Making a dependency on WPO is a big mistake.
> ...

Inheritance is usually a bad way to reuse library functionality anyway.

On 9 April 2013 21:02, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 04/09/2013 12:18 PM, Manu wrote:
>
>> ...
>>
>>
>> Thus successfully eliminating non-open-source libraries from D...
>> Making a dependency on WPO is a big mistake.
>> ...
>>
>
> Inheritance is usually a bad way to reuse library functionality anyway.
>

Who said anything about inheritance? What if I want to call a method? len = x.length for instance? Properties are almost always really trivial leaf functions. But they're all virtual calls! O_O

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.

On 04/09/2013 01:09 PM, Manu wrote:
> On 9 April 2013 21:02, Timon Gehr <timon.gehr@gmx.ch
> <mailto:timon.gehr@gmx.ch>> wrote:
>
>     On 04/09/2013 12:18 PM, Manu wrote:
>
>         ...
>
>
>         Thus successfully eliminating non-open-source libraries from D...
>         Making a dependency on WPO is a big mistake.
>         ...
>
>
>     Inheritance is usually a bad way to reuse library functionality anyway.
>
>
> Who said anything about inheritance? What if I want to call a method?
> len = x.length for instance? Properties are almost always really trivial
> leaf functions. But they're all virtual calls! O_O

If you do not want to add overrides, then there is no dependency on WPO.

Eh? How so? Overrides may or may not come from anywhere...
Actually, a DLL may introduce an override that's not present at link time.
Even WPO can't save it.


On 9 April 2013 22:12, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 04/09/2013 01:09 PM, Manu wrote:
>
>> On 9 April 2013 21:02, Timon Gehr <timon.gehr@gmx.ch <mailto:timon.gehr@gmx.ch>> wrote:
>>
>>     On 04/09/2013 12:18 PM, Manu wrote:
>>
>>         ...
>>
>>
>>         Thus successfully eliminating non-open-source libraries from D...
>>         Making a dependency on WPO is a big mistake.
>>         ...
>>
>>
>>     Inheritance is usually a bad way to reuse library functionality
>> anyway.
>>
>>
>> Who said anything about inheritance? What if I want to call a method? len = x.length for instance? Properties are almost always really trivial leaf functions. But they're all virtual calls! O_O
>>
>
> If you do not want to add overrides, then there is no dependency on WPO.
>

On 04/09/2013 02:30 PM, Manu wrote:
> Eh? How so? Overrides may or may not come from anywhere...
> Actually, a DLL may introduce an override that's not present at link
> time. Even WPO can't save it.
> ...

That would not be a case of 'there are no overrides'.

09-Apr-2013 14:18, Manu пишет:
> On 9 April 2013 13:09, Rob T <alanb@ucora.com <mailto:alanb@ucora.com>>
> wrote:
>
>     On Monday, 8 April 2013 at 08:21:06 UTC, Manu wrote:
>
>
>         The C++ state hasn't changed though. We still avoid virtual
>         calls like the
>         plague.
>         One of my biggest design gripes with D, hands down, is that
>         functions are
>         virtual by default. I believe this is a critical mistake, and
>         the biggest
>         one in the language by far.
>
>
>     My understanding of this is that while all of your class functions
>     will be virtual by default, the compiler will reduce them to
>     non-virtual unless you actually override them, and to override by
>     mistake is difficult because you have to specify the "override"
>     keyword to avoid a compiler error.
>
>
> Thus successfully eliminating non-open-source libraries from D...
> Making a dependency on WPO is a big mistake.
>

final class Foo{ //no inheritance
final: //no virtuals
...
}

2 extra words and you are done. The only problem I see is that there is no way to "undo" final on a few methods later...

-- 
Dmitry Olshansky

On 2013-04-09 16:50, Dmitry Olshansky wrote:

> final class Foo{ //no inheritance
> final: //no virtuals
> ...
> }
>
> 2 extra words and you are done. The only problem I see is that there is
> no way to "undo" final on a few methods later...

Isn't "final" on the class enough. No point in having virtual methods if nothing can inherit from the class.

-- 
/Jacob Carlborg