Intro
Contents
metacall series
- Part One: metacall foundations, JavaScript format
- Part Two: metacall C# Binding
metacall()()()™
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 one strongly typed language. In english: types are everything.
Also, C++ is compiled language, vs dynamic (interpreted) JavaScript. metaclass is already implmented 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.
Still 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. 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” AP indeed. And by default very forgiving. metacall can be logical instance of any kind-of-a metacall type. It just has to confirm to certain interface, we shall see very soon. What matters here is this paradigm of “endless” stream of calls.
First argument of each call, by default defines the behaviour. If it is callable it will be simply called with the argument’s given. The “normal” equivalent of the above is:
first_1(a,b,c) ;
first_2(1,2,true);
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 is giving much more control of the behaviour of the whole interface mechanism.
Three calls above are just any three functions, but as part of metacall sequence suddenly they 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.
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 | int main() { namespace cs = dbj::meta_call; cs::default_cs cst ; // following call // is dispatched to an processor for handling string literals cst("add", 1, 2) // pre-existing function is immediately callable from a "metacall" (user::add,4,5,6) // if found this is dispatched to specialized processor for handling char ('X', 1, 2, 3) // if found this is dispatched to specialized processor for handling int list (7, 6, 8, 9) // if found this is dispatched to specialized processor for handling bool (true, 11) // and we can guess by now where this will go (&std::cout, "this", "goes", "to", "generic", "processor"); // make a command to deal with single int's user::generic_command<int> my_cmd("LABEL"); // just proceed woth the same cassl stream instance cst(my_cmd, 9)(my_cmd, 6); } |
Above is the the real code that compiles and runs. (GitHub repository here). For each call in the stream, frist argument is significant.
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 . Let’s jump straight to the call stream code.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | /* front end of the c++ "metacall" mechanism delivers the "calling experience" to the clients */ template<typename PROC> struct call_streamer final { PROC proc_{}; template < typename CMD_, typename... Args> const call_streamer& operator()(CMD_ cmd_, Args... args_) const { proc_(cmd_, args_...); return *this; } }; |
Perhaps surprisingly simple. So, in this solution there is one dbj::meta_call::call_streamer<PROC> class template, serving the needs of all.
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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | /* Default metacall processor each call can be a 'command' + variable number of arguments but does not have to be */ struct default_processor { /* user defined processors must be functors implementing this method */ template <typename T, typename... Args> void operator () (T const& cmd_, Args... args_) const { /* implementatin here */ } } ; |
