StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>Unfortunately, this cannot be done in C++ (yet - see the conclusions). Follows a proof.</p> <p><strong>CONSIDERATION 1: [on the need of templates]</strong></p> <p>In order to determine the correct member function <code>Ai::f</code> to be invoked at run-time when the expression <code>call_on_variant(v, f, ...)</code> is met (or any equivalent form of it), it is necessary, given the variant object <code>v</code>, to retrieve the type <code>Ai</code> of the value being held by <code>v</code>. Doing so <strong>necessarily requires the definition of at least one (class or function) template</strong>. </p> <p>The reason for this is that no matter <em>how</em> this is done, what is needed is to <strong>iterate over all the types</strong> the variant can hold (the type list is exposed as <code>boost::variant<...>::types</code>, check whether the variant is holding a value of that type (through <code>boost::get<></code>), and (if so) retrieve that value as the <em>pointer</em> through which the member function invocation must be performed (internally, this is also what <code>boost::apply_visitor<></code> does).</p> <p>For each single type in the list, this can be done this way:</p> <pre><code>using types = boost::variant<A1*, ..., An*>::types; mpl::at_c<types, I>::type* ppObj = (get<mpl::at_c<types, I>::type>(&var)); if (ppObj != NULL) { (*ppObj)->f(...); } </code></pre> <p>Where <code>I</code> is a <strong>compile-time</strong> constant. Unfortunately, C++ <strong>does not</strong> allow for a <a href="https://stackoverflow.com/questions/14261183/how-to-make-generic-computations-over-heterogeneous-argument-packs-of-a-variadic"><code>static for</code> idiom</a> that would allow a sequence of such snippets to be generated by the compiler based on <strong>a compile-time for loop</strong>. Instead, <strong>template meta-programming</strong> techniques must be used, such as: </p> <pre><code>mpl::for_each<types>(F()); </code></pre> <p>where <code>F</code> is a functor with a template call operator. Directly or indirectly, <strong>at least one class or function template needs to be defined</strong>, since the lack of <code>static for</code> forces the programmer to code the routine that must be repeated for each type <em>generically</em>.</p> <p><strong>CONSIDERATION 2: [on the need of locality]</strong></p> <p>One of the constraints for the desired solution (requirement 1 of the section "<em>CONSTRAINTS</em>" in the question's text) is that it shall not be necessary to add global declarations or any other declaration at any other scope than the one where the function call is being done. Therefore, no matter whether macro expansion or template meta-programming is involved, what needs to be done <strong>must be done in the place where the function call occurs</strong>.</p> <p>This is problematic, because "<em>CONSIDERATION 1</em>" above has proved that it is needed to define at least one template to carry out the task. The problem is that C++ <strong>does not allow templates to be defined at local scope</strong>. This is true of class templates and function templates, and there is no way to overcome this restriction. Per §14/2:</p> <p><em>"A template-declaration can appear only as a namespace scope or class scope declaration"</em></p> <p>Thus, the generic routines we <em>have to</em> define in order to do the job <strong>must be defined elsewhere than at call site</strong>, and must be <em>instantiated</em> at call-site with proper arguments.</p> <p><strong>CONSIDERATION 3: [on function names]</strong></p> <p>Since the <code>call_on_variant()</code> macro (or any equivalent construct) must be able to handle any possible function <code>f</code>, the <em>name</em> of <code>f</code> must be passed in as an argument to our template-based, type resolving machinery. It is important to stress that <strong>only the name</strong> of the function shall be passed, because the <em>particular function</em> <code>Ai::f</code> that needs to be invoked must be determined by the template machinery.</p> <p>However, <em>names</em> cannot be template arguments, because they do not belong to the type system. </p> <p><strong>CONCLUSION:</strong></p> <p>The combination of the three considerations above proves that this problem cannot be solved in C++ as of today. It requires either the possibility of using names as template arguments or the possibility of defining local templates. While the first thing is undesirable at least, the second one might make sense, but it is not being taken into consideration by the standardization committee. However, <em>one <strong>exception</strong> is likely to be admitted</em>.</p> <p><strong>FUTURE OPPORTUNITIES:</strong></p> <p><em>Generic lambdas</em>, which are being strongly pushed to get into the next C++ standard, are in fact <strong>local classes with a template call operator</strong>. </p> <p>Thus, even though the macro I posted at the end of the question's text will still not work, an alternative approach seems viable (with some tweaking required for handling return types):</p> <pre><code>// Helper template for type resolution template<typename F, typename V> struct extractor { extractor(F f, V& v) : _f(f), _v(v) { } template<typename T> void operator () (T pObj) { T* ppObj = get<T>(&_v)); if (ppObj != NULL) { _f(*ppObj); return; } } F _f; V& _v; }; // v is an object of type boost::variant<A1*, ..., An*>; // f is the name of the function to be invoked; // The remaining arguments are the call arguments. #define call_on_variant(v, f, ...) \ using types = decltype(v)::types; \ auto lam = [&] (auto pObj) \ { \ (*pObj)->f(__VA_ARGS__); \ }; \ extractor<decltype(lam), decltype(v)>(); \ mpl::for_each<types>(ex); </code></pre> <p><strong>FINAL REMARKS:</strong></p> <p>This is an interesting case of type-safe call that is (sadly) not supported by C++. <a href="http://aszt.inf.elte.hu/~gsd/s/cikkek/abel/Jarvi.pdf" rel="nofollow noreferrer">This paper</a> by Mat Marcus, Jaakko Jarvi, and Sean Parent seems to show that dynamic polymorphism on unrelated types is crucial to achieve an important (in my opinion, fundamental and unavoidable) <strong>paradigm shift</strong> in programming.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload