On 03/11/12 18:45, Manu wrote:
> On 11 March 2012 18:45, Artur Skawina <art.08...@gmail.com
> <mailto:art.08...@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
