Question

This regrettably lengthy example is a cut-down version of a real piece of code I am attempting to write. It has two problems. First, as written, it doesn’t compile: the error is

error: cannot bind ‘std::string’ lvalue to ‘std::string&&’
error:   initializing argument 3 of ‘void pack_arg(datum*, size_t, std::string&&)’

and is triggered by the presence of the call to shut_the_door. If I take out the && in the relevant overload of pack_arg, then it compiles, but the generated code appears to copy both strings, unnecessarily. Second, I need to ensure that all string temporaries that the array d is holding pointers to, remain live until after the call to vprocess. Right now the generated code appears to destruct them right before that call.

I am willing to consider quite radical changes to how the array is filled, as long as I have the opportunity to run each argument to process through an overloadable function call, independent of all the other such arguments. (In particular, I suspect that the special rules for temporaries initializing a reference would make problem 2 go away if I could use std::string& in the union, but as each member of the datum array is filled in by assignment rather than initialization, that presently won’t work, and I don’t know how to make it be filled in by initialization without losing the calls to pack_arg, which are necessary in the larger context.)

EDIT: Using std::forward between pack_args and pack_arg does not appear to help; I get exactly the same error messages.

#include <string>
#include <stddef.h>
using std::string;

union datum
{
  const string* s;
  int i;
};

inline void
pack_arg(datum* d, size_t n, int t)
{
  d[n].i = t;
}

inline void
pack_arg(datum* d, size_t n, string && t)
{
  d[n].s = &t;
}

inline void
pack_args(datum*, size_t)
{
}

template <typename X, typename... XS> inline void
pack_args(datum* d, ::size_t n, X&& x, XS&&... xs)
{
  pack_arg(d, n, x);
  pack_args(d, n+1, xs...);
}

extern void vprocess(datum*, size_t);

template <typename... XS> inline void
process(XS&&... xs)
{
  size_t n = sizeof...(xs);
  datum d[n];
  pack_args(d, 0, xs...);
  vprocess(d, n);
}

extern string shut_the_door();

void
demo()
{
  process(1, 2, "buckle my shoe", 3, 4, shut_the_door());
}

Answer 1

Luc brings a really interesting point (I briefly skimmed the code reading only the signatures):

If you are going to store pointers to the std::string in a container then your code must make sure that the arguments are not rvalues, as that will leave a dangling pointer after the function call completes.

The more I think on your code, the more I believe that the whole thing is just a bad idea. Without a tag on what each element is, you cannot know after the fact which element of the array is of what type. The lifetime of the objects will be hard to maintain (for the std::strings in particular…) Maybe you should rethink the design altogether.

---

You have hit an interesting quirk of the new C++11 syntax. The double ampersand (&&) in these two declarations don’t really mean the same:

inline void
pack_arg(datum* d, size_t n, string && t);         // [1]
template <typename X, typename... XS> inline void
pack_args(datum* d, ::size_t n, X&& x, XS&&... xs) // [2]

In [1] the argument of type string&& will only bind to an rvalue allowing to discriminate a temporary (or std::moved object) from an lvalue. The rvalue-reference behaves like an lvalue inside the function. In [2], because you are in a template and X is an inferred type a different set of rules apply and X&& will be resolved to either an lvalue reference or rvalue reference, depending on the argument.

In your case, the argument is actually a temporary, so X&& will be mapped to std::string&&, but inside the function it is treated as an lvalue an cannot be bound. You can fix this by adding std::forward:

template <typename X, typename... XS> inline void
pack_args(datum* d, ::size_t n, X&& x, XS&&... xs)
{
  pack_arg(d, n, std::forward(x));
  pack_args(d, n+1, std::forward(xs)...);
}

The std::forward template will generate either an lvalue or rvalue reference depending on whether the argument is an lvalue or rvalue-reference itself.