Announcement

[Pix]

The curiously recurring template pattern is the bees' knees.

[Pix]

It also, I think, solved my problem, with one digression.

consider:

template <typename T>
class A<T>
{
public:
    int i;

    int funca();
};

template <typename T>
class B<T>
{
public:
    int funcb();
};

template <typename T>int B<T>::funcb()
{
    static_cast<T*>(this)->funca();
}

class C: public A<C>, public B<C>
{
    int c;
    int funcc() { return funca() + funcb(); }
};

int main(void)
{
    C c;
    
    std::cout << c.funcc() << std::endl;
    return 0;
}

Barring typos this code will work just fine. There is one caveat: the scope of a template instatiation is implementation-defined. In MSVC, if you put each class in it's own source file, it has to be a header. Well, it has to be included into the main program. putting the definition in a .h and the code in a .cpp will not work--you get unresolved external errors. Other compilers (supposedly gcc, but I've never tried it) can have the template in one compilation unit and the derived class in another, supposedly.

[RonHiler]

Ugg. Template metaprogramming . Better you than me

Barring typos this code will work just fine. There is one caveat: the scope of a template instatiation is implementation-defined. In MSVC, if you put each class in it's own source file, it has to be a header. Well, it has to be included into the main program. putting the definition in a .h and the code in a .cpp will not work--you get unresolved external errors. Other compilers (supposedly gcc, but I've never tried it) can have the template in one compilation unit and the derived class in another, supposedly.

Yeah. This is a pet peeve of mine, and one reason why I tend not to use templates in general. You know how I feel about code in the h files It can't be helped in some cases. Case it point, the Memory Manager uses template functions quite a bit.

[Pix]

ROFL!

Well, I'm not sure how you'd easily do this without templates! (First answer: one giant honking class. Second answer: sub-objects instead of MI.) This is pretty cool.

I'd love to try this on a compiler that doesn't have the limitation on compilation units, but I'm lazy. Having said that, I've seen a style where people #include the .cpp, but I find that offensive. Generally I agree with you about code in .h files.

Aside: my God, iostreams make your code fat, or maybe it's STL in general. My project generates a 300K object file and a 200K executable with a couple of uses of cout. Take that out and you're talking about 17K of object and 45K of exe. I don't know quite how the relative sizes got swapped but whatever.

Still: CRTP is a very clean way, stylistic objections aside, to deal with talking to your siblings across an inheritance tree, and it drastically reduces the number of interconnections I'm going to need.

[RonHiler]

ROFL!

Well, I'm not sure how you'd easily do this without templates! (First answer: one giant honking class. Second answer: sub-objects instead of MI.) This is pretty cool.

No, I agree with you. Templates are the way to go here.

I'd love to try this on a compiler that doesn't have the limitation on compilation units, but I'm lazy. Having said that, I've seen a style where people #include the .cpp, but I find that offensive.

Indeed.

[Pix]

Next up, figuring out how to work multithreading into the mix. Worse, the simplest way to do what I want involves having two threads in an STA. I think. Which obviously you can't do.

I want my control to spin off a worker thread, which will periodically notify the object that it's been updated and wants to redraw itself. I _think_ that you are supposed to acquire an advise sink from your container, and tell it your view has changed. There's a bunch of stuff in there I'm not sure how to make it work.

I wish I knew more C++ people, and some who also know COM.