A simple C++ delegate implementation but it 'cheats' the standard. Opinions?

Question

I posted the implementation and short test/demo here: http://ideone.com/CNJDi

I came up with an approach to C++ Delegates that is way different than other stuff I've been seeing. The problem specifically that I want to solve is to have a unified function pointer solution where a given instance may be either a) member fn ptr+object ptr or b) a nonmember fn ptr. Once you initialize the delegate and hand it off to other code, he can just call it, dynamically, without even knowing what type of object it came from (normally member function pointers can only be invoked by statically referencing the class it came from. Boo!). It's readily possible in theory, but C++ makes it extra hard to pull off anything like this. So I twisted the language to make it work.

The main drawback of my implementation is that it is not technically "standards compliant" due to invalid casts/invocations of member function pointers (at least, I'm 95% sure the standard is not protecting me here...). But it does happen to work on the compilers I tested it on (including Visual Studio 2012). I also think it's clear that it would 'tend to work' if member functions are implemented in a straightforward way by the compiler.

I looked at some other implementations but to me they just seemed so complicated and clumsy to use. Some even relied on build tools to generate stub functions to call the member functions, whereas mine only relies only on macros and templates. I think the lack of proper delegates is a major shortcoming of C++, but I find that I 'hate this workaround less'. Now I need to decide if I actually want to use it, or if I only like it because I thought of it.

Here is how you use it:

A. Declare Delegate type

typedef DELEGATE(float, ARGS(int, int)) Delegate1;

This macro automatically declares the static and member function pointer types so you don't have to type the signature twice. It expands to Delegate<float (*)(int, int), float (Null::*)(int, int)> . The compiler uses whichever of these is appropriate depending on how the delegate instance was initialized to perform invocations later. And the compiler uses it to statically validate arguments supplied by the coder's invocations. The ARGS macro is pure syntactic sugar to separate from the return type: DELEGATE(float, int, int) is the same.

B. Initialize:

Delegate1 d = Delegate1(test1); // static function
Delegate1 e = Delegate1((Delegate1::MemberType)&TestClass::test2, &obj); // member

these static and member functions are now stored as the same type! obj must be a valid pointer to a TestClass instance, and TestClass::test2 had better return a float and take (int, int) as arguments as described above. This is the main usage pitfall, the compiler can't catch mistakes made here.

C. Invoke: INVOKE(d, ARGS(5, 6)) (returns a float in this example) Despite it's appearance, this argument list is as actually as type safe as any C++ function call! It verifies the arguments using the aforementioned float (*)(int, int) signature supplied above! It can support any number of arguments, it just has to match the signature. You get the friendly compiler error if you add too many/too few arguments, use the wrong argument types, etc. from the compiler. Again, ARGS is syntactic sugar, INVOKE(d, 5, 6) is the same.

But if used INVOKE in a compiler that does not approve, it would probably crash the program :(

I have several questions:

1. Can anyone find any good compilers that my posted implementation sample does not work correctly on?
2. I hope this either works completely or the compiler/program flips out on the first usage. But is there a possibility of it seeming to work for a while and then randomly crashing?
3. Does this seem easy/clean to use in your opinion? Or do you find other implementations simpler? Which ones? Can you think of a good way to improve my syntax/useability of mine somehow?
4. Would you ever use it? Or should I just bite the bullet and use a safer but more complex alternative solution?

Answer 1

Why not just use std::bind available in C++11 / Boost? Member functions, function pointers, lambda functions, functors, and any other callable objects can be used with it. I personally prefer to avoid the preprocessor and macros at all costs; it can make debugging a giant mess. Scott Meyers (author of Effective C++, More Effective C++, and Effective STL) also discourages use of the preprocessor.

Reference for bind: http://en.cppreference.com/w/cpp/utility/functional/bind

I'd also consider using std::function to encapsulate the various types, but bind can handle pretty much everything cleanly. http://en.cppreference.com/w/cpp/utility/functional/function

Answer 2

Can anyone find any good compilers that my posted implementation sample does not work correctly on?

In my opinion, this is irrelevant if the code is not standards compliant in the first place. If you have to look at the rules of the language in a weird way, your code is probably not standards compliant.

Standards-compliant code is important because while the implementation details of the compiler may change, the observed behavior of the resulting binary cannot. Bugs that are an issue of standards compliance are more likely to get fixed than bugs that are an issue of non-standards-compliant code not working.

I hope this either works completely or the compiler/program flips out on the first usage. But is there a possibility of it seeming to work for a while and then randomly crashing?

If your code invokes undefined behavior, then have it work just fine then failing catastrophically at the worst time is a possibility allowed by the standard.

Does this seem easy/clean to use in your opinion? Or do you find other implementations simpler? Which ones? Can you think of a good way to improve my syntax/useability of mine somehow?

Quite honestly, I think it's a mess. To use your delegates I have to use three different macros, a separate typedef that's apparently not optional and a C-style cast. Frankly, it's painful to use and look at.

Would you ever use it? Or should I just bite the bullet and use a safer but more complex alternative solution?

Again, to be honest, I would just use std::function and friends (or boost::function if you don't have a C++11 compiler available). Even if you find std::function more complex, it's certainly more cleaner, it's standard, and is way more capable.