Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Functor with recursive call

47 views
Skip to first unread message

A

unread,
Jan 29, 2014, 11:12:25 AM1/29/14
to
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

unread,
Jan 29, 2014, 11:16:51 AM1/29/14
to
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.


Victor Bazarov

unread,
Jan 29, 2014, 11:28:15 AM1/29/14
to
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
--
I do not respond to top-posted replies, please don't ask

Alf P. Steinbach

unread,
Jan 29, 2014, 11:44:19 AM1/29/14
to
On 29.01.2014 17:12, A wrote:
>
> 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

A

unread,
Feb 3, 2014, 12:12:45 PM2/3/14
to
thank you guys for your most excelent answers!


0 new messages