What differentiates function objects from poltergeists?

Question

The Short (Original) Version

How are function objects, sometimes called "functors" in C++ and other OO languages, where they make sense different from classes symptomatic of the poltergeist anti-pattern?

Definitions

• A function object is a construct allowing an object to be invoked or called as if it were an ordinary function (full definition, more references follow).
• A poltergeist is a short-lived object, typically stateless, which is used solely to trigger or initialize several other objects and then discarded. It is considered a consequence of poor object design (full definition, more references follow).

Why Do I Ask?

In many places in the extensive code-base I'm working on, a complex data structure is being traversed in a few different ways, and each element is being acted upon. In order to not violate the DRY principle by re-writing the complex traversal code and its variants, I instead have several higher-order traversal functions which accept function objects that act on elements as arguments. Likely, (C++) iterator pattern is warranted here, but it was missing and its implementation is costly, so I deferred it.

I had a concern that these multiple function objects would obfuscate my code and make it less maintainable, but instead of asking "do these make my code more obscure", which seems like an opinion-based question, so I alluded to more-or-less known things with concrete definitions. I did not quite understand why function objects cannot all be classified as poltergeists / bad design before the answer was kindly provided below by Karl Bielefeldt.

Additional References

Poltergeists:

• Brown, William J. (1998). "Chapter 5: Software Development AntiPatterns". AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. New York, USA: John Wiley & Sons. Available here. Crisis. New York, USA: John Wiley & Sons.
• An example of a poltergeist in Php by Serega Zhuk
• 9 Anti-Patterns Every Programmer Should Be Aware Of, by Sahand Saba

Originally, this question also included this article here, which likely means it's also in the book Design Patterns Explained Simply, but [disclaimer] people took issue with this article in the comments for reasons seemingly unrelated to the actual concept.

Object functions:

• Functors in C++

Clarifications, or What This Question is Not About

• This question is neither about how well-known the term "poltergeist anti-pattern" is, nor is it about whether it discourages or encourages good or bad coding practices. Please refer to the Wikipedia article on possible confusions about this concept.

• This question is not about what is and what isn't a functor. The term "functor" means different things in the context of functional programming and the context of object-oriented languages. This question refers to function objects, i.e. the latter definition.

Answer 1

First of all, be careful about calling them functors, because apparently C++ people ignored the entire history of what functor means and decided to redefine that name for their function objects, which is a completely different thing than what most people think of as a functor.

Second, the poltergeist anti-pattern requires doing something unexpected via side effect. If your operator() method has side effects, then it could certainly qualify as an example of that anti-pattern. However, there are also uses of operator() that don't have side effects, such as emulating partial function application. Those uses may potentially have other anti-patterns, but without unexpected side effects, it wouldn't be a poltergeist pattern.

Answer 2

Very simple, potentially short-lived objects are damn useful in many scenarios; yes, what they mistakenly call "functors" (partially-applied functions), tuples, optionals, etc match this pattern.

If one cares about utter efficiency and not ever allocating an extra byte, one should first detect the hot code path, and optimize it. For the rest of the design (likely 99% of it), such optimizations do not bring any benefit.

Anything that helps thinking about the program more easily and clearly does bring a benefit.