www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - why cant structs have base structs

reply Regan Heath <regan netwin.co.nz> writes:
This:

struct a {
}

struct b : a {
}

is not valid, the spec does not seem to allow it, why not?

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 23 2004
next sibling parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Regan Heath wrote:

 This:
 
 struct a {
 }
 
 struct b : a {
 }
 
 is not valid, the spec does not seem to allow it, why not?
My guess: Structs cannot have virtual functions (adding that feature would mean overhead which should be avoided for structs) Without virtual functions, the behavior of struct-inheritance would be strangely different from the behavior of class-inheritance, where every public function is implicitly virtual. Furthermore: without polymorphism (which would require virtual functions) inheritance is just a matter of saving some typing. And for that, you can also use mixins.
Jun 23 2004
next sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Thu, 24 Jun 2004 07:52:11 +0200, Norbert Nemec <Norbert.Nemec gmx.de> 
wrote:
 Regan Heath wrote:

 This:

 struct a {
 }

 struct b : a {
 }

 is not valid, the spec does not seem to allow it, why not?
My guess: Structs cannot have virtual functions (adding that feature would mean overhead which should be avoided for structs)
Agreed.
 Without virtual functions, the behavior of struct-inheritance would be
 strangely different from the behavior of class-inheritance, where every
 public function is implicitly virtual.
Different, yes. Strange .. not so long as it's documented.
 Furthermore: without polymorphism (which would require virtual functions)
 inheritance is just a matter of saving some typing. And for that, you can
 also use mixins.
Ok. You've convinced me. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 23 2004
parent reply Daniel Horn <hellcatv hotmail.com> writes:
Regan Heath wrote:
 On Thu, 24 Jun 2004 07:52:11 +0200, Norbert Nemec <Norbert.Nemec gmx.de> 
 wrote:
 
 Regan Heath wrote:

 This:

 struct a {
 }

 struct b : a {
 }

 is not valid, the spec does not seem to allow it, why not?
My guess: Structs cannot have virtual functions (adding that feature would mean overhead which should be avoided for structs)
Agreed.
 Without virtual functions, the behavior of struct-inheritance would be
 strangely different from the behavior of class-inheritance, where every
 public function is implicitly virtual.
Different, yes. Strange .. not so long as it's documented.
 Furthermore: without polymorphism (which would require virtual functions)
 inheritance is just a matter of saving some typing. And for that, you can
 also use mixins.
Ok. You've convinced me.
but what if you wanted to pass a SuperThing into a function that only took a thing and didn't want to use templates struct Thing{ float amt; } struct SuperThing :Thing { char[] name; } now it's not just a matter of saving typing, but actually having it do all the things you could with thing. in C you'd use an anonymous union to accomplish this-- is that also possible in D? struct Thing { float amt; }; struct SuperThing { union { float amt; Thing thing; }; char[] name; };
 Regan
 
Jun 23 2004
next sibling parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Daniel Horn wrote:

 Furthermore: without polymorphism (which would require virtual
 functions) inheritance is just a matter of saving some typing. And for
 that, you can also use mixins.
Ok. You've convinced me.
but what if you wanted to pass a SuperThing into a function that only took a thing and didn't want to use templates
That's just what I mean with "polymorphism" - as mentioned: polymorphism demands for virtual functions, and these mean overhead. If you want polymorphism, use classes. (There is no point in using polymorphism without handling the objects by reference, anyway.)
Jun 23 2004
parent reply Jan-Eric Duden <jeduden whisset.com> writes:
Norbert Nemec wrote:
 Daniel Horn wrote:
 
 
Furthermore: without polymorphism (which would require virtual
functions) inheritance is just a matter of saving some typing. And for
that, you can also use mixins.
Ok. You've convinced me.
but what if you wanted to pass a SuperThing into a function that only took a thing and didn't want to use templates
That's just what I mean with "polymorphism" - as mentioned: polymorphism demands for virtual functions, and these mean overhead. If you want polymorphism, use classes. (There is no point in using polymorphism without handling the objects by reference, anyway.)
"polymorphism" does not demand for virtual functions by default. in C++ i could do the following: struct MyPolyStruct { int type; }; struct A : public MyPolyStruct { int a; } struct C : public MyPolyStruct { float c[1000]; } void bla(MyPolyStruct* p) { switch(p->type) { //do stuff } } I still need to do a cast to get the subclass data, but this is a bit "type-safier" than doing this in D: template MyPolyType { int type; }; struct Base { mixin MyPolyType; } struct A { mixin MyPolyType; int a; } struct C { mixin MyPolyType; float c[1000]; } int bla(void* p) // need to use void ptr here { switch((cast(Base)p).type) { //do stuff } } some times you need to do this stuff, f.e. when you implement functions that work on binary formats. Standard polymorphism doesn't help here at all. Are there better solutions for doing this kind of stuff in D? Note that using unions doesn't really help ( without having memory overhead): struct MyPolyStruct { int type; union { int a; float c[1000]; } data; }; Jan-Eric
Jun 24 2004
next sibling parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Jan-Eric Duden wrote:
 Are there better solutions for doing this kind of stuff in D?
Use classes! The only reason to use struct instead of class is, if you want value-semantics (as opposed to reference semantics which are the only available behaviour for classes in D) Polymorphism is generally only possible when handling references. (Since the size of an inheriting class is not known, it cannot be passed by value) Your C++ example uses a pointer to a struct. In D, you should simply use a class for that.
Jun 24 2004
next sibling parent Jan-Eric Duden <jeduden whisset.com> writes:
Norbert Nemec wrote:
 Jan-Eric Duden wrote:
 
Are there better solutions for doing this kind of stuff in D?
Use classes! The only reason to use struct instead of class is, if you want value-semantics (as opposed to reference semantics which are the only available behaviour for classes in D) Polymorphism is generally only possible when handling references. (Since the size of an inheriting class is not known, it cannot be passed by value) Your C++ example uses a pointer to a struct. In D, you should simply use a class for that.
You can't use classes in some cases. With classes you can't model an exact binary layout. With classes you have memory overhead that is too large in some cases.Custom allocators won't help all the time. A small example: I have a file with 1,000,000 objects. all objects have the same size. I need to do some sorting and other stuff. the object size is 16 bytes. 16 MB is not too much for my memory requirements. I allocate just one chunk of memory. read all the objects into that chunk. hold a struct pointer on that chunk. easy and efficient. If I have to do that with class objects... I get gc overhead for 1 million objects, 1 million times a monitor, 1 million times a virtual function table pointer, ... 1 million new calls, 1 million read calls. In that case structs a just better. Jan-Eric
Jun 24 2004
prev sibling parent Daniel Horn <hellcatv hotmail.com> writes:
Norbert Nemec wrote:
 Jan-Eric Duden wrote:
 
Are there better solutions for doing this kind of stuff in D?
Use classes!
classes are on the heap, structs can be on the stack--this is important--esp if you're doing something like a number sort of class or a vector
 
 The only reason to use struct instead of class is, if you want
 value-semantics (as opposed to reference semantics which are the only
 available behaviour for classes in D)
 
 Polymorphism is generally only possible when handling references. (Since the
 size of an inheriting class is not known, it cannot be passed by value)
 
 Your C++ example uses a pointer to a struct. In D, you should simply use a
 class for that.
 
Jun 24 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
You can do the following:

struct A { ... }

struct B
{
    A a;
    ... more members ...
}
Jul 01 2004
next sibling parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:cc0hlu$9gv$2 digitaldaemon.com...
 You can do the following:

 struct A { ... }

 struct B
 {
     A a;
     ... more members ...
 }
Or even (maybe) better: struct A() { } struct B { mixin A!(); // ... more members ... }
Jul 01 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Thu, 1 Jul 2004 14:12:37 +0200, Ivan Senji <ivan.senji public.srce.hr> 
wrote:

 "Walter" <newshound digitalmars.com> wrote in message
 news:cc0hlu$9gv$2 digitaldaemon.com...
 You can do the following:

 struct A { ... }

 struct B
 {
     A a;
     ... more members ...
 }
Or even (maybe) better: struct A() { } struct B { mixin A!(); // ... more members ... }
Nope: mixin A!() A is not a template Besides which you cannot use a mixin to add private members. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 01 2004
parent reply "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsahbksx25a2sq9 digitalmars.com...
 On Thu, 1 Jul 2004 14:12:37 +0200, Ivan Senji <ivan.senji public.srce.hr>
 wrote:

 "Walter" <newshound digitalmars.com> wrote in message
 news:cc0hlu$9gv$2 digitaldaemon.com...
 You can do the following:

 struct A { ... }

 struct B
 {
     A a;
     ... more members ...
 }
Or even (maybe) better: struct A() { } struct B { mixin A!(); // ... more members ... }
Nope: mixin A!() A is not a template
I am a real idiot for not trying to add member variables.
 Besides which you cannot use a mixin to add private members.
I tried this and it seems that i can template A() { int x,y; } struct B { private mixin A!(); float a,b; } And i get a nice message "struct B A!().x is private" B b; b.a=3; b.x=4;//<-error here but ofcourse it has to be in another module to manifest this behaviour!
 Regan

 --
 Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 02 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Fri, 2 Jul 2004 09:06:25 +0200, Ivan Senji <ivan.senji public.srce.hr> 
wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsahbksx25a2sq9 digitalmars.com...
 On Thu, 1 Jul 2004 14:12:37 +0200, Ivan Senji 
 <ivan.senji public.srce.hr>
 wrote:

 "Walter" <newshound digitalmars.com> wrote in message
 news:cc0hlu$9gv$2 digitaldaemon.com...
 You can do the following:

 struct A { ... }

 struct B
 {
     A a;
     ... more members ...
 }
Or even (maybe) better: struct A() { } struct B { mixin A!(); // ... more members ... }
Nope: mixin A!() A is not a template
I am a real idiot for not trying to add member variables.
 Besides which you cannot use a mixin to add private members.
I tried this and it seems that i can template A() { int x,y; } struct B { private mixin A!(); float a,b; } And i get a nice message "struct B A!().x is private" B b; b.a=3; b.x=4;//<-error here but ofcourse it has to be in another module to manifest this behaviour!
Yes you can do that, what I actually mean't to say was, you cannot go... template A() { public: void foo() { bar(); } private: int a; } struct B { mixin A; void bar() { a = 5; } } 'int a' is private to mixin A and not accessable at all to B. But, now that I think about it, were I allowed to go... struct A { public: void foo() { bar(); } private: int a; } struct B : A { mixin A; void bar() { a = 5; } } it wouldn't work either as (I assume) A's privates would not be accessable to B (using standard C++ class inheritance etc). So my workaround to make the private section protected is probably the correct way to do it anyway. I'll go put my head in a paper bag now :) (not plastic - cos that's dangerous) Regan.
 Regan

 --
 Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 02 2004
parent "Ivan Senji" <ivan.senji public.srce.hr> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsaigb8o15a2sq9 digitalmars.com...
 On Fri, 2 Jul 2004 09:06:25 +0200, Ivan Senji <ivan.senji public.srce.hr>
 wrote:

 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsahbksx25a2sq9 digitalmars.com...
....... Yes you can do that, what I actually mean't to say was, you cannot go...
I finally understand what is troubling you. I read yout previous posts about this but didn't have any time to try it out.
 template A()
 {
 public:
 void foo() {
 bar();
 }
 private:
 int a;
 }

 struct B
 {
 mixin A;
 void bar() {
 a = 5;
 }
 }

 'int a' is private to mixin A and not accessable at all to B. But, now
 that I think about it, were I allowed to go...

 struct A {
 public:
 void foo() {
 bar();
 }
 private:
 int a;
 }

 struct B : A {
 mixin A;
 void bar() {
 a = 5;
 }
 }

 it wouldn't work either as (I assume) A's privates would not be accessable
 to B (using standard C++ class inheritance etc).
Yes i also think you are right, mixin has its own scope and decides what to give access to.
 So my workaround to make the private section protected is probably the
 correct way to do it anyway.
Conclusion: your workaround isn't a workaround at all, but the way it should work.
 I'll go put my head in a paper bag now :)
 (not plastic - cos that's dangerous)
:)
 Regan.

 Regan

 --
 Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
-- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 02 2004
prev sibling next sibling parent Regan Heath <regan netwin.co.nz> writes:
On Thu, 1 Jul 2004 01:11:15 -0700, Walter <newshound digitalmars.com> 
wrote:

 You can do the following:

 struct A { ... }

 struct B
 {
     A a;
     ... more members ...
 }
That's not the same. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 01 2004
prev sibling parent reply Regan Heath <regan netwin.co.nz> writes:
On Thu, 1 Jul 2004 01:11:15 -0700, Walter <newshound digitalmars.com> 
wrote:

 You can do the following:

 struct A { ... }

 struct B
 {
     A a;
     ... more members ...
 }
Should this work? --[test.d]-- struct A { int aaa; int bbb; } struct B { A a_instance; alias a_instance.aaa aaa; alias a_instance.bbb bbb; } void main() { B b; b.aaa = 5; b.bbb = 6; } Cos it gives: test.d(7): identifier 'aaa' of 'a_instance.aaa' is not defined Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 01 2004
parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 02 Jul 2004 16:12:07 +1200, Regan Heath wrote:

 struct A {
 	int aaa;
 	int bbb;
 }
 struct B {
 	A a_instance;
 	alias a_instance.aaa aaa;
 	alias a_instance.bbb bbb;	
 }
 
 void main() {
 	B b;
 	
 	b.aaa = 5;
 	b.bbb = 6;
 }
This works ... #struct A { #struct B { #void main() { But doesn't help if you have two or more instances of A inside B. -- Derek Melbourne, Australia 2/Jul/04 2:19:58 PM
Jul 01 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Fri, 2 Jul 2004 14:27:17 +1000, Derek Parnell <derek psych.ward> wrote:

 On Fri, 02 Jul 2004 16:12:07 +1200, Regan Heath wrote:

 struct A {
 	int aaa;
 	int bbb;
 }
 struct B {
 	A a_instance;
 	alias a_instance.aaa aaa;
 	alias a_instance.bbb bbb;	
 }

 void main() {
 	B b;
 	
 	b.aaa = 5;
 	b.bbb = 6;
 }
This works ... #struct A { #struct B { #void main() { But doesn't help if you have two or more instances of A inside B.
Thanks.. I still have not got the hang of aliases like this. :) I am trying to emulate having a base struct (like a base class only no virtual functions etc), so there will not be more than one instance of A inside B. This workaround isn't too bad so long as there aren't too many members in the 'base' struct. You can go another level deep but it requires some copy/pasting... struct A { int var1; int var2; } struct B { A a; alias A.var1 var1; alias A.var2 var2; int var3; int var4; } struct C { B b; alias B.var1 var1; alias B.var2 var2; alias B.var3 var3; alias B.var4 var4; } void main() { C c; c.var1 = 5; c.var2 = 6; c.var3 = 7; c.var4 = 8; } Walter: it would be nice if the above could be achieved with struct A { int var1; int var2; } struct B : A { int var3; int var4; } struct C : B { } Much simpler! Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 01 2004
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Daniel Horn wrote:
 struct Thing{
  float amt;
 }
 struct SuperThing :Thing {
   char[] name;
 }
 
 now it's not just a matter of saving typing, but actually having it do 
 all the things you could with thing.
 in C you'd use an anonymous union to accomplish this-- is that also 
 possible in D?
 
 struct Thing {
  float amt;
 };
 
 struct SuperThing {
  union {
    float amt;
    Thing thing;
  };
  char[] name;
 };
What you code here should work...though I don't know why you wouldn't just include the Thing directly. The union is unnecessary: struct SuperThing { Thing thing; char[] name; }; If you want to implement something that looks more like C++ inheritance, you can do it with properties: struct SuperThing { Thing super; float amt() { return super.amt; } float amt(float f) { return super.amt = f; } char[] name; }; You don't get implicit casting, but that's not too hard: Thing* castThing(SuperThing* s) { return s.super; } Likewise, you can even implement constructors and virtual functions by hand if you want; but you have to run the constructor by hand, and make sure it initialized the virtual functions allright: struct Thing { struct { int delegate() foo; } vtbl; void Constructor() { this.vtbl.foo = &this.foo; } int foo() { ...do stuff... } float amt; } struct SuperThing { Thing super; float amt() { return super.amt; } float amt(float f) { return super.amt = f; } void Constructor() { super.Constructor(); super.vtbl.foo = &this.foo; } int foo() { ...do stuff... } char[] name; } Thing thing1; thing1.Constructor(); SuperThing thing2; thing2.Constructor(); Thing *ptr1; Thing *ptr2; ptr1 = &thing1; ptr2 = castThing(&thing2); ptr1.vtbl.foo(); // runs Thing.foo() ptr2.vtbl.foo(); // runs SuperThing.foo()
Jun 24 2004
parent Jan-Eric Duden <jeduden whisset.com> writes:
Russ Lewis wrote:

 Daniel Horn wrote:
 
 struct Thing{
  float amt;
 }
 struct SuperThing :Thing {
   char[] name;
 }

 now it's not just a matter of saving typing, but actually having it do 
 all the things you could with thing.
 in C you'd use an anonymous union to accomplish this-- is that also 
 possible in D?

 struct Thing {
  float amt;
 };

 struct SuperThing {
  union {
    float amt;
    Thing thing;
  };
  char[] name;
 };
What you code here should work...though I don't know why you wouldn't just include the Thing directly. The union is unnecessary: struct SuperThing { Thing thing; char[] name; }; If you want to implement something that looks more like C++ inheritance, you can do it with properties: struct SuperThing { Thing super; float amt() { return super.amt; } float amt(float f) { return super.amt = f; } char[] name; }; You don't get implicit casting, but that's not too hard: Thing* castThing(SuperThing* s) { return s.super; } Likewise, you can even implement constructors and virtual functions by hand if you want; but you have to run the constructor by hand, and make sure it initialized the virtual functions allright: struct Thing { struct { int delegate() foo; } vtbl; void Constructor() { this.vtbl.foo = &this.foo; } int foo() { ...do stuff... } float amt; } struct SuperThing { Thing super; float amt() { return super.amt; } float amt(float f) { return super.amt = f; } void Constructor() { super.Constructor(); super.vtbl.foo = &this.foo; } int foo() { ...do stuff... } char[] name; } Thing thing1; thing1.Constructor(); SuperThing thing2; thing2.Constructor(); Thing *ptr1; Thing *ptr2; ptr1 = &thing1; ptr2 = castThing(&thing2); ptr1.vtbl.foo(); // runs Thing.foo() ptr2.vtbl.foo(); // runs SuperThing.foo()
that looks like a reasonable solution. it's not too much work for doing this kind of rare stuff. with mixins you can do this, too: struct Thing { // stuff }: template BaseStruct { Thing myThing; Thing* castThing() { return &myThing; } }; struct A { mixin BaseStruct; int stuffint; };
Jun 24 2004
prev sibling parent "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Norbert Nemec" <Norbert.Nemec gmx.de> wrote in message
news:cbdq61$2u6v$1 digitaldaemon.com...
 Regan Heath wrote:

 This:

 struct a {
 }

 struct b : a {
 }

 is not valid, the spec does not seem to allow it, why not?
My guess: Structs cannot have virtual functions (adding that feature would mean overhead which should be avoided for structs) Without virtual functions, the behavior of struct-inheritance would be strangely different from the behavior of class-inheritance, where every public function is implicitly virtual. Furthermore: without polymorphism (which would require virtual functions) inheritance is just a matter of saving some typing. And for that, you can also use mixins.
Very nice point! I knew there was a point to trawling the posts tonight. Thanks for that. :)
Jun 24 2004
prev sibling parent reply Brian <Brian_member pathlink.com> writes:
In article <opr92xf8ba5a2sq9 digitalmars.com>, Regan Heath says...
This:

struct a {
}

struct b : a {
}

is not valid, the spec does not seem to allow it, why not?

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
It isn't allowed because structs in d are c style structs not c++ style stucts. In C the struct makes a data aggregate. For C++ this is not the case. The struct key word is equivalent to class foo{ public:} by that I mean it creates a class which defaults to public instead of private. So it has all of that over head you wish to avoid.
Jul 01 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Thu, 1 Jul 2004 15:15:36 +0000 (UTC), Brian <Brian_member pathlink.com> 
wrote:

 In article <opr92xf8ba5a2sq9 digitalmars.com>, Regan Heath says...
 This:

 struct a {
 }

 struct b : a {
 }

 is not valid, the spec does not seem to allow it, why not?

 Regan

 --
 Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
It isn't allowed because structs in d are c style structs not c++ style stucts.
I know. Currently, they are...
 In C the struct makes a data aggregate. For C++ this is not the case. 
 The struct
 key word is equivalent to class foo{ public:}  by that I mean it creates 
 a class
 which defaults to public instead of private.  So it has all of that over 
 head
 you wish to avoid.
The overhead comes when it's implemented as you suggest. You can implement structs with inheritance and without virtual functions to remove all that overhead. similar to: struct A { } struct B { mixin A; } however there are 2 problems with this soln. 1. it does not work, you cannot mixin a struct. 2. you cannot use a mixin to add 'private' members. What I want is to be able to say: struct A { virtual void bar(); private: void foo(); } struct B : A { void bar() { foo(); } } Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 01 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Fri, 02 Jul 2004 10:07:51 +1200, Regan Heath <regan netwin.co.nz> wrote:

 On Thu, 1 Jul 2004 15:15:36 +0000 (UTC), Brian 
 <Brian_member pathlink.com> wrote:

 In article <opr92xf8ba5a2sq9 digitalmars.com>, Regan Heath says...
 This:

 struct a {
 }

 struct b : a {
 }

 is not valid, the spec does not seem to allow it, why not?

 Regan

 --
 Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
It isn't allowed because structs in d are c style structs not c++ style stucts.
I know. Currently, they are...
 In C the struct makes a data aggregate. For C++ this is not the case. 
 The struct
 key word is equivalent to class foo{ public:}  by that I mean it 
 creates a class
 which defaults to public instead of private.  So it has all of that 
 over head
 you wish to avoid.
The overhead comes when it's implemented as you suggest. You can implement structs with inheritance and without virtual functions to remove all that overhead. similar to: struct A { } struct B { mixin A; } however there are 2 problems with this soln. 1. it does not work, you cannot mixin a struct. 2. you cannot use a mixin to add 'private' members. What I want is to be able to say: struct A { virtual void bar(); private: void foo(); } struct B : A { void bar() { foo(); } }
Small correction, there should be a body in the void foo() function in struct A. My current workaround is to make A a template, and to make foo protected rather than private. Regards, Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 01 2004