how to refactor this class template to minimize boiler-plate code?

Question

I've recently started using boost mirror for ORM reflection so I can minimize the amount of DB-related boiler-plate code.

One kind of pattern I've run into is listed below.

Since Bar's code is going to look identical even for Baz, I was wondering, is it possible to collapse this code any further?

It would be nice if the getValues() interface would look the same, but the identical implementation could also live in Foo instead.

#include <iostream>

template< typename T >
struct Foo
{
    static std::ostream& GetValues_Worker( std::ostream& os, T const& t )
    {
        // do boost mirror reflection stuff here
        return os;
    }
};

struct Bar : 
    public Foo<Bar>
{
    // REFACTOR IF POSSIBLE:  this code will always look the same - even for Baz
    std::ostream& 
    getValues( std::ostream& os ) const
    {
        return GetValues_Worker( os, *this );
    }
};

struct Baz : 
    public Foo<Baz>
{
    // REFACTOR IF POSSIBLE:  looks the same as Bar
    std::ostream& 
    getValues( std::ostream& os ) const
    {
        return GetValues_Worker( os, *this );
    }
};

int main( int argc, char* argv[] )
{
    Bar b;
    std::cerr << b.getValues( std::cerr ) << std::endl;
}

ANSWER

It turns out that ecatmur's answer below works in most cases. In my specific situation, I adapted his solution to my real code, it worked in 2 out of 4 cases. In the two cases where it failed to work, it was a bit beyond the scope of the Mickey-Mouse example that I gave above. The closest explanation that I could find in SO which explains the compile-time errors I was getting is probably this post. The crux of the problem appeared to be related to what was happening inside my Worker code. In the two failed cases, I was doing output streaming of the subclasses' members based on what I was getting back from runtime reflection results in boost mirror. I think this is turned out to be a case of non-deducible context. I still don't understand why the solution in those two failed cases works exactly (why using a visitor in the form of a virtual method gets around the issue). Anyhow, I stumbled upon that approach and was trying to reduce the code some more (in those 4 cases), but in two of them, I couldn't really reduce that code any more without running into the non-deducible context issue.

I didn't put a Baz because it would look the same as Bar - I'll add... — kfmfe04, Dec 18 '12 at 13:43
If you have two classes that looks and behaves the same, why have two classes? If they are _mostly_ the same, then you could have a common base class. As you already have a common base class, why not simple make the common functions `virtual` members of the base class? — Some programmer dude, Dec 18 '12 at 13:44
What's the point of having `Bar` and `Baz` then? Just remove one and only use the other. — Kerrek SB, Dec 18 '12 at 13:45
@KerrekSB `Bar` and `Baz` are abstractions for different database objects/tables (eg Cat, Dog, Frog tables and objects) - I am using boost mirror to minimize boiler-plate code required to provide functionality to INSERT/DELETE/UPDATE, for instance... — kfmfe04, Dec 18 '12 at 13:48

ecatmur · Accepted Answer · 2012-12-18T14:00:30.097

4

Bar::getValues can be moved to Foo<Bar> using a CRTP downcast:

template< typename T >
struct Foo
{
    static std::ostream& GetValues_Worker( std::ostream& os, T const& t )
    {
        // do boost mirror reflection stuff here
        return os;
    }

    std::ostream& getValues( std::ostream& os ) const
    {
        return GetValues_Worker( os, *static_cast<T const *>(this) );
    }
};

At this point you might as well combine the two methods:

template< typename T >
struct Foo
{
    std::ostream& getValues( std::ostream& os ) const
    {
        T const &t = *static_cast<T const *>(this);
        // do boost mirror reflection stuff here
        return os;
    }
};

edited Dec 18 '12 at 14:00

answered Dec 18 '12 at 13:44

ecatmur

152,476
27
293
366

+1 YES! I think this is what I need - tyvm for the simplified code – kfmfe04 Dec 18 '12 at 13:46
One quick addendum - if that function happened to be `operator==( T const&)` instead, would I be forced to leave it in `Bar` and `Baz` and use the two tier call? – kfmfe04 Dec 18 '12 at 14:09
@kfmfe04 not at all; `Foo` can write `bool operator==(T const &) const` and the correct operator will be picked up by `Bar` and `Baz`. – ecatmur Dec 18 '12 at 14:16
After several hours of digging around in SO, I think I'm beginning to understand my special case now. It has to do with my funky mixing of templates which require compile-time knowledge of types vs my use of reflection, which is necessarily requires dynamic typing. I will add notes to the OP for future reference. – kfmfe04 Dec 18 '12 at 19:31

how to refactor this class template to minimize boiler-plate code?

1 Answers1