[The Architect 2.0]

so i was browsing through some C++ lit and stumbled upon functors. they're still a little fuzzy for me. basically, they are objects, treated as functions, that are passed as arguments to provide additional variable functionality* for the receiving function. am i correct?

anyhow, for a data structure i'm making, would it be 'proper' for me to build a binary predicate that returned true when one value DID NOT equal the other value?

*meaning that it can vary, depending on the functor passed through

[NickDMax]

Functors are objects that behave like functions. This can be helpful to give a *function* state. Its better than static function variables of the past.

There are also lots of usecases where they are just the ticket.

For example you can have a functor that calculates a running total.

You can have a set of polymorphic functors which share a common interface for plugging into something like a command pattern. (this is useful for creating simple scripting engines).

Functors also fit well into the STL algorithms.

Functors can have state so they are nice for applications where you have several arguments. For example in a Fuzzy logic application you may create a collection of hedge functions created with different sets of arguments.

So yes they can be passed into another function to change its behavior. For example you may pass in a Functor that determines which of two values is "greater" to a sort function so that it changes the way the objects are sorted. Basically this gives you the ability to "Sort By" different attributes of a collection of objects.

This same functionality can be done though function pointers so in this case forctors are not required, but they are a lot of fun.

AS for your question: I just don't really understand it. Generally for a data structure you rarely really need an "equals" operator -- but if you have time they are nice to have. Now for model objects you should create an equals operator to complete the class.

[The Architect 2.0]

i'll elaborate:

i was planning on using the STL adjacent_find algorithm. As i understood it, i could pass in a functor that would return a boolean value. the algorithm wouldn't 'care' how my functor determined if the two elements were equal, it just cared whether i returned true or false, MEANING* i could put w/e i wanted into the functor(in this case, instead of finding two equal sequential values, it finds two unequal sequential values).

as for the context, I have a STL map and i want to use adjacent_find to determine the element where the values deviate.

when i said 'proper,' i was inquiring if it would be too far from standard practice/bad coding practice(such as overloading operator* to add instead of multiply)


*as far as i understand

[NickDMax]

This would indeed be a proper use of the STL algorithm. The idea of the algorithm is to find two adjacent elements matching a given criteria. The DEFAULT criteria is that they are equal.

Now it would not be proper if you overladed the == operator just to get the default find_adjacent algorithm to work. This is because the operator == should return true when the two objects are logically equal.

Though whose to say what is "proper" or what "equal" means. In mathematics we often tweak the meanings of standard symbols. If I want to make the equals sign stand for some off the wall equivalence relation that so be it.

So for example if you wanted to find where a series of values has a marked deviation then creating a functor and using the find_adjacent algorithm seems like a good way to solve the problem.

[The Architect 2.0]

alright, that clears everything up

thanks alot