Disable GC entirely

[Manu]

On 10 April 2013 19:44, Regan Heath <regan at netmail.co.nz> wrote:

> On Wed, 10 Apr 2013 09:56:01 +0100, Manu <turkeyman at gmail.com> wrote:
>
>  On 10 April 2013 17:01, Paulo Pinto <pjmlp at progtools.org> wrote:
>>
>>  On Wednesday, 10 April 2013 at 06:03:08 UTC, 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.
>>>> OOP by design recommends liberal use of accessors, ie, properties, that
>>>> usually just set or return a variable. Wen would you ever want @property
>>>> size_t size() { return size; } to be a virtual call?
>>>>
>>>>
>>> Yes, if you want to change its behavior in a derived class.
>>>
>>>
>> That really shouldn't be encouraged. Give me an example?
>>
>
> I wrote some crypto code which had a property for the hash size, each
> derived class returned it's own size.  Now, in this case the property
> size() was called rarely, but it's still a valid example.
>

But this is a trivial class, with 2 methods, size() and computeHash(). It's
also a primitive tool that should probably live in a standard library. It's
not the sort of code people are writing on a daily basis.

That said, I agree we don't generally want properties and other
> short-and-should-be-inlined methods to be virtual by default.  But.. is D
> really doing that?  I mean /actually/ really doing it.
>

Yes. People don't write final on everything. It's not a habit, and it's not
even recommended anywhere.

I have read most of this thread in passing and I've seen the earlier
> discussion about classes in libraries etc and TBH I am not sure how/what D
> does in those situations.  Presumably if D does not have the source for the
> library then the library class would have to have all methods virtual -
> just in case it was derived from and I guess this is an issue that needs
> solving somehow.  But, I don't know if this is the case, or if this is even
> an actual problem.
>

It's a problem. And I don't believe it's 'solvable'.
The only solution I can imagine is to not force the compiler into that
completely unknowable situation in the first place, by making virtual
explicit to begin with.

That's not the most common case however, the common case is a class you're
> compiling with the rest of your classes and in this case D is not going to
> make your base class methods (which have not explicitly been overridden)
> virtual, they should be non-virtual and optimised/inlined/etc.  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.
>

I don't see how this is possible, unless the instance was created in the
same local scope, and that's extremely unlikely.
Even if it has the source for my class, it can't ever know that the pointer
I hold is not a base to a more derived class. It could be returned from a
DLL or anything.
Everyone keeps talking like this is possible. Is it? I can't imagine any
way that it is.

It would be interesting to see what the compiler actually does if, for
> example, you compile a file with a class then in a separate compile/link
> step compile a derived class and link.  Does D manage to non-virtual all
> non-overridden methods?  If so, can it do the same with a lib/dll combo?


The compiler makes a virtual call. If a static lib, or a DLL is involved, I
don't see how the optimisation could ever be valid?

 That's not an exampe. I want to see a class where every function SHOULD be
>> overloaded... That sounds like a nightmare, how can anyone other than the
>> author ever expect to understand it? The fewer and more deliberately
>> controlled the virtuals, the better, by almost every measure I can
>> imagine.
>>
>
> This isn't the reasoning behind making virtual the virtual default for
> methods.  The reason for doing it was simply so the compiler could be
> responsible for figuring it out without you having to label it manually.


Yes but the compiler can't figure it out. It's not logically possible, it
must always assume that it could potentially be derived somewhere...
because it could.

 You're already labelling the derived class method "override" and that
> should be enough.  This was a choice of convenience and ultimately
> performance because you won't accidentally make a method virtual that
> doesn't need to be.


Sorry, I don't follow. How does this help?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130410/2671c7d9/attachment-0001.html>