On Wednesday, 10 April 2013 at 11:31:08 UTC, Manu wrote:
> I feel like I'm being ignored. It's NOT POSSIBLE.

Well, this is not 100% true. It is possible if you just say "hey, I prohibit you to use dll or any other way to leak symbols from binary and please no separate compilation in any form". But I doubt one can consider it a viable option.

On Wed, 10 Apr 2013 12:00:04 +0100, Manu <turkeyman@gmail.com> wrote:

> On 10 April 2013 20:53, Regan Heath <regan@netmail.co.nz> wrote:
>
>>
>> False.  In this first example we are compiling A and B together (into an
>> exe - I left that off) so the compiler has all sources and all uses of all
>> methods of A (and B).
>>
>
> And if the program calls LoadLibrary() somewhere?
>
>
>  notVirt is virtual.
>>>
>>
>> It may actually be (I don't know) but it certainly does not have to be
>> (compiler has all sources/uses) and my impression was that it /should/ not
>> be.
>
>
> It doesn't have all sources. It could load a library. That can never be
> guaranteed.

So, your counter example is this..

[shared source]
class A {}

[example DLL]
class B : A {}
compiled along with source for A.

[example application]
class C : A {}
compiled along with source for A.

main() {}
calls LoadLibrary which loads above DLL, DLL manifests an A, which is actually a B, e.g.

A fromDLL = ...exported DLL function...

or perhaps we constrct a B

A fromDLL = new B();

And if we were to manifest our own C, derived from A

A local = new C();

the methods which would be virtual/non-virtual might very well differ.  So how can the compiler know what to do when it sees:

void foo(A a)
{
   a.method();
}

Correct?

I must admit I don't know how a class is exported from a DLL.  Presumably the method address is exported.  But, does the vtbl get exported, or do virtual methods all map to a wrapper method which indexes the vtbl?

In any case, it seems to me that the underlying issue is the desire to have 2 separate definitions for A.  One from the DLL, and one local to the application.  And, for calls to optimised on the local one in the ususal fashion, while maintaining the DLL mandated virtual/non-virtual methods at the same time.

R

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

On Wed, 10 Apr 2013 12:30:56 +0100, Manu <turkeyman@gmail.com> wrote:

> On 10 April 2013 21:09, Regan Heath <regan@netmail.co.nz> wrote:
>
>> On Wed, 10 Apr 2013 11:59:32 +0100, Dicebot <m.strashun@gmail.com> wrote:
>>
>>  On Wednesday, 10 April 2013 at 10:53:26 UTC, Regan Heath wrote:
>>>
>>>> Hmm..
>>>>
>>>>  A is not final.
>>>>>
>>>>
>>>> True.  But, I don't see how this matters.
>>>>
>>>>  A has no internal linkage. It can be inherited from in other
>>>>> compilation unit.
>>>>>
>>>>
>>>> False.  In this first example we are compiling A and B together (into an
>>>> exe - I left that off) so the compiler has all sources and all uses of all
>>>> methods of A (and B).
>>>>
>>>>  notVirt is virtual.
>>>>>
>>>>
>>>> It may actually be (I don't know) but it certainly does not have to be
>>>> (compiler has all sources/uses) and my impression was that it /should/ not
>>>> be.
>>>>
>>>> R
>>>>
>>>
>>> If it is compiled all at once and compiled into executable binary than
>>> yes, you examples are valid and compiler _MAY_ omit virtual.
>>>
>>
>> Exactly the point I was trying to make.  I wanted to establish the point
>> at which the design problems (what D defines/intends to do) arise, vs when
>> the implementation problems arise (DMD not doing what D intends).
>>
>>
>>  But
>>> a) DMD doesn't do it as far as I am aware.
>>>
>>
>> Maybe, maybe not.  I have no idea.  My understanding of the design
>> decision is that DMD will eventually do it.
>
>
> I feel like I'm being ignored. It's NOT POSSIBLE.

You're not.  The issue here is my understanding of the problem (and compilation etc in general) and why you believe it's an insurmountable problem.  I am trying to both understand the issue and explore possible solutions.

R

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

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.

-- 
/Jacob Carlborg

On Wed, 10 Apr 2013 12:51:18 +0100, 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.

Ok.  I've always assumed that it would tho, at some stage.  Or is that not the intention?

R

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

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.

Andrei

On 04/09/2013 04:43 PM, Nick Sabalausky wrote:
>
> - Starcraft?: Starcraft is 15 years old, so it isn't an example of a
>    modern AAA title in the first place.

StarCraft II came out a few years ago and sold very well. They also just released the second installment of it within the past month or so, and considering it is essentially an over-priced expansion pack, it also sold very well.

> In the ones I identified as "interactive movie", cinematic presentation
> deeply permeates the entire experience, gameplay and all.

Translation: Wearing your gumpy-old-man goggles, you dismiss games that feature lots of cinematics as "interactive movies", even though there is plenty of core gameplay to be had.

There *are* games that are essentially interactive movies, like Heavy Rain for example, or LA Noire, but putting shooters like BioShock Infinite or GTA (when doing the missions) in this category is ridiculous.

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.

On 2013-04-10 11:19, Dicebot wrote:

> The question is then "what is class?". Because the very reason to have
> class is to have guaranteed polymorphic behavior, so that working with
> object via its base will always make sense without any fears about what
> behavior can be overriden. But that is mostly needed in OOP hell with
> few practical cases like plugins.
>
> If essentially coupling data and methods is needed, that is what struct
> does. I am not arguing that everything should be virtual, I am arguing
> that you actually need classes. It is not C++ and, in my opinion,
> structs should be much more common entities than classes, especially in
> performance-hungry code.

I often want reference types, but not necessarily polymorphic types.

What I want:

* Heap GC allocated
* Be able to store references

What I don't want:

* Pointers (don't guarantee heap allocated)
* ref parameters (can't store the reference)
* Implement reference counting

-- 
/Jacob Carlborg

On Wednesday, 10 April 2013 at 12:46:28 UTC, Jacob Carlborg wrote:
> I often want reference types, but not necessarily polymorphic types.
>
> What I want:
>
> * Heap GC allocated
> * Be able to store references
>
> What I don't want:
>
> * Pointers (don't guarantee heap allocated)
> * ref parameters (can't store the reference)
> * Implement reference counting

I find this more of an issue with "ref" being a second-class citizen instead of proper type qualifier.