Back to Better
Now, back to our shiny solution based on a single CallStream mechanism and generic bridge specialized by “customers” for their specific purposes.
Imagine we have a customer which wants to hide her complex “things” behind a CallStream and thus make her solution look nice and easy and eminently usable. Accidentally the same customer is keen on functors, How would that customer quickly subscribe to the CallStream concept and implement a small layer of code necessary?
First, a simple functor has to be invented to act as a primary type passed into call streams and used to create a bridge specialization that will be used by the c++ compiler, to pass the calls and parameters to the code “behind”.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
/* Abstract base to all functors specific to this example */ class Functor { protected std::string tag_ ; public: /* in this example each functor inheritor must have an 'operator (va_list &)' implemented */ virtual void operator ()( va_list & vl ) const = 0 ; /* method to show functor type and value held using std::cout by default */ virtual void show ( std::ostream & out_ = std::cout ) const = 0 ; }; /* The CallStream bridge specialization that will reach to any kind-of-a Functor above */ template<> inline void bridge<Functor> (const Functor & gf, va_list & vl) { std::cout << std::endl << "Bridge to the " << typeid(gf).name(); gf(vl); // passing to the functor variable number of arguments gf.show() ; // showinf the type and value held } |
CallStream need not be changed for this customer to use it and it’s a specialized bridge to be found and used. Also in this example, everything is in the same namespace (dbj), while in reality Functor above will be in a separate namespace. Again we could imagine and present a solution where Functor will not deal with va_list‘s. That would require the more complex bridge to decode the parameters etc. Instead, I have made a solution with templatized functors, who “know” what type and value they are dealing with. For example:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
/* The generic functor which deals with different types of arguments sent through call stream. */ template<typename T> class GFunctor : public Functor { public: typedef T ValueType; typedef GFunctor<T> MyType ; typedef GFunctor<T> * MyTypePtr ; protected : T value_ ; MyType & This () const { return * const_cast<MyTypePtr>(this);} public: GFunctor( const char * tag ) { if ( tag ) This().tag_ = strdup(tag) ; else This().tag_ = "" ; } /*This functor requires exactly one argument of type T*/ virtual void operator ()( va_list & vl ) const { This().value_ = va_arg( vl, T ); } virtual void show ( std::ostream & out_ = std::cout ) const { out_ << "nFunctor of type " << typeid(*this).name() << ", is holding the type " << typeid(T).name() << ", and the value is: " << value_ ; } }; |
Since the customer is using functors here, we could pass some useful data inside functors instances too.
|
1 2 3 4 5 6 7 8 9 10 |
const dbj::Functor & gf = dbj::GFunctor<int>("LABEL"); /* make a functor to deal with single int's */ const dbj::CallStream & cs = dbj::CallStream() ; /*Again the same single CallStream is used */ cs (gf,9) // "LABEL" and 9 are available to the implementation (gf,6); // "LABEL" and 6 |
But now we are encroaching into the customer’s domain. The code that was necessary to use (or be used by) CallStream is short and sweet. And it is perfectly applicable for anyone using functors with CallStream.
One more example and that is it. This “post” is already turning into a “booklet” ;) This time I will pay attention to CallStream customers who are at the same time perhaps implementing some library in the (right) spirit of c++ std::: a lot of generic functions and the whole solution in header files. Still, they want to have a “CallStream enabled” interfacing to their library. Let’s keep this one simple but still valid c++.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
/* the whole 'ops' library is made out of inline generic functions and no specializations */ namespace ops { /* generic functions to add or multiply "anything" that has binary '+' and '*' operators */ template<typename T> inline T add( const T & a, const T & b) { return a + b ; } template<typename T> inline T mul( const T & a, const T & b) { return a * b ; } /* int_int_int is a function pointer type to a concretized form of generic ops above which are concretized with an int type */ typedef int ( * int_int_int ) ( const int &, const int & ) ; } |
This is the whole library. And here is the code required so that CallStream users can use it.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
namespace dbj { /*This bridge will be called for all the ops generic functions which are concretized as dealing with int's CallStream need not be changed for this bridge to be found and used. */ inline void bridge (const ops::int_int_int operation, va_list & vl ) { int op1 = va_arg( vl, int ); int op2 = va_arg( vl, int ); int rez = operation(op1,op2) ; std::cout << std::endl << "Bridge to the " << typeid(operation).name() << " result of operation(" << op1 << "," << op2 << ") is : " << rez ; } } // namespace dbj |
Yes, just this one specialized bridge is enough for the CallStream mechanism to find it and to pass calls to the “ops” library operations.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
void main( int /*argc*/, wchar_t * /*argv*/[] ) { const dbj::CallStream & cs = dbj::CallStream() ; cs (ops::add<int>,3,5) (ops::mul<int>,4,6) (ops::add<float>,2.3,7.12) ; // works but generic bridge is called } |
Also, just to confirm the CallStream malleability, if one passes the ‘ops’ operation which is not having its bridge yet , the code will still work, it is only that generic bridge will be called. Of course, the CallStream instance above is valid for passing to it any calls. It is the same as before. It will find any specialized bridge presented here, to pass these calls to their intended implementations.
Conclusion
All these C++ “snazzy” idioms, are not here because of my “requirements” or dictate. I am showing all these used with/by CallStream to confirm the eligibility of the whole concept for the C++ programming too.
1Or template concretization, as I am calling it. And a few others, too.