c++ metacall()()()™

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”.

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:

Since the customer is using functors here, we could pass some useful data inside functors instances too.

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++.

This is the whole library. And here is the code required so that CallStream users can use it.

Yes, just this one specialized bridge is enough for the CallStream mechanism to find it and to pass calls to the “ops” library operations.

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.

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.

%d bloggers like this: