Functor with recursive call

A

A

I have a functor which looks like this:

struct TLocalRecursiveF
{
void operator()(int *P1, std::vector<TStruct*> &S1)
{
P1++;
S1.push_back(TStruct());
this->operator()(P1, S1);
}
} RecursiveF;

RecursiveF(P0, S0);

Now, ignore for a sec the meaninglessness of this functor. In reality it is
a tree node builder.
It works fine but I am wondering, is this prefered to doing something like
this:

struct TLocal
{
static void RecursFunc(int *P1, std::vector<TStruct*> &S1)
{
P1++;
S1.push_back(TStruct());
RecursFunc(P1, S1);
}
};

TLocal::RecursFunc(P0, S0);

Is one version preferred over another or faster over another?
 
A

A

As I've seen that some use struct variables to simulate parameters, I am
actually asking, is that preferred to the way I passed parameters e.g.

this->operator()(...parameterlist...)

in a recursive part of the call.
 
V

Victor Bazarov

I have a functor which looks like this:

struct TLocalRecursiveF
{
void operator()(int *P1, std::vector<TStruct*> &S1)
{
P1++;
S1.push_back(TStruct());
this->operator()(P1, S1);
}
} RecursiveF;

RecursiveF(P0, S0);

Now, ignore for a sec the meaninglessness of this functor. In reality it is
a tree node builder.
It works fine but I am wondering, is this prefered to doing something like
this:

struct TLocal
{
static void RecursFunc(int *P1, std::vector<TStruct*> &S1)
{
P1++;
S1.push_back(TStruct());
RecursFunc(P1, S1);
}
};

TLocal::RecursFunc(P0, S0);

Is one version preferred over another or faster over another?

A member function has a hidden argument - the object for which it's
called. If your function has no particular need for the object, making
it 'static' will mean tiny savings in both stack size use during
recursion and performance. Most likely you won't notice it, really. As
always the advice is to measure it before making a decision.

Functors have a very specific trait - they satisfy a requirement to be
"callable", which makes them useful with standard algorithms like
'for_each'. In that sense the alternative to a functor is not a struct
with a static member function, but a stand-alone function. The functor
is really only needed when it has a *state*. A stand-alone function
usually doesn't.

V
 
A

Alf P. Steinbach

Is one version preferred over another or faster over another?

I would prefer the one that most closely matches the requirements at
hand and is most clear and simple to understand.

The requirements are however not obvious.

If you need local state then a non-static member function might be it,
but I would prefer a named one rather than operator(), unless this
object has to be passed to other code as a functor.

Otherwise the static member function is good.

You might alternatively consider a named namespace level function placed
in e.g. a `detail` namespace.

Or if this is in a (outer) class, just an ordinary but non-public member
function of that class, instead of doing everything locally, even if in
a sense that is like polluting the class scope with the implementation
details of one of its member functions.

A local lambda would run into the problem of expressing the recursion,
which would necessitate either a local struct or accessing an outside
reference to the lambda (e.g. a `std::function` instance), so that would
just be more complication, not less. I think.

Summing up, one of the four first. ;-)


Cheers & hth.,

- Alf
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,995
Messages
2,570,226
Members
46,815
Latest member
treekmostly22

Latest Threads

Top