c++ metacall()()()™

A paradigm shift (or revolutionary science) is, according to Thomas Kuhn, in his influential book The Structure of Scientific Revolutions (1962), a change in the basic assumptions, or paradigms, within the ruling theory of science. It is in contrast to his idea of normal science.

metacall series


metacall broadly means: “call of calls”

Part 3 : C++ Binding

It is not attached to any programing language, yet metacall as a concept is born (and bred) in the domain of type-less JavaScript.  Slight difficulty is that good old/new/standard C++, is v.s. JavaScript, one strongly typed language. In English: types are everything.

Also, C++ is  compiled language, vs dynamic (interpreted) JavaScript. Although, metaclass is already implemented in C#. And conceptualy, as far as types are concerned, C# is somewhere in between, (but not in the middle !) even in it’s latest reincarnation.

Ditto, I think metacall must be implemented in C++ too. Let’s jump into the deep.

metacall is not an implementation idiom of a single programming language. It is an (application architecture) concept. And concept is not very good if it is not universally applicable. In which case it is not ubiquitous, and therefore not used everywhere by everyone. Not successful, in one word.

In case of C++, I have decided to make an (sort of a) type-less metacall type.  Which in  C++ is achieved with generic programming, aka “templates”.

Thus metacall C++, is an C++ interfacing mechanism which allows for more or less same call-streaming as in JavaScript. Where one can “call” anything with “any” arguments.

call_stream(first_1, a,b,c)               // call 1
           (first_2,1,2,true)             // call 2
           (first_3, 3.14, "literal") ;   // call 3

This is one “fluent” API indeed. And by default it is very forgiving.  metacall can be logical instance of any kind-of-a metacall type.  It just has to confirm to certain interface, which we shall see very soon. What matters here is this paradigm of “endless” stream of calls.

We shall follow here the “comand and arguments” paradigm. First argument of each call, by default defines the behaviour. If it is callable it will be simply called with the rest of the argument’s given, for one call. The “normal” equivalent of the above is:

first_1(a,b,c) ;
first_3(3.14, "literal");

Why would anybody use this?

Why not just using (for example) variable number of arguments mechanism ? I think it is simple:

metacall enables quick building of an fluent API.

metacall is giving place of control of the mechanism behind the API.

metacall quickly and succesfully hides the complexity. It is also an “facade pattern”.

Importan benefit here is dealing with legacy code. Three calls above are just any three old functions, but as part of metacall sequence suddenly they have a new meaning. The belong to the same API,  same logic in the back and are very likely, operating on the same data in the back. All very nicely encapsulated and decoupled from the callers.

Here is the usage of the c++17 implementation, I will show soon.

Above is the the real code that compiles and runs. (GitHub repository here). For each call in the stream, frist argument is significant. It is a “command”.

metacall core mechanism

The “metacall” default implementation allows calls where first argument and any other argument can be “anything”; a string literal, function, intrinsic type or object (aka class instance). With any number of any type of arguments . Of course “anything” that has to compile at the moment of usage in the C++ source.

Let’s jump straight to the default call stream code.

Perhaps surprisingly simple. So, in this solution there is one dbj::meta_call::call_streamer<PROC> class template, serving the needs of all.

Note: yes, I am aware of locking issue. In ISO C++ that is easy to solve, but it is not shown here, so we can focus on the core subject.  But why are there two classes?

metacall and processor are split into two, so that processor can be changed.

The metacall (functor) type makes the “meta calling” possible. It is also passing each call to the “processor” type in the back.

The “trick” is in the (generic) function template call operator. Where the operator (), has a simple task of passing the first argument and variable number of arguments sent, to the proc_() (aka “processor”) function. Where the real action happens. In the application space, that I am calling “behind”.

And that function is actually another functor. In the code (simplified, full code is on GitHub) it’s interface is this

[nextpage title=”What is happening here ?”]

Compiler dispatches all the calls from the main() examples, above to the particular “metacall” instance,  Each of them calls, is passed to the current processor, passed as template argument.  ::dbj::meta_call::default_processor is just the default one of the (potentially) many processors functors available.

Remember the first argument. It’s type decides what will be done with a paraticular  call, in the stream of calls.

This is how default processor behaves. It simply calls the first argument with the remaining arguments , if it is found to be invocable, that is. This is how the bridge between metacall mechanism and user defined types is established.

By default or by using user defined processor.

If it is not callable and there is no processor for a type of the first argument arrived into it, that call is by default simply logged.  The safe assumption is here, the user has already delivered a processor for dealing with that type. For an example see the user defind proceesor bellow which deals with booleans.

The term “bridge” sometimes used, by me, in this context means an “bridge” to the implementation. I am also using the term “bridge” because this implementation hiding concept, reminds me (somewhat) on the “bridge pattern” as described by Gof4.

Actual class diagram of metacall and the user processor (in this online project) is this:

metacall + user

Which processor/bridge functor is going to be used is decided by the users at compile time. It’s type is a template argument. Let us repeat the usage of this composition mechanism, from the main() above:

Here, user whose code is in the namespace user , has also provided her extension of the default processor. Here is its interface (yes, the actual code is in that project on line)

Thus in the main() where user has decided to use her own processor:

And now cst is completely interchangeable with the default metacall with the added benefit of user defined bool calls processing.

What we have till now is enough to use this modern c++ call-stream implementation. And enjoy its default behaviour.

[nextpage title=”Let’s clarify”]

Not to worry. Behavioural patterns are very flexible and difficult to grasp at first.  Here is a (uml sequence)  diagram showing metacall and processor dancing together.

Two calls: one to the exsiting function void add(int,int); and the other that provokes “not found and log”, iniside the processor.

There is no much more to it. That is the all of the functionality one needs to start metacalling, using whatever one wishes to use behind, that existed before. Any other pre-existing function for example, all clustered together behind one wonder API, almost instantly.

Asynchronous metacall

Yes that is delivered too. For those use cases when order of the execution of single calls in the metacall stream, is not important

Beside being asynchronous this and previous metacall streamer behave exactly the same. This one will finish the overal metacall faster and will contribute to the faster program hosting it. But remember: call will be executed out of sync.

Comand + aguments = API

This mechanism is indeed not based on an hierarchy of implementations (aka processors). Inheritance is optional, not mandatory.

Example shown above:  user::processor, indeed inherits from the dbj::meta_call::default_processor, but it does not have to.  Due to the concept of the dbj::meta_call::call_streamer<PROC> , one can use any type that is INVOCABLE  to act as a processor as long as invoking  it, conforms to the following signature:

That user made processor will be then able to simply replace the default one and will receive every call “streamed in”. In case of using functors as processor, the added benefit is we can easily compose the workable drop-in-replacement solution based on overloading the above operator

Sometimes Difficulty is in the Flexibility

All streamer/processor combinations work and shape up a behaviour close or very far from the default one.  A lot of people have difficulty seeing the benefit of this.  For example user (also a good pupil reading this) might decide to use metacall as an API for the data base proxy front end. And nothing else.

In that case the user processor simply becomes:

And then this user can pre-package the metacall to act as a front end to the MYSQL proxy

Any calls streamed into this will have to start with MQSQL type or anything inherting from it:

metacall mechanism has no return values.

Perhaps you have noticed that ‘feature’ aleady. Interesting issue or attribute of this mechanism, is the user/developer has to think of the state more clearly.

There is no return values from metacall calls. You either provide accumulator for the return values, or you design some global singletons to keep your data (DOM is one real life example of that concept). Very interesting.

outcome and result_set here, can also be globals. It depends on the users application design.

API as the obvious use-case

Now, back to our shiny solution based on default call stream mechanism and generic processor ( aka bridge ), possibly specialized by “customers” for their specific purposes.

What would be the most likely use case?

This time I will pay attention to the customers who are implementing some library in the (right) spirit of c++ std : a lot of generic functions and the whole solution in header files. Also, they want to have an “metacall enabled API” interfacing to their library.

Most likely this customer wants to hide her complex “things” behind a dbj::meta_call, and thus make the whole solution API, nice and easy and eminently usable. Accidentally the same customer is keen on “cmd & arguments paradigm”, perhaps wishing to deliver her existing lib into an API good for  command line interface (CLI) apps implementation,

How would that customer quickly implement the  call stream concept and  a small layer of code necessary  to make API?

Let’s keep this sample, simple but still valid c++. Let us call the customers lib “ops”, short for “operators”.

This is the whole library. And here is the code required so that meta-call-stream-ed API for users can be delivered.

Yes,  that is right.  Just use the default metacall with the “ops” lib availabe and you will have instant call-stream-ed API.

Also, just to confirm once more, the metacall malleability, if one passes some other non ‘ops’ operations here, or anything else, this code will still work.

Of course the metacall instance above is valid for passing to it any calls. It is the same as ever before. It will find any specialized call operator presented here, to pass the calls to their intended implementations.


All this C++ “snazzy” idioms, are not here because of my “requirements” or dictate. I am showing all these to confirm the eligibility of the whole metacall concept for the C++ programming too.

This is one very flexible but simple mechanism. Your imagination is required.