RDataFrame Define with variadic function

Dear experts,

When trying to call Define on a RDataFrame using a variadic function, i’m getting a runtime_error from here. I think the exception is raised because of this assignment.

It is very likely that something is wrong in my implementation, given that i’m using variadic functions and some c++17 features for the first time. So i’m giving some details on what i want to do:
The goal is to define a vector of TLorentzVectors for later use with the same parent RDataFrame. The size of this vector is unknown at compile-time, since i’m defining it in an external (config-)file (i expect sizes from 3 to, say, 8 and could write overloaded functions for this).

My implementation is attached below. The conflicting part can be found in lines 17ff and 42.
misID_betaRDF_master.h (5.9 KB)

Sorry for not providing a standalone version. When trying to do so, ACLiC complained about:

input_line_13:14:1: warning: missing terminating '"' character [-Winvalid-pp-token]
" ignoring environment value of R_HOME
^
input_line_13:14:1: error: expected expression
input_line_13:15:83: warning: missing terminating '"' character [-Winvalid-pp-token]
/cvmfs/sft.cern.ch/lcg/releases/R/3.2.5-c6012/x86_64-slc6-gcc7-opt/lib64/R/include",
...

At the end of the day, i don’t really need a solution with variadic functions (and there are several possibilities to implement a workaround for my case), but it would be nice to understand if this is a problem with my implementation or if this corner case is not anticipated by RDataFrame.

Cheers,
Marian


ROOT Version: HEAD (dev3/latest)
Platform: x86_64-slc6
Compiler: g++ 7.3.0


Hi Marian,
all functions that you pass to RDataFrame must be non-overloaded and non-template, since RDataFrame finds out the types of your branches from the signature of that function --> so the signature must be non-ambiguous.

If you want to pass a variadic function, you can wrap in in a helper lambda:

auto callVariadicFunction = [](int x, double y) { return VariadicFuncion(x, y); };

The compiler will most probably optimize this extra step away.

Cheers,
Enrico

Hi Enrico,

Thanks for the super fast response and clarification of the issue!

Cheers,
Marian