the "this" pointer

the "this" pointer

In msg #5 of "select() for references" thread, we've reiterated the "baked in" aspect of ArBB compilation and C++ pointers.

How does this work for the this pointer? How do we write class member functions e.g. to take advantage of compiling ArBB closures and saving these as class static and/or function static objects to be called later?

For example, say that for converting from between two ArBB-based user classes we might havea _assign(&RHS) function in a base classto define the work for operator= in a derived class... how do we capture/call the _assign() to best make use of ArBB?

What options do we have for when these compilations are built, e.g: 1)at the beginningof program execution, 2)anytime we choose, 3) when the class is first used, or 4) when the first _assign() is required?

Thank you,
- paul

7 帖子 / 0 全新

Hi Paul,

Let me restate your question(s) to capture the various aspects:

  1. Does Intel ArBB support capturing (calling) member functions?
  2. How to implement Intel ArBB-based function objects with state?

Let me now answer the above two questions.

  1. First, Intel ArBB doesn't support capturing non-static class member functions or methods. The reason for that is, that there are some difficulties to carry around the state for example within an Intel ArBB closure. Would it be the right way to carry around a shallow copy and to rely on the lifetime of the state? Would it be better to rely on a correct value semantic of the whole state? Would it be better to introduce an explicit interface to solve this problem, e.g. an interface to allow deep copying or cloning an object? Actually this is often application-specific and not exactly related to Intel ArBB. On the other hand stateless vs. stateful operation is somehow a point in the light of functional programming or when trying to avoid side-effects.
  2. There is a simple and powerful way (or if you like a pattern), which is able to implement a stateful function object. An overview is given below.

Overview of the interface to build a stateful function object:

class algorithm {
public: // c'tor

public: // method
void operator()(call-time-args) const;

private: // ArBB function(s)
static void fun(arbb-call-args);

private: // data
arbb::auto_closure m_program;
// addtional data


P.S.: here are some notes on the software technology of the above shown pattern:

  • It's useful to finish building m_program at construction-time of algorithm.
    Using the upcoming closure::compile method is then just a drop-in.
  • It's useful to carefully separate between:
    • construction-time arguments and
    • actual arguments (call-time arguments)
  • It's not necessary to keep an instance of the above type really stateless:
    • m_program doesn't need to be captured at construction time
    • Using the mutable keyword allows algorithm to be "logically stateless"
    • operator() might be "non-const"
  • It's possible to move the function(s) which are captured into the translation unit,
    i.e. fun in the above case.
  • It's possible to use "C++ state" to:
    • Build specializations of the algorithm (m_program)
    • Inspect call-time-args to select specialization within operator()
    • Manage a "dirty-flag" to build specializations on-the-fly
      (but see the note on the construction-time)
  • The pointer-to-implementation pattern allows:
    • Using Intel ArBB underneath of the above interface
  • Capturing a closure during algorithm's construction-time allows to achieve:
    • Predict to point in time where the JIT-compilation happens (at construction time)
    • Avoid having "C++ state" stored just for the matter of making it accessible to fun.
      Though, fun is either a "static" class function or a free function (somewhere else)

Hi Hans,

Thank you! This was exactly the information my wooly-minded questions were searching for.

In keeping with C++ "pay only for what you use" practicality, it occurs to me that JIT-compilation at construction time could be done with a "training" example. What I wonder is, is it necessary to exercise every path through the function (something like code coverage) with such an example for the JIT to "get it" completely?

Best regards,
- paul

By the way, at least with my MSVC configuration, I was unable to capture during construction but easily able to do so later if the closure was empty. For the former, the exewould go into "deep thought" and ultimately fail. The latter has the advantage of setting up to compile only functions actually used.
- paul

Thank you Paul, I added your suggestion to our backlog.

> [...] is it necessary to exercise every path through the function [...] for the JIT to "get it" completely?
I am feeling, that answering this question will clarify further how the runtime compilation actually works. Unfortunately, I can only guess what your concern is. Can you explain further what you mean?


Hi Hans,

Rethinking my post, I had forgotten that ArBB develops an abstract representation of my code andJITs that, so actually executing it (and all paths) is not part of that process. Silly me. Iwithdraw that question.

- paul


that's fine! You just got around of all these words... nice.

Your questions are always very welcome!