Re: fighting with move sematics and std::tuple
Am 27.05.2012 09:32, schrieb Frank Bergemann:
[..]
struct _ArgCommon
You should be aware, that according to [global.names]:
"Each name that [..] begins with an underscore followed by an
uppercase letter (2.12) is reserved to the implementation for any
use."
Do not introduce such names, unless you are a library implementation.
You may get unexpected errors that are hard to track down.
template<typename ...Types>
struct _ArgTuple
{
typedef typename std::tuple<const _Arg<Types>...> Type;
};
There is a lot of code, but above member type definition is at least
one source of the trouble, see below.
struct _FunctionTrackerShared {
static int _level;
};
Let me add that without a definition of FunctionTrackerShared::level
your code is ill-formed, no diagnostic required.
int
main(
int argc,
char ** argv)
{
int x = 5;
std::cerr<< "### main: create tuple"<< std::endl;
std::tuple<InArg<int> > forTest = std::make_tuple(MakeInArg("x", x));
std::cerr<< "### main: create FunctionTracker"<< std::endl;
auto funcTracker = FunctionTracker<
std::remove_reference<decltype(x)>::type
::make(
__FUNCTION__,
The C++11 standard does not specify an entity or macro __FUNCTION__. I
assume you meant __func__ instead.
Back to your problem again: To produce a simplified model of what is
going one we invent the following simple function template:
template <typename... Args>
typename ArgTuple<int>::Type my_make(Args... args)
{
return std::make_tuple(std::move(args)...);
}
and call it like this:
int main()
{
int x = 5;
my_make(MakeInArg("x", x));
}
This would already be ill-formed, when you have declared all your copy
constructors as deleted (as indicated by your preprocessor
defines). Or in other words: This already requires a copy constructor
for ArgTuple<int>::Type. The reason is very simply:
ArgTuple<int>::Type is - according to your definition - a typedef for
std::tuple<const _Arg<int>>. It is easy to understand that *any*
std::tuple<const X> cannot be a move-only type for some object type X,
simply because the move-constructor would be ill-formed when there is
a const data member. Compare this with the following
copy-initialization:
#include <utility>
struct MO {
MO() = default;
MO(MO&&) = default;
};
const MO mo;
MO mo2 = std::move(mo);
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]