On 07/06/13 17:28, Walter Bright wrote:
> On 6/6/2013 11:30 PM, Peter Williams wrote:
>> I use it to make sure that my unittests are complete.
>
> Awesome!
>
> -cov is also useful for:
>
> 1. debugging - if your unittests can't seem to cover certain lines,
> those lines might indicate a bug

That's what I meant by "unittests are complete" i.e. they cover all of the code.

>
> 2. performance - giving usage counts of lines tells you where the 'hot'
> paths are, and those can be hand-tuned
>
> It's also quite possible to have the compiler read the coverage report,
> use it to identify the hot paths, and rearrange the code while
> optimizing so that the hot paths have the fewest branches. Profile
> guided optimization, if you will.
>
>> Peter
>> PS It would be nice if it printed the overview (i.e. % complete line)
>> to stdout
>> as well as sticking it in the coverage file report.
>
> Please file this as an enhancement request on bugzilla.

Done.

Peter

On Friday, 7 June 2013 at 22:57:01 UTC, Walter Bright wrote:
> On 6/7/2013 9:51 AM, Rob T wrote:
>> If D had a compiler option switch to collect statistics on feature usage, maybe
>> you could get something a lot better than a guess for both 1 and 2.
>
> And then you'd have to convince people to use it and send you the results!

The stats gathering idea may be food for further thought. For example a more-likely-to-work method may be to allow users to rate features through the on-line documentation. You could derive a reasonably accurate idea of success and failings from such a thing. Perhaps something like this has been successfully done before that can serve as a model to emulate.

--rt

On 6/7/2013 5:15 PM, Manu wrote:
> 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.

I'm curious why these exports all must be classes, and cannot be structs?

On 8 June 2013 13:25, Walter Bright <newshound2@digitalmars.com> wrote:

> On 6/7/2013 5:15 PM, Manu wrote:
>
>> 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.
>>
>
> I'm curious why these exports all must be classes, and cannot be structs?
>

Because they embody functionality, not just data. That's just how many many
programmers write code.
Go to university for a couple of years, see what they tell you... ;)
Some of these systems can effectively be considered plugins. Consider
OpenGL/DirectX? DirectSound/XAudio? Linux has a million back-end API's to
choose from.
I can see why many people feel it's natural to design their API's/systems
that way, right or wrong.

I don't agree with it personally, I would write it differently, but I'll never win that argument. Tech/systems programmers are vastly outnumbered in most studios. And of course, most programmers are junior-mid experience, that's just commercial reality.

On Saturday, 8 June 2013 at 00:16:05 UTC, Manu wrote:
> 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.
>

It seems that you missed some of my points. LTO work by dumping the IR in object file. Linker with LTO enabled will read the ir, and redo the codegen. So the LTO is done before the codegen, and it shouldn't be a problem for most architectures.

I also recognize that architectures are not equal on that regard. My reasoning here is that ARM and X86 are roughly 90% of the CPU you'll find and they handle indirect branch nicely.

It is a bigger issue for other architectures, but it is desirable that architecture that are less used don't clutter the language.

> 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.
>

My point is that exported symbol require very careful crafting anyway. So caring about what is final or not is a concern.

Additionally, it is possible to use th following pattern :
export class Exported {
}

// All intern subclass inherit that one.
class NotExported : Exported {
}

And manipulated the NotExported class internally whenever it is possible. It allow for very precise crafting of the exported API, which is also a benefit.

> 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.
>

That is true. However, this would result in an opaque call anyway, so opportunity for optimization isn't that big. If this is a huge problem, the final keyword is here.

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

I said that you would rant, that one is quite nicela satisfied.

On Saturday, 8 June 2013 at 06:33:48 UTC, deadalnix wrote:
> ...

Btw, are there any reasons why "export" can't be applied on per-method basis instead of whole classes?

On Saturday, 8 June 2013 at 10:22:42 UTC, Dicebot wrote:
> On Saturday, 8 June 2013 at 06:33:48 UTC, deadalnix wrote:
>> ...
>
> Btw, are there any reasons why "export" can't be applied on per-method basis instead of whole classes?

For final method, no problem, but for virtual method, it is either all or nothing, as they share the same virtual table.

On Saturday, 8 June 2013 at 10:34:17 UTC, deadalnix wrote:
> On Saturday, 8 June 2013 at 10:22:42 UTC, Dicebot wrote:
>> On Saturday, 8 June 2013 at 06:33:48 UTC, deadalnix wrote:
>>> ...
>>
>> Btw, are there any reasons why "export" can't be applied on per-method basis instead of whole classes?
>
> For final method, no problem, but for virtual method, it is either all or nothing, as they share the same virtual table.

I don't see an issue. Non-export virtual methods can be implicitly final if compiler/linker finds so. It does not matter if they are in virtual table if no virtual table look-up happens. Any micro-example to clarify?

On Saturday, 8 June 2013 at 10:55:37 UTC, Dicebot wrote:
> On Saturday, 8 June 2013 at 10:34:17 UTC, deadalnix wrote:
>> On Saturday, 8 June 2013 at 10:22:42 UTC, Dicebot wrote:
>>> On Saturday, 8 June 2013 at 06:33:48 UTC, deadalnix wrote:
>>>> ...
>>>
>>> Btw, are there any reasons why "export" can't be applied on per-method basis instead of whole classes?
>>
>> For final method, no problem, but for virtual method, it is either all or nothing, as they share the same virtual table.
>
> I don't see an issue. Non-export virtual methods can be implicitly final if compiler/linker finds so. It does not matter if they are in virtual table if no virtual table look-up happens. Any micro-example to clarify?

It does matter that all parties agree on the layout of the virtual table.

Virtual method are never linked, it don't makeany sens to export them or not.

Even if no lookup for a given function is present, it is still important, because its presence change the layout of the virtual table, and so the lookup of other virtual methods.

On Saturday, 8 June 2013 at 03:59:25 UTC, Manu wrote:
> On 8 June 2013 13:25, Walter Bright <newshound2@digitalmars.com> wrote:
>
>> On 6/7/2013 5:15 PM, Manu wrote:
>>
>>> 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.
>>>
>>
>> I'm curious why these exports all must be classes, and cannot be structs?
>>
>
> Because they embody functionality, not just data. That's just how many many
> programmers write code.
> Go to university for a couple of years, see what they tell you... ;)
> Some of these systems can effectively be considered plugins. Consider
> OpenGL/DirectX? DirectSound/XAudio? Linux has a million back-end API's to
> choose from.
> I can see why many people feel it's natural to design their API's/systems
> that way, right or wrong.
>
> I don't agree with it personally, I would write it differently, but I'll
> never win that argument. Tech/systems programmers are vastly outnumbered in
> most studios. And of course, most programmers are junior-mid experience,
> that's just commercial reality.

Personally, I never understood why portability must pass by a plugin architecture. In our game engine we use macro to build the right implementation depending on the target platform and pure interfaces to be sure that API are respected.
It's not an issue, because the user don't have to be able to choose the sound backend, and developer can do it for testing but it requires a full rebuild (a real issue due to the C++ slow compilation).