hi all.

I have a question regarding the standards as for overloading operator() -
the
function call operator.

in all places I've come upon meeting an implementation of such overloading,
the
overloaded operator was declared const (not changing non-mutable members of
called object in context)

is this enforced by the standard?

if so, how come?

is it a mandatory or a user-defined behaviour?

I would appreciate an answer.

Rotem

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Rotem Yaari wrote:

> I have a question regarding the standards as for overloading operator() -
> the function call operator.

> in all places I've come upon meeting an implementation of such overloading,
> the overloaded operator was declared const (not changing non-mutable
> members of called object in context)

> is this enforced by the standard?
> Rotem

No.

However, many STL algorithms (now C++ library algorithms) take function objects
and may work with copies of them. Since you don't know which copy will be
modified you should design your function objects so that they won't be
modified. Making operator() const is one way to enforce this.

So you can call it good style (in this context).

--
Michiel Salters
Michiel.Salters@cmg.nl
salters@lucent.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Michiel Salters wrote:
>
> Rotem Yaari wrote:
>
> > I have a question regarding the standards as for overloading operator() -
> > the function call operator.
>
> > in all places I've come upon meeting an implementation of such overloading,
> > the overloaded operator was declared const (not changing non-mutable
> > members of called object in context)
>
> > is this enforced by the standard?
> > Rotem
>
> No.
>
> However, many STL algorithms (now C++ library algorithms) take function objects
> and may work with copies of them. Since you don't know which copy will be
> modified you should design your function objects so that they won't be
> modified. Making operator() const is one way to enforce this.
>
> So you can call it good style (in this context).

That's not so much good style, as necessity, when it applies. If you
can't be guaranteed that the object won't be copied at arbitrary points
in the process, then there's little point in it retaining an internal
state, and therefore little need for a non-const operator().

I couldn't find anything in the standard prohibiting an implementation
from making arbitrary copies of any of the function objects, nor
anything warning users that copying might occur. When the function
object is passed by value, copying certainly occurs, if only at the
point of the call to the template function, and this is case in all but
one of the standard library algorithms. Unless you get back an updated
copy of the function object, keeping an internal state would have only
limited usefulness.

The one exception to by-value passing is the optional
RandomNumberGenerator argument in random_shuffle<>(). In fact, I assume
that it's intended for RandomNumberGenerator to have a non-const
operator(), in order to allow it to update the internal state it needs
to produce a different psuedo-random number each time it's called. The
internal state could be declared mutable, or stored in a pointer to
non-const allocated memory, while the pointer itself is const; however,
the most convenient option is a non-const operator(). I would hope that
it's required that the originally referenced object be used, rather than
a copy of it, because  that would make it more convenient to arrange
that the generator continue its state across several different calls to
random_shuffle. I couldn't find anything that says so explicitly,
however.


There's one other special case: for_each() returns a Function object
which is required to be the same object as the one that was passed to
it. Since the object is passed by value, this really means that it must
return a copy of the object that is passed to it. The only reason I can
see for such an interface is if the Function object is allowed to
accumulate information in it's internal state about the elements it was
applied to, using a non-cost operator(). In order for that to work, of
course, for_each() must not use a seperate copy of the input object for
each iteration; that may be implied by the standard, but it's certainly
not said explicitly.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Rotem Yaari wrote:
>
> hi all.
>
> I have a question regarding the standards as for overloading operator() -
> the
> function call operator.
>
> in all places I've come upon meeting an implementation of such overloading,
> the
> overloaded operator was declared const (not changing non-mutable members of
> called object in context)
>
> is this enforced by the standard?

No. Nothing's "enforced" by the standard - the standard has no
enforcement powers; it's just a document. However, it's also not
required by the standard, which is what I assume you were asking.

> is it a mandatory or a user-defined behaviour?

User-defined.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

I agree with you on one thing:

Non-const function objects are not very common.

I disagree about much of the rest. State-retaining function objects can and
are useful in some cases, many of which apply the visitor pattern in
internal
designs. Many (non-bad-form) designs I have seen and worked with use
state-oriented function objects to iterate over both STL and non-STL
collections gracefully.

Indeed, the by-value problem occurs, but using carefully-considered copy
constructors and assignment operators we can create a correct and useful
design out of function objects.

And remember, the STL isn't the only one using function objects!

Not every non-common design is necessarily bad form.

And by the way, by saying that a standard "enforces" something I simply mean
that that something is documented as a correct semantic of the standard.

Indeed, the standard isn't obligatory but in a world where portable software
becomes more and more important, it is considered such!


thanks alot,

Rotem

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Rotem Yaari wrote:
>
> I agree with you on one thing:

I presume that the "you" you're referring to is me? You didn't mark this
as a reply to my message, which was a little confusing.

> Non-const function objects are not very common.
>
> I disagree about much of the rest. State-retaining function objects can and
> are useful in some cases, many of which apply the visitor pattern in
> internal
> designs. Many (non-bad-form) designs I have seen and worked with use
> state-oriented function objects to iterate over both STL and non-STL
> collections gracefully.

I didn't say that state-retaining function objects aren't useful; only
that the fact that most standard library algorithm pass function objects
by value reduces the usefulness of retaining state - when using those
algorithms. I didn't even say that the usefulness disappeared, only that
it was reduced. I even mentioned a techique (using pointers) that would
allow you to retain state even if the algorithm copies the function
objects freely.

...
> And remember, the STL isn't the only one using function objects!

I was very careful to construct my statements so that they only referred
to the use of function objects by the standard library algorithms.

> Not every non-common design is necessarily bad form.

I never implied anything to the contrary. I was merely trying to explain
why the design was uncommon, and hence why the you might have gotten the
idea that it might be prohibited.

> And by the way, by saying that a standard "enforces" something I simply mean
> that that something is documented as a correct semantic of the standard.

Which has nothing to do with the correct meaning of the word "enforce".
To enforce a rule is to prevent violations of that rule, or at least to
discourage violations by punishing the violators. The standard, being
only a document, has no power to do anything of the kind. The standard
lays down the rules; enforcement of those rules is done by human beings.

Incidentally, the standard is not enforced by the standards agencies
themselves - they generally have no enforcement powers. It's usually
other organizations which negotiate contracts that require conformance
to a standard, and then assign people to enforce those contracts by
checking for conformance. I work under just such a contract for NASA.
The organization I work for accepts code from scientists from all over
the world, and fixes it as needed (which is pretty frequently!) to
conform with the applicable standards before allowing it to go into
production on our system.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]