<div dir="ltr">On 8 June 2013 01:23, deadalnix <span dir="ltr"><<a href="mailto:deadalnix@gmail.com" target="_blank">deadalnix@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><span style="color:rgb(34,34,34)">Requiring classes to be exported provide the following benefit :</span><br></div>
 - 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.<br>

 - Shared object can be stripped of all non exported symbols, reducing their size.<br>
 - Reduce the surface area of breakage for shared objects.<br>
<br>
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).<br>

<br>
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.<br>
<br>
Executive summary :<br>
 - We can provide a toll to finalize the whole program.<br>
 - We can automatically finalize everything that isn't exported.<br>
 - We don't break any code.<br>
 - We get consistency between windows and UNIXes.<br>
 - Manu will rant.<br>
<br>
I see only benefits :D<br>
</blockquote></div><br></div><div class="gmail_extra" style>It's like you've missed most of my points though.</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>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?</div>
<div class="gmail_extra" style>Many architectures will most certainly never receive support, and these are usually the architectures that need it most.</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>
Put that aside for a second, it's still flawed in a basic sense.</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>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.</div>
<div class="gmail_extra" style>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.</div><div class="gmail_extra" style>
<br></div><div class="gmail_extra" style>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.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>What am I left with? Basically nothing.</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>And finally, even if none of these problems existed, you still don't want virtual methods across export boundaries.</div>
<div class="gmail_extra" style>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.</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>So, basically none of my usages are satisfied by your proposal.</div><div class="gmail_extra" style>Sorry.</div></div>