On 8 June 2013 01:23, deadalnix <deadalnix@gmail.com> wrote:
Requiring classes to be exported provide the following benefit :
 - LTO can finalize methods that aren't overridden. It include function that you want virtual by design, but you don't use that capability is your specific situation. In this regard, this is superior to the explicit virtual solution as it do not require to annotate virtual and can finalize method that would have to be annotated virtual.
 - Shared object can be stripped of all non exported symbols, reducing their size.
 - Reduce the surface area of breakage for shared objects.

It however require careful crafting of exported objects. I think this is mitigated by the fact that shared object interface require careful crafting anyway, as what is exported cannot be unexported (and cannot even change its ABI in way that aren't easily visible in the source).

The solution can be completed later by a tool as Andrei proposed (great idea), but by itself provide a lot of opportunity to finalize automagically. As you argued, this is the best way to go.

Executive summary :
 - We can provide a toll to finalize the whole program.
 - We can automatically finalize everything that isn't exported.
 - We don't break any code.
 - We get consistency between windows and UNIXes.
 - Manu will rant.

I see only benefits :D

It's like you've missed most of my points though.

So under this proposal, which *entails* said 'sufficiently advanced optimiser/linker/etc', which doesn't exist. And even if it did, what architectures are supported?
Many architectures will most certainly never receive support, and these are usually the architectures that need it most.

Put that aside for a second, it's still flawed in a basic sense.

Anything 'exported' still falls under precisely the same set of problems as we have now. By exporting something, NOTHING can be de-virtualised, even when used internally. And exported things DO get used internally. So by exporting, you lose all benefit within your own code anyway.
I can tell you that in my case, we export a lot(/most) things. Renderer api, sound api, etc are often all in their own libraries. So none of them are ever eligible for optimisation.

Additionally, one of my central points is completely un-satisfied, that is, 3rd party libraries. To make use of them at all implies they are exported, so there is never any possibility for optimisation there.

What am I left with? Basically nothing.

And finally, even if none of these problems existed, you still don't want virtual methods across export boundaries.
Just because you use a class implemented in a DLL, that doesn't prevent you from inlining the trivial accessors within your own code. Using a library is an ABI commitment anyway, and it's completely normal to inline foreign libraries trivial methods within your own code.

So, basically none of my usages are satisfied by your proposal.
Sorry.