Wrappers revisited. Yuriy Solodkyy August 8, 2005

Transcription

1 Wrappers revisited Yuriy Solodkyy August 8, 2005 Abstract This essay tries to revisit idea of wrappers as presented in papers by Michael Tiemann [1] and Bjarne Stroustrup [2] with taking into account some cases that were of practical interest in problem domains I had a chance to work with. It tries to analyze pros and cons of explicit dispatching approach used by several libraries to solve the wrapping problem and then estimate what would it cost for the language to support it implicitly. I have chosen this topic to be my essay for the course, because I was really impressed by the power of explicit dispatching technique when I first saw it. I m also very interested in generic programming in C++ where I believe this approach opens new horizons for experimenting. 1 Introduction Often times we need to be able to slightly modify behavior of an existing class by adding or intercepting some functionality, while leaving the rest of the class semantics intact. Typical needs of classes that modify behavior of others can be briefly summarized as following: a) notification upon initiation and completion of a call b) access to actual parameters of a call c) access to result of a call d) access to pointer to free/member function being called e) ability to catch exceptions thrown inside called function f) ability to specialize wrappers g) ability to change type of result h) possibility to discard actual call i) vtbl level compatibility of wrapper s and original interface Here are some examples and their requirements accordingly to this list: 1. Calls dispatching in distributed systems. Requires b, c, d, e, f, i (the last for source interfaces used as callbacks). 2. Synchronization of access to shared objects in multithreaded environments Requires a (in simple cases), d (in more complicated synchronization models) and f (e.g. to let const methods lock for reading and non-const for writing) 3. Support of Aspect Oriented Programming 4. Transcoding error handling models (status codes, OS level exceptions, C++ exceptions, last error descriptors etc.) Requires c, g, e 1

2 5. Code instrumentation (timing, debug tracing, error handling etc.) Requires d, b, c and e (may be useful to intercept from where exception was thrown) 6. Memoization Requires d, b, c, h 7. Proxy objects that try to behave as a reference to another object Requires d, b, c, g 2 Related works A very good overview and historical backgrounds of the problem are given in [2]. To conserve space we ll just list main features and shortcomings of approaches mentioned there. Call and Return facilities of C with Classes [3] allowed defining a pair of functions that would implicitly be called before every call of every member function (except constructors) and before every return from every member function (except destructor). Construct was removed from the language as almost no one was using it, though it would have easily solved us cases 2 and partially 5 if it was a day. The notion wasn t perfectly general for example, you couldn t access arguments for a member function call from call(), which are required to handle cases 1,4,5 and 6. C++ language extension called Wrappers proposed by Michael Tiemann [1] was intended to allow the programmer to specify an alternate implementation of member function calls and was based on notion that in order to execute a member function call, it is necessary only to know the object for the call, member function for that object and arguments. This proposal had the interesting property that the wrapper had access to the arguments and the return value of a call. Also, different wrapper functions could be provided for functions with different types. Approach was not adopted though as there were other serious problems: Approach was intrusive as it required controlled classes to be derived from a specific base class. General case of wrapping any method was handled via untyped argument list (...) which was type unsafe and required compiler tricks to be implemented. Run-time overhead for possibility of ignoring wrapping of certain methods. Author argues though that this could have been optimized out by a good compiler via inlining and constant folding. Compiler had to treat differently this-pointer inside a wrapper because implicit conversion of a pointer-toan-object to a pointer-to-a-base-class of that object is anti-symmetric with respect to pointers to member functions and hence it was not type safe to pass a pointer-to-a-derived-member-function to a wrapper in a base class. To overcome this deficiency compiler had to check whenever possible whether this-pointer actually points to an object of derived class and whenever not, it had to provide appropriate run-time check. If implemented, this extension would have probably been able to solve most of our cases, though cost of supporting such a feature in C++ compiler would have been significant. In 2000 Bjarne Stroustrup presented partial solution to a wrapping problem [2]. This solution was non intrusive and didn t require any language changes hence could be implemented in Standard C++. Some language features, used in implementation, were not available at the time Michael Tiemann presented his ideas though. Used technique has the nice property that the suffix code is executed even if method throws an exception. Idea was capable of solving case 2 and certain subcases of 3 and 5. What prevents it from solving other cases can be best quoted from Dr. Stroustrup s paper: A fundamental limitation of this prefix/suffix approach is that neither prefix nor suffix has access to the arguments to the called function or the result produced. For example, it is not possible to provide a prefix/suffix to record the results of calls or to map calls into message send operations. In this, the prefix/suffix approach differs from the Tiemann wrappers [1]. Another limitation of this approach is that the prefix and suffix are independent. For example, it is not possible to write a prefix/suffix pair that catch exceptions thrown by the wrapped functions. It is not possible to open a try-block in the prefix and close it in the suffix. 2

3 However, it is possible for a prefix and a suffix to communicate. A simple use of that is for a prefix and a suffix to access the same variable as is typically done for locks and trace state. To do the call, Wrap and Call proxy get a pointer to the object called. Thus, they might keep a record of objects accessed, but they do not know which function is called for those objects. [2] Also unlike Tiemann s proposal this technique didn t allow specializing wrappers for methods with different signatures, only for different classes. This may be important for example in RPC domain where you may want to specialize wrapping of methods that return void to not block before the result is returned. Another, though smaller inconvenience of this approach lays in fact that its usage assumes some sort of pointer semantics, which is not always desirable or possible. As an example you may think of wrapper atomic<t> which synchronizes access to members of T on one-method-at-a-time bases. We want atomic<t> to behave exactly as T does (to the extent implementable in current C++) but have synchronization semantics mentioned above. 3 Dispatchers In a search for greater flexibility some libraries adopted approach of explicit function call wrapping [4, 5]. In these libraries family of parameterized free functions or parameterized member functions of a dedicated wrapper class explicitly accept what to call and on which arguments. Term dispatchers is probably not the most appropriate here, - we picked it by analogy from COM/DCOM [6] where it is used for similar purposes, though without direct relation to C++ templates. We didn t use term forwarding function as defined in [7] to highlight the fact that apart from forwarding parameters, dispatchers also forward pointer to free/member function. The following example demonstrates idea of dispatchers by implemententing redirection of calls to an actual object represented by reference, access pattern though can be more sophisticated. To conserve space we ll also omit explicit calls to prefix, suffix as well as wrap calls into try-catch blocks, however they are assumed in most of the places. template <class T> class dispatcher public: dispatcher(t& obj) : m_obj(obj) } template <class R> R dispatch(r (T::*method)() const) return (m_obj.*method)(); } template <class R> R dispatch(r (T::*method)() ) return (m_obj.*method)(); } template <class R, class A1> R dispatch(r (T::*method)(A1) const, A1 a1) return (m_obj.*method)(a1); } template <class R, class A1> R dispatch(r (T::*method)(A1), A1 a1) return (m_obj.*method)(a1); } template <class R, class A1, class A2> R dispatch(r (T::*method)(A1, A2) const, A1 a1, A2 a2) return (m_obj.*method)(a1, a2); } template <class R, class A1, class A2> R dispatch(r (T::*method)(A1, A2), A1 a1, A2 a2) return (m_obj.*method)(a1, a2); } // --- etc. private: T& m_obj; // Underlain object to redirect calls to 3

4 Amount of arguments that can be handled by the wrapper is typically limited by a predefined constant, big enough to suit practical needs. Calls in this scenario are made as following: class MyClass //... int f() const; int g(const string& s); double h(float f, long n); string m(const char* s) const; template <class U> U z(u u); MyClass my; dispatcher<myclass> dsp(my); int i = dsp.dispatch(&myclass::f); int j = dsp.dispatch(&myclass::g, "aaa"); int k = dsp.dispatch(&myclass::z<int>, 7); std::cout << dsp.dispatch(&myclass::h, , 42) << std::endl; We could have overloaded operator->* of dispatcher to return a functor and as a result let the calling syntax look like: int i = (dsp->*&myclass::f)(); int j = (dsp->*&myclass::g)("aaa"); int k = (dsp->*&myclass::z<int>)(7); however we didn t do that on purpose to avoid tying dispatcher to pointer semantics only. While this is perfect for some of our use cases, this is not suitable for all of them. This will become clearer in the next section while example of this approach with overloading operator->* can be found in my second essay for this course. Another possibility was to use operator() instead of method dispatch, however such usage intuitively does not assume passing pointer to member function to call as a first argument. At the same time giving an explicit name to such method allows us to use it in global scope for dispatching of free functions and functors: template <class R> R dispatch(r (*func)()) return func(); } template <class R, class A1> R dispatch(r (*func)(a1), A1 a1) return func(a1); } template <class F> typename result_of<f()>::type dispatch(f f) return f(); } template <class F, class A1> typename result_of<f(a1)>::type dispatch(f f, A1 a1) return f(a1); } Where result_of<> is oncoming standard library s solution to the problem of obtaining result type of applying function object to a given set of argument types. [8]. Calls will be dispatched similarly: int my_func(double d); int n = dispatch(&my_func, 0.0); 4

5 Interesting property of dispatching approach is that it also allows wrapping access to data members. This has some limitations though, but works well in majority of typical cases. template <class T> class dispatcher //... previous definitions skipped... template <class V> struct read_write_proxy read_write_proxy(t& t, V T::*attribute) : m_obj(t), m_attr(attribute) } V operator=(const V& val) return m_obj.*m_attr = val; } operator V() const return m_obj.*m_attr; } private: T& m_obj; V T::*m_attr; template <class V> read_write_proxy<v> dispatch(v T::*attribute) return read_write_proxy<v>(m_obj, attribute); } Note, we return here a proxy object rather then direct reference to a member because in the most interesting cases of this approach s applications, member is not available directly and either needs to be brought in for reading or updated with new value written. Exactly this situation occurs in RPC domain, where we may refer to a member of an object located remotely. Because proxy is also a kind of wrapper, that tries to behave as a reference to a data member, it naturally has limitations of class wrapping we are trying to analyze in this essay. For example in the following snippet: class MyClass //... previous definitions skipped... public: int m_n; const double m_d; std::string m_s; dsp.dispatch(&myclass::m_n) = 5; std::cout << dsp.dispatch(&myclass::m_n) << std::endl; std::cout << dsp.dispatch(&myclass::m_d) << std::endl; dsp.dispatch(&myclass::m_s) = "Howdy"; all dispatchings work just fine, however already: std::cout << dsp.dispatch(&myclass::m_s) << std::endl; fails to compile because in C++ overload resolution happens after template argument deduction, and this deduction does not consider conversion from read_write_proxy<std::string> to std::string. Template argument deduction is required here because operator<< is defined for generic templates std::basic_ostream<> and std::basic_string<>. Should standard library have defined specialization of operator<< for types std::ostream and std::string, which are just instantiations of these templates, overload resolution would have picked it up using our conversion from read_write_proxy<std::string> to std::string. Without this we have to either use explicit cast: std::cout << static_cast<std::string>(dsp.dispatch(&myclass::m_s)) << std::endl; 5

6 or add to read_write_proxy operator<< defined on basic_ostream<> that simply redirects call to parameter s operator<<. template<class _Char, class _Traits> friend std::basic_ostream<_char, _Traits>& operator<<( std::basic_ostream<_char, _Traits>& os, const read_write_proxy& p) return os << static_cast<v>(p); } This, however, neither covers general case (we only consider operator<< for std::basic_ostream<>) nor can be done for all the operators that can be overloaded in C++ as this would require deduction of type from a result of operation. Hopefully next revision of C++ is going to cover this issue with decltype operator [9]. To the extent I understand the proposal, what even decltype won t be able to fix is possibility to say dsp.dispatch(\&myclass::m_s).empty() without explicit casting a la static_cast<std::string>(dsp.dispatch(&myclass::m_s)).empty() (assuming that dispatch returns proxy object rather then reference). 3.1 Pluses and minuses Despite syntactical changes that need to be done to all function calls, dispatching approach has most of the nice properties referred in Tiemann s and Stroustrup s work: a) Access to arguments of call and return value b) Possibility to specialize dispatcher for methods/free functions with given signature c) Complete control over call possibility to discard actual call or execute it several times possibility to change the value and/or type of returned result possibility to catch exceptions in actual call d) Non intrusiveness can wrap objects not written by us allows to make a direct call instead of a wrapped one e) Compile time wrapping logic preselection. This is different from the wrapper predicate proposed by Tiemann though, as because of distinct call syntax we do not really abolish wrapping but rather choose between simple wrapping (redirect call without doing anything else) and purposeful wrapping (does other things apart from call redirection). This can be achieved for example via boost::enable if template [10] f) Possibility to dispatch methods of different classes g) Possibility to wrap access to data members h) Possibility to deduct return type and types of arguments from a single argument - pointer to free/member function. Approach has negative sides too: a) Difference in calling syntax makes approach less generic as code written without it in mind won t be able to benefit from wrappers possibilities. INVOKE proposed in [11] can possibly help with this issue. 6

7 b) When wrapped class uses function overloading, calling becomes even more tedious: class MyClass //... double h(float f, long n); int h(short f, bool b); dsp.dispatch(static_cast<int (MyClass::*)(short,bool) const>(&myclass::h), 8, true); int (MyClass::*pmf)(short,bool) const = &MyClass::h; // second option dsp.dispatch(pmf, 8, true); as otherwise taking address of the method is ambiguous. c) Call dispatching is tightly linked to call forwarding as described in [7] and naturally has all its problems. I will abstract from those issues here as oncoming revision of C++ standard will likely provide means to handle those. [12, 13] 4 Anonymous members If it was not for the syntax, dispatchers would have been a very good solution to the problems we mentioned. In what follows we try to merge Tiemann s idea with ideas seen in dispatchers. This is not a language extension proposal as it has too many unclarities and lacks formalism required by [14]. Instead I regard it as an exercise in evaluating language feature, hoping that this experience may become useful later in the course. As can be noticed, when using dispatchers we ve got to duplicate some of the information twice. In the example above we refer to MyClass first in type within variable definition dispatcher<myclass>dsp(my); and then in every call we make as a part of the pointer-to-member reference dsp.dispatch(&myclass::g, "aaa");. It seems to be logical to leave the first reference, as we want to be able to explicitly specify which classes to wrap and which not, but as to the second one, it would have probably been nicer to have possibility in the language to bring it into the context. Borrowing syntax from Tiemann s work this should probably look as following: template <class T> class dispatcher public: dispatcher(t& obj) : m_obj(obj) } template <class R, class A1, class A2> R ()T (R (T::*method)(A1, A2), A1 a1, A2 a2) return (m_obj.*method)(a1, a2); } private: T& m_obj; Again, term anonymous member is probably not the right one here, but we need another name as it s Tiemann s alternative wrapper is used in several contexts: Class that wraps functionality of another class Method of a class that wraps certain set of methods of a wrapped class Name Unnamed or anonymous member reflects the fact that member s name serves purpose of a formal argument, and not a real member name within its class. Another possibility would have probably been to call it a meta member as it works on regular members of a class, however this is not truly compile-time work, as what they define will be executed at run-time. Leaving naming aside, the user of dispatcher class will be writing code as following: 7

8 MyClass my; dispatcher<myclass> dsp(my); int i = dsp.f(); // invokes dsp.()t(&t::f) int j = dsp.g("aaa"); // invokes dsp.()t(&t::g, "aaa") Informal reasoning behind this should probably sound as following: Class dispatcher doesn t have any method g(), but has some anonymous members, which can be invoked with one argument, thus for each of them compiler should bring for overload resolution all the methods g() of classes referred in the signature of matching anonymous members. Note, dispatchers presented in the previous paragraph were able to dispatch calls from multiple classes and therefore it seems unreasonable to abolish this possibility for anonymous members (unless we have a strong reasoning why). This may look as following: template <class T, class U> class dispatcher public: dispatcher(t& obj1, U& obj2) : m_obj1(obj1), m_obj2(obj2) } template <class R, class A1> R ()T (R (T::*method)(A1), A1 a1) return (m_obj1.*method)(a1); } template <class R, class A1> R ()U (R (U::*method)(A1), A1 a1) return (m_obj2.*method)(a1); } private: T& m_obj1; U& m_obj2; With this said while looking for an appropriate method to call, compiler should bring for overload resolution (into viable overload set) methods with given name from classes mentioned in all the anonymous members that can possibly satisfy this call. Overload resolution is then performed in accordance to existing C++ overloading rules (13.3 in [15]). 4.1 Various issues Already after a brief look at this feature several questions arise 1. Should regular methods of a wrapper class get priority over methods brought in via anonymous members or should they all be equal in overload resolution? 2. How to wrap overloaded methods with the same amount of arguments but different signatures? Should compiler in this case tries to deduct argument types from the call? 3. What about default arguments? Should anonymous member s default arguments be used or actual method s? 4. Can wrappers be used transparently in polymorphic calls? 5. Can call to a free function be wrapped the same way? 6. How to define behavior in case of dispatching calls from many classes when types are related (say T=U in the example above) 7. Which wrapper should handle the call when method s signature matches two wrappers? 8. How about template members of a wrapped class? 8

9 9. Hidden problems with sizeof(t) in generic code, since sizeof wrapper needn t be the same as sizeof wrapped. 1. It seems to be logical to have regular methods of a wrapper be brought to a viable set for overload resolution together with matching methods of the wrapped class. In case of ambiguities though regular methods of a wrapper should probably be chosen as a better match to let user override wrapping behavior of some methods. 2. Overloaded methods with the same amount of arguments were posing problem in case of explicit dispatching as getting pointer to a member was ambiguous. Here situation is a little bit different from explicit dispatching though. In explicit dispatching arguments of the call were separated from the method to call and even though we were using them as such, compiler knew nothing about our intent. In case of anonymous members compiler knows that arguments are for the call with pointer-to-member it s going to deduce and hence it can use those arguments to deduct types of pointer-to-member s arguments. 3. It seems to be reasonable to allow default parameters for arguments of anonymous members since one may probably want to create a wrapper with the sole purpose of providing defaults for arguments without it in some original methods. Nevertheless, because in C++ a template type parameter cannot be deduced from the type of a function default argument ( (17) in [15]) we can t use meta method s default arguments to deduce argument s type. At the same time default arguments of actual member function may affect resolution of anonymous member and then should be used as arguments to its call. 4. Why would someone need vtbl level compatibility of wrapper and wrapped object? When making a remote call, as one of the parameters caller may supply pointer to its interface for callbacks. In such scenario we want to be able to generate a wrapper (called stub in COM/DCOM [6]) that has exactly the same vtbl layout as caller object but generic implementations of virtual methods that marshal calls back to the caller s processor. We need to understand here, that virtual methods of the wrapped class and anonymous methods of a wrapper (even if they are virtual) have different signatures because of pointer to member passed in and hence are not compatible for polymorphic calls. What can be done in this case is the following: struct MyInterface virtual int A(int) = 0; virtual void B(double) = 0; struct MyClass : public MyInterface int A(int); void B(double); template <class T> class wrapper : public MyInterface int A(int a) return T::() A(a); } // Redirect to wrapper. This will wrap T::A() void B(double b) return T::() B(b); } // Syntax from Tiemann s work template <class R, class A1> R ()T (R (T::*method)(A1), A1 a1) return (m_obj1.*method)(a1); } MyClass my; wrapper<myclass> dsp(my); void f(myinterface* pmyinterface); f(&dsp); Such manual redirection covers case with callbacks, however it assumes that callee won t be querying another interface via dynamic cast<>, as wrapper won t necessarily implement it too. In this scenario we don t really need 9

10 anonymous method as since we explicitly implement methods of the interface, we can do the necessary wrapping inside them. More general wrapping for this case requires more issues to be analyzed and will be skipped for now. 5. With anonymous members we in a way brought certain members of one class into the scope of another. Class name of the first class plays role of boundary of what to bring in. Doing the same with free functions will be too permissive and would have too much overhead in cases when we wanted to wrap a limited set of functions but wrapped many more because we didn t think they would also match the template. At the same time if we think of static member functions, which are treated similarly to free functions in C++, one may think of an anonymous member (say static anonymous member) that wraps static members of a class. Having made this step one naturally would want to extend the idea to namespaces, but we miss important differences here: Call to a static member will be wrapped not unconditionally, but when made through a wrapper (e.g. call MyClass::static member() won t be wrapped, while call wrapper<myclass>::static member() will be) Unlike classes in C++, namespaces can be reopened. This may create ambiguities when adding new wrappers to namespace as they may conflict with existing ones. On the other hand this may change wrapping logic in different translation units. 6. When types are related by hierarchy, we might get the following situation: template <class B, class D> struct dispatcher template <class R, class A1, class A2> R ()B (R (B::*method)(A1, A2), A1 a1, A2 a2) return (m_objb.*method)(a1, a2); } template <class R, class A1, class A2> R ()D (R (D::*method)(A1, A2), A1 a1, A2 a2) return (m_objd.*method)(a1, a2); } struct B int a(int, int); int b(int, int); struct D : public B int b(int, int); int c(int, int); B b; D d; wrapper<b,d> bd(b,d); bd.a(1,2); // B::() a(1,2); or D::() a(1,2); or ambiguous? bd.b(3,4); // B::() B::b(3,4); or D::() D::b(3,4); or ambiguous? bd.c(5,6); // D::() c(5,6) Answer seems to be obvious only for the last case: anonymous member for derived class should clearly be selected for methods of Derived not found in Base. There seems to be no clear preference in the second case, when b() is overloaded in derived. In the first case anonymous member for B seems to be a better match, though this has to be yet formalized. 10

11 Case when both classes of the wrapper are the same needn t be ambiguous by default: for example anonymous members of the first parameter may cover only members with even amount of arguments while anonymous members of the second parameter - with odd. In such scenario calling method on wrapper<t,t> won t be ambiguous as only one anonymous member can be used. In those cases when anonymous members from both parameters overlap in what they can cover, designer of a wrapper class template can always specialize her class to cover this case. 7. When method s signature matches two wrappers, call is ambiguous and can be disambiguated via explicit call to appropriate anonymous member. 8. When wrapped class has member templates, in dispatching approach we had to instantiate it explicitly before taking address of the method. As before, this was because compiler didn t know about any relationship between the first argument (member function pointer) and other arguments of dispatch method. Here situation is different and since compiler is trying to use anonymous method, it knows, that arguments are for call with the member function pointer it is going to deduce and hence it can use types of those arguments to deduce parameters of member template (of course only in those cases where these types can be deduced from parameters of call to member template). 9. Usage of sizeof in generic code can clearly cause problems when wrappers are used, however it doesn t seem to be unsafe as with idea of overloading sizeof() itself. 4.2 Tiemann s issues Apart from these questions let s look at applicability of the issues from Tiemann s paper to our situation [1]. 1. How does one keep a specific function call from being wrapped? 2. How does one keep a particular member function from being wrapped? 3. What happens when passing a derived member function to a base wrapper? 4. How does one handle type conversion in an argument list full of...? 5. Should constructors be wrapped? 6. Should wrappers be recursive? (can call to a wrapper be wrapped?) 7. Should function calls within wrappers be wrapped? (where is the bottom?) 8. How does one wrap a function call via a pointer-to-function (which may be missing type information)? 9. How should return values be handled? (overload based on return types?) 1. When logic of wrapper requires some of the calls to be made directly, such wrapper can expose a method to get reference to the original object, via which all methods can be called directly. A good option in some cases for such a method can be operator-> defined on wrapper. 2. Second question should be elaborated before it can be applied to our case. In Tiemann s work classes were derived from base classes that implemented wrappers and hence indirectly wrappers and wrapped methods were parts of a derived class. In our case wrapper and wrapped objects are not bound by inheritance and hence methods of a wrapper are called on wrapper, while methods of a wrapped class are called on wrapped object. To have a different implementation of a particular method or to wrap it up differently, wrapper always can implement method with the same signature, which should probably be given priority in overload resolution since it doesn t involve call to an anonymous member. As usual declaring method private on wrapper will make it inaccessible. 3. Again, since wrapper and wrapped class are not necessarily bound by inheritance relation, question is not directly applicable. When they are (D : wrapper<b> : B), passing a derived member function to a base wrapper violates anti-symmetry of implicit conversion between pointers to member functions and hence is not type safe. Another case when D is derived from B and wrapper<b> is initialized with reference to D won t allow wrapping of D s members for the same reason. Employing Curiously Recurring Template Pattern (D : wrapper<d>) will be type safe as wrapper will see D s definition [16]. 11

12 4. Unfortunately I don t have enough knowledge on details of ellipses handling in C++ so I ll skip this one. 5. Wrapping constructors/destructor makes sense in our case as construction/destruction of wrapper needn t be directly linked to construction destruction of a wrapped object It certainly makes sense in remote procedure calling where object may be created on one processor by the caller on another. In this case we want to be able to marshal parameters of creation from caller s process to the process where object will reside. This is perfectly possible with dispatchers so there seems to be no reason of disallowing it on wrappers. 6. There seems to be no obvious reason why calls to wrappers shouldn t be wrapped by other wrappers. For any instantiation of a wrapper with a given type(s) we know exactly set of methods and their signatures, available on wrapper. This can be computed as a filtering of parameter type s methods that match any of the meta methods. Another interesting question though is whether it should be possible to write a meta method of higher order that wraps calls to regular meta methods. Are of application of those should probably be related to area of template template parameters application, however I can t directly find such for higher order meta methods. 7. Question about whether function calls within wrapper should be wrapped is not as important to our case as it was for Tiemann s case: because of inheritance, there wrapper s methods and wrapped methods were becoming part of the same class, while here they are members of distinct classes (actually even more: members of a class and a class template). 8. When call is made through pointer-to-member, compiler s task becomes simpler: it needn t do any overload resolution, just find a wrapper that matches type of the pointer-to-member and call it with provided pointer. 9. Dispatchers presented before had a full control over return type and could change it if needed. For example they could have returned a type that is a wrapper around original return type. The same seems to be possible here as return type is deduced from pointer-to-member passed in. Hence this won t require overload based on return types. 5 Examples of usage In this section we ll try to briefly demonstrate intended use of anonymous members. 5.1 Synchronization template <class T, class SyncModel=default_sync_policy<T> > class atomic //... template <class R, class A1> R ()T (R (T::*method)(A1), A1 a1) auto_lock<syncmodel> Lock(m_obj); // will unlock in destructor return (m_obj.*method)(a1); } 5.2 Instrumentation template <class T> class logger //... template <class R, class A1, class A2> R ()T (R (T::*method)(A1, A2), A1 a1, A2 a2) std::clog << typeid(t).name() << " s method called with arguments " << a1 << " and " << a2 << std::endl; std::clock_t start = clock(); R r = (m_obj.*method)(a1, a2); std::clock_t finish = clock(); 12

13 } std::clog << typeid(t).name() << " s method called with arguments " << a1 << " and " << a2 << " returned " << r << " execution time " << double(finish - start)/clocks_per_sec << std::endl; return r; 5.3 Error handling template <class T> class status_to_exception //... template <class A1, class A2> HRESULT ()T (HRESULT (T::*method)(A1, A2), A1 a1, A2 a2) HRESULT hr = (m_obj.*method)(a1, a2); if (FAILED(hr)) throw com_exception(hr); return hr; } Another usage example, implemented by means of standard C++ via explicit dispatching, can be found in my second essay. 5.4 Conclusions Generalizing wrappers based on ideas seen in explicit dispatchers seems to be an attractive idea for generic programming purposes, however it poses too many questions yet to be answered before it can be considered. In this respect it may also be interesting to compare issues of this approach with those that appear with overloading of operator. and see whether both can t be resolved in yet more generic way. These and similar issues related to generics in C++ is what drives my interest in C++ Language Design Studio course, where I hope to learn more on how to tackle them. References [1] Michael Tiemann. wrappers: solving the rpc problem in gnu c++. In USENIX C++ Conference, pages , Denver, CO, October [2] Bjarne Stroustrup. Wrapping c++ member function calls. C++ Report, 12(6), June [3] B. Stroustrup. The Design and Evolution of C++. Addison Wesley, March ISBN [4] Douglas Gregor. The Boost Function library. June [5] Lawrence Rauchwerger Steven Saunders. Armi: An adaptive, platform independent communication library. In ACM SIGPLAN Symp. Prin. Prac. Par. Prog. (PPOPP), page 12, San Diego, CA, June [6] Richard T. Grimes. Professional ATL COM Programming. Wrox Press, September ISBN [7] Peter Dimov, Howard Hinnant, and Dave Abrahams. The forwarding problem: Arguments. In ANSI/ISO C++ Standard Committee Pre-Santa Cruz mailing, number N1385= in ANSI/ISO C++ Standard Committee Pre- Santa Cruz mailing, October [8] Douglas Gregor. A uniform method for computing function object return types. In ANSI/ISO C++ Standard Committee Post-Oxford mailing, number N1454= in ANSI/ISO C++ Standard Committee Post-Oxford mailing, April [9] Jaakko Järvi and Bjarne Stroustrup. Decltype and auto (revision 3). In ANSI/ISO C++ Standard Committee Pre-Sydney mailing, number N1607= in ANSI/ISO C++ Standard Committee Pre-Sydney mailing,

14 [10] J. Järvi, J. Willcock, H. Hinnant, and A. Lumsdaine. Function overloading based on arbitrary properties of types. C/C++ Users Journal, 21(6):25 32, June [11] Peter Dimov Pete Becker. Unifying tr1 function object type specifications. In ANSI/ISO C++ Standard Committee Pre-Redmond mailing, number N1673= in ANSI/ISO C++ Standard Committee Pre-Redmond mailing, September [12] Howard E. Hinnant, Peter Dimov, and Dave Abrahams. A proposal to add move semantics support to the C++ language. In ANSI/ISO C++ Standard Committee Pre-Santa Cruz mailing, number N1377= in ANSI/ISO C++ Standard Committee Pre-Santa Cruz mailing, October [13] Peter Dimov Howard E. Hinnant, Dave Abrahams. A proposal to add an rvalue reference to the c++ language. In ANSI/ISO C++ Standard Committee Pre-Redmond mailing, number N1690= in ANSI/ISO C++ Standard Committee Pre-Redmond mailing, September [14] Members of the X3J16 working group on extensions. How to write a c++ language extension proposal for ansix3j16/iso-wg21. In ACM SIGPLAN Notices, volume 27, June [15] ISO/IEC International Standard. Programming languages C++. American National Standards Institute, September [16] James O. Coplien. Curiously recurring template patterns. C++ Rep., 7(2):24 27,