Is using boost::bind to pass more arguments than expected safe?

Using boost-bind, the resulting boost-function may receive more arguments than the bound object expects. Conceptually:

int func() { return 42; }
boost::function<int (int,int,int)> boundFunc = boost::bind(&func);
int answer = boundFunc(1,2,3);

In this case, func() receives 1,2, and 3 on the stack even though its signature indicates that it takes no arguments.

This differs from the more typical use of boost::bind for partial application, where values are fixed for certain objects yielding a boost::function that takes fewer arguments but supplies the correct number of arguments when invoking the bound object.

The following code works with both MSVC++2010 SP1. This is a reduced form to post; the original code also works under g++4.4 on Linux.

Is the following well-defined according to the C++ Standard?

#include <iostream>
#include <boost/bind.hpp>
#include <boost/function.hpp>

using namespace std;

void func1(int x) { std::cout << "func1(" << x << ")\n"; } // end func1()

void func0() { std::cout << "func0()\n"; } // end func0()

int main(int argc,char* argv[]) 
{
        typedef boost::function<void (int)> OneArgFunc;
        OneArgFunc oneArg = boost::bind(&func1,_1);
        // here we bind a function that accepts no arguments
        OneArgFunc zeroArg = boost::bind(&func0);
        oneArg(42);
        // here we invoke a function that takes no arguments 
        // with an argument. 
        zeroArg(42);

   return 0;
} // end main()

I understand why zeroArg(42) works: the unused argument is put on the stack by the calling routine and simply not accessed by the called routine. When the called routine returns, the calling routine cleans up the stack. Since it put the arguments on the stack, it knows how to remove them.

Will moving to another architecture or c++ compiler break this? Will more aggressive optimization break this?

---

I'm looking for a stronger statement, either from the Boost documentation or from the Standards document. I haven't been able to find an unambiguous position in either.

Using a debugger and looking at the assembly and stack, it is clear that func from the first example does not receive values 1,2, and 3: you are correct on that front. The same is true for func0 in the second example. This is true at least for the implementations that I am looking at, MSVC++2010SP1 and g++4.4/Linux.

Looking at the referenced Boost documentation, it's not as clear as I would like that it is safe to pass extra arguments:

bind(f, _2, _1)(x, y);                 // f(y, x)

bind(g, _1, 9, _1)(x);                 // g(x, 9, x)

bind(g, _3, _3, _3)(x, y, z);          // g(z, z, z)

bind(g, _1, _1, _1)(x, y, z);          // g(x, x, x)

Note that, in the last example, the function object produced by bind(g, _1, _1, _1) does not contain references to any arguments beyond the first, but it can still be used with more than one argument. Any extra arguments are silently ignored, just like the first and the second argument are ignored in the third example. [Emphasis mine.]

The statement about extra arguments being ignored is not as unambiguous as I would like to convince me that this is true in the general case. Looking at TR1, it is clear from Sec 3.6.3 that a callable object return from bind can be called with a different number of arguments than the target object expects. Is that the best guarantee available?

Yes, this is safe and portable – as mentioned explicitly in the documentation, the bind-expression returned by boost::bind silently ignores extra arguments.

I.e., in your first example, func does not receive the values 1, 2, and 3 – boundFunc receives the values 1, 2, and 3 and forwards them to the contained bind-expression, which safely receives and ignores them, and then invokes func(). Likewise, in your second example, zeroArg receives the value 42 and forwards it to the contained bind-expression, which receives and ignores the value and then calls func0().