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

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

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.