View mode: basic / threaded / horizontal-split · Log in · Help
August 23, 2012
Non-virtual private struct inheritance
In C++, it is a very common practice, when writing a struct 
template, to have said template derive from a base non-template 
struct. This makes sure there is no executable bloat, and, more 
often than not, the inheritance is private, so invisible to users 
(no "interface leak").

For instance, std::list is a classic example of this: First, you 
have the template create a node, and then you defer to the base 
class for all insertions/deletions, that don't really care about 
what a T is.

My first question is: Is such an approach even encouraged in D? 
Or is the module compilation system able to see through what 
does/doesn't depend on these parameters?

Can be swapping inheritance for member variables, or free 
standing external methods. Both works most of the time, but 
neither are quite as polyvalent.

...

D being a heavily templated system language, executable size is 
something that should be controlable, correct? Is there any 
chance we could see this kind of limited inheritance for structs? 
As in just basic non-polymorphous inheritance? I seem to remember 
a few threads about other users wishing for inheritance with 
structs...
August 23, 2012
Re: Non-virtual private struct inheritance
monarch_dodra:

> In C++, it is a very common practice, when writing a struct 
> template, to have said template derive from a base non-template 
> struct. This makes sure there is no executable bloat,

"alias this" seems to help both for composition and against 
template bloat:


struct Foo {
    int x;
    int bar() { return x * 2; }
}
struct Bar(T) {
    Foo f;
    T y;
    alias f this;
}
void main() {
    Bar!int b1;
    b1.x = 10;
    assert(b1.bar() == 20);
    Bar!double b2;
    b2.x = 100;
    assert(b2.bar() == 200);
}


In the asm listing there is only one bar:

_D3foo3Foo3barMFZi:
    enter 4, 0
    mov EAX, [EAX]
    add EAX, EAX
    leave
    ret


Another way to fight template bloat is the @templated() I have 
suggested elsewhere, that applied to something inside a template 
allows you to choose what that something is templated to (even 
nothing).

Bye,
bearophile
August 23, 2012
Re: Non-virtual private struct inheritance
On Thursday, 23 August 2012 at 13:17:23 UTC, bearophile wrote:
> monarch_dodra:
>
>> In C++, it is a very common practice, when writing a struct 
>> template, to have said template derive from a base 
>> non-template struct. This makes sure there is no executable 
>> bloat,
>
> "alias this" seems to help both for composition and against 
> template bloat:
>
>
> struct Foo {
>     int x;
>     int bar() { return x * 2; }
> }
> struct Bar(T) {
>     Foo f;
>     T y;
>     alias f this;
> }
> void main() {
>     Bar!int b1;
>     b1.x = 10;
>     assert(b1.bar() == 20);
>     Bar!double b2;
>     b2.x = 100;
>     assert(b2.bar() == 200);
> }
>
>
> In the asm listing there is only one bar:
>
> _D3foo3Foo3barMFZi:
>     enter 4, 0
>     mov EAX, [EAX]
>     add EAX, EAX
>     leave
>     ret
>
>
> Another way to fight template bloat is the @templated() I have 
> suggested elsewhere, that applied to something inside a 
> template allows you to choose what that something is templated 
> to (even nothing).
>
> Bye,
> bearophile

Thanks for the answer. Very nice. "alias this" is still the first 
thing I think about, but in this case, it works perfectly well 
actually.
Top | Discussion index | About this forum | D home