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

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.