Today's C++ question, Fit the Second.

[Pix]

struct B1
{
int i;

funcb1() { i = ...; }
};

struct B2
{
funcb2() { ... }
};

struct D : public B1, public B2 // do I need the "public"?
{
};

funcb2 needs the value of i. What's a good way to get it out of B1?

I'm thinking about putting a setter/getter in D that will cache a copy of i, and then calling the setter in funcb1 and the getter in funcb2. Cross-casting doesn't seem to work, or else I'm doing it wrong: trying ((B1)this).i in B2 doesn't seem to work, although I didn't really expect it to.

[RonHiler]

struct D : public B1, public B2 // do I need the "public"?

Technically, no, not for structures, but IMO it's best to state it explicitely anyway.

funcb2 needs the value of i. What's a good way to get it out of B1?

Depends. Where are you calling funcb2 from? If the only call into the function is from Struct D, you could just pass it as a parameter of the function.

Otherwise there is no relationship between your two base classes. Just because they are both a parent of D doesn't mean they can share member data, unless you provide some specific functionality for that (or pass it in through the derived class).

Is it possible for you to do this?

struct B1 {};
struct B2 : public B1 {};
struct D : public B2 {};

That would give you i inside of B2 where your funcb2() lives. Plus, then you don't have multiple inheretance issues to worry about.

[Pix]

Technically, no, not for structures, but IMO it's best to state it explicitely anyway.


Depends. Where are you calling funcb2 from? If the only call into the function is from Struct D, you could just pass it as a parameter of the function.

funcb2 is being called from outside of D. It needs the value of i, but i only exists in B1.

Otherwise there is no relationship between your two base classes. Just because they are both a parent of D doesn't mean they can share member data, unless you provide some specific functionality for that (or pass it in through the derived class).

Is it possible for you to do this?

struct B1 {};
struct B2 : public B1 {};
struct D : public B2 {};

That would give you i inside of B2 where your funcb2() lives. Plus, then you don't have multiple inheretance issues to worry about.

I could certainly do that but from a design standpoint, it doesn't make sense, as B2 isn't based on B1.

[RonHiler]

funcb2 is being called from outside of D. It needs the value of i, but i only exists in B1.

Okay, then the fact that they are parents of another class is irrelevant. Basically you have two different classes, and you need a value in Class B1 to run a method in B2. You will need a getter function in B1 to grab that value for use in B2. Class D has nothing to do with anything in this case.

I could certainly do that but from a design standpoint, it doesn't make sense, as B2 isn't based on B1.

Fair enough. Then you are doing the right thing.

[Pix]

Okay, then the fact that they are parents of another class is irrelevant. Basically you have two different classes, and you need a value in Class B1 to run a method in B2. You will need a getter function in B1 to grab that value for use in B2. Class D has nothing to do with anything in this case.

Ok, but now for the 23¢ question: In the real world B1 and B2 are siblings in D. How do I get them to communicate with each other? In B1, you can't cast the this pointer to a B2 *. Well, you can, but it doesn't work. What about this: I add 1-arg setters to B1 and B2. The parameter is a pointer to the OTHER class. Then in D's ctor, I call both setters. Let me think about the syntax...

B1::SetB2(B2 *b2) { ... }
B2::SetB1(B1 *b1) { ... }

then:

D:() : ...
{
SetB2( (B1 *)this);
SetB1( (B2 *)this);
}

and finally I add a getter on B1, int GetI() { return i; }, and when I need B1.i in funcb2, I can say local_i = GetI();

This is all COM stuff. Generally, a nice, clean way to implement a crapload of interfaces is to create a class for each one, and then create a superclass that derives from all of 'em. So far, you only run into problems where two of the bases have the same function name (and there's ways to deal with that) or, as I've just found, when one of them needs something another one has.

I guess I could couple everything a bit more tightly, and remove all the internal values from the base class, promoting them into the derived one, and then put getters and setters on the derived class that the bases would use. Let's see...I'd still need to pass the derived this to the bases, though. I need the equivalent of the MSVC-specific __super keyword, but in the other direction, and for members as well as methods.

[Pix]

Oh my stars and garters, I just figured out a totally evil way to do what I want.

See, I was simplifying, of course. B1::i isn't just an int, it's actually a pointer to an interface on another object (that's not mine.) I wanted that pointer in B2, because I was going to call a function on the interface that would enumerate something.

Thanks to some reading on MSDN, I just realized that in the method in B2 that wants i, I could just create another instance of that (foreign) object, ask it for a new interface pointer, and then call the enumeration function on THAT object. I don't actually need the original object, as (I am assuming ) the set of IDs will be static.

[Pix]

And that turns out not to work, anyway; at least not in the time I was willing to allocate.

I've found more instances of needing to pass information between the various base classes. I've started moving the members into the derived class. Then I create a SetParent() method on each base. The derived's ctor calls the various SetParents, passing this. Then I put setters and getters in the various bases and the derived class. So far it's on a pretty ad-hoc basis, and I may need to revisit the solution at some point.

The goal is to have a theoretically mostly-reusable set of base classes, each of which implements (generally) one COM interface. How useful this will be to me in the long run, I'm not sure.