-
-
Notifications
You must be signed in to change notification settings - Fork 258
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is it possible to allow variadic template expansion? #109
Comments
Thank you for reporting this. It would be great if we could support this. Can you provide a small example to reproduce the error? |
Yes, sure template <typename... ARGS>
void test(const ARGS&... args) {
dbg("Args: ", args...);
}
int main(void)
{
test(1);
test('1');
return 0;
}
The problem seems to occur because the macro expands earlier than the variadic template. |
Thank you. I can reproduce it as well. Unfortunately, I don't really know how to fix it. Any help would be very much appreciated. |
Seems the problem in that even the following code doesn't compile: #include <typeinfo>
template <typename... T>
void test(T&& ...args) {
/* std::cout << typeid(args...).name() << std::endl; */
typeid(args...).name();
// typeid(1).name();
};
int main(void)
{
test('v', 1);
return 0;
} I'm afraid it cannot be called that way. You can move the type extraction inside the |
Maybe @ShikChen could help out here? (only if you are interested) |
I don't have a good solution in mind now. Note that it's also really tricky to properly handle the return value: #include <dbg.h>
template <typename... T>
int sum(T&&... args) {
return (args + ...);
}
template <typename... T>
int calc(T&&... args) {
// Some other logic here in real world...
// This will return 3 instead of 6 :O
// return sum(dbg::identity(args...));
return sum(args...);
}
int main() {
dbg(calc(1, 2, 3));
return 0;
} A slightly simpler workaround could be wrapping it with |
I've recently found a hack which might allow this. Consider the following example: template <int N, typename... Ts>
using NthTypeOf = typename std::tuple_element<N, std::tuple<Ts...>>::type;
template <typename... ARGS>
void f(ARGS&&... args) {
dbg::DebugOutput(__FILE__, __LINE__, __func__)
.print({DBG_MAP(DBG_STRINGIFY, args...)},
{dbg::type_name<NthTypeOf<0, ARGS...>>() + ", " +
dbg::type_name<NthTypeOf<1, ARGS...>>()},
args...); // Here should be logic, which would evaluate args as a
// single variable
}
template <typename... ARGS>
void proxy(ARGS&&... args) {
dbg::DebugOutput(__FILE__, __LINE__, __func__)
.print({DBG_MAP(DBG_STRINGIFY, args...)},
{dbg::type_name<NthTypeOf<0, ARGS...>>() + ", " +
dbg::type_name<NthTypeOf<1, ARGS...>>()},
args...); // Here should be logic, which would evaluate args as a
// single variable
f(args...);
}
int main(void) {
proxy(1, 'v');
// test('1');
return 0;
} It outputs
Note that it compiles, and manages to correctly detect when parameter pack variables are lvalue reference. Though it seems to fail when they're rvalue references. |
Hm, also what's interesting that this seems to work! template <typename... ARGS>
void proxy(ARGS&&... args) {
/* dbg::DebugOutput(__FILE__, __LINE__, __func__)
.print({DBG_MAP(DBG_STRINGIFY, args...)},
{(... + (" " + dbg::type_name<decltype(args)>()))},
args...); */
std::cout << (... + (" " + dbg::type_name<decltype(args)>())) << std::endl;
}
int main(void) {
proxy(1, 'v');
// test('1');
return 0;
} I think this might fix the issue with finding the appropriate types for the parameter pack. Though it's still unclear how to threat parameter pack in a different way. #define DBG_TYPE_NAME(x) dbg::type_name<decltype(x)>() and for parameter pack: #define DBG_TYPE_NAME(x) (... + (" " + dbg::type_name<decltype(args)>())) I guess it might be solvable somehow using templates or recursion, but I can't find the solution right now |
I'd like to be able to write
dbg(args...);
So far it breaks when the macro is expanded. The workaround might be to create a tuple from a variadic template like this:
std::tuple<ARGS...> input{args...}; dbg(input);
But it adds some unwanted output regarding the
input
type (std::tuple<...
), and has other issues (see #102)The text was updated successfully, but these errors were encountered: