Multiple return values...

Artur Skawina art.08.09 at gmail.com
Sun Mar 11 12:18:53 PDT 2012


On 03/11/12 18:45, Manu wrote:
> On 11 March 2012 18:45, Artur Skawina <art.08.09 at gmail.com <mailto:art.08.09 at gmail.com>> wrote:
> 
>     Other than that, there is devirtualization - D does not have 'virtual'; the compiler
>     can still do it and even inline the virtual methods, but it needs to know that
>     nothing overrides the functions - impossible w/o WPO for public non-final classes. [1]
[...]
> virtual-by-default seems like the single biggest and most harmful _mistake_ in the whole language.
> Defaulting a feature that introduces very costly damage that ONLY a WPO pass can possibly un-do can only be described as insanity.

Well, there is 'final' and limiting the visibility can help too ('private' etc).

> /validating/ a method is not overridden anywhere is NOT a trivial task. Being able to do this with confidence will be tedious and waste unimaginable amounts of time and frustration...

CPUs won't complain and their time is relatively cheap. :)
IOW, if it can be done by the compiler then it should.

> If I were evaluating D to use commercially, this would be the biggest red flag to consider. The time/efficiency costs could potentially be very high.

If it can be done automatically in C++, by looking just at the generated RTTI in object
files, then a similar approach should work for D. I don't think this is such a big
problem, especially compared to some things which currently are inexpressible in D. 

eg: http://drdobbs.com/184401938

>     > My understanding is that templates depends on .d/.di files being present during compilation? So why doesn't D do inlining the same way? If I declare some inline function in a .d/.di file, surely it should be capable of inlining?
>     > C/C++ can't inline something from a foreign object either without a definition in a header...
> 
>     It's the same for D, I just don't think *.di files should be necessary for _internal_
>     cross-module interfaces, or when the full source is available anyway.
>     Currently, cross-module inlining is a problem for GDC, but even when that's fixed,
>     WPO will help things like devirtualization or changing calling conventions (gcc does
>     it already, but i don't know if it clones non-local functions just for this, when not
>     in WPO mode).
> 
> 
> So assuming that most libraries will be closed source, what's the implication here for inlines and tempaltes long term? It sounds no different than .h files.
> Is there a plan to be able to store that metadata inside lib/object files somehow? (I assume not, if there was, why need .di files at all)

Well, if you distribute your library as closed source, you can't expect compile time
optimizations to work across the app/lib boundary - you can't both have the cake and
eat it. Note you *can* add enough information to the object files so that the compiler
can do a better job -- simply by compiling your library with LTO enabled. While this
effectively turns closed-source into obfuscated-source, it's possible to do this
selectively on a by unit basis - which can be acceptable in some situations.
And if your closed-source library exports non-final classes you may not really want
devirtualization; marking certain members as final would probably be good idea anyway.
So *.di files work the same as *.h -- you only have to expose the API and can add as
much extras as you can/want.

artur


More information about the Digitalmars-d mailing list