Re: [boost] Boost.Function const semantics

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-07-22 17:01:27

On Sunday 22 July 2001 03:17, you wrote:
> Douglas Gregor writes:
>  > >  If we take
>  > > the analogy of a "pointer to functor", you're fighting with the
>  > > difference between:
>  > >
>  > > 1) functor * p;
>  > > 2) functor const * p;
>  > > 3) functor * const p;
>  > > 4) functor const * const p;
>  > >
>  > > your current semantics seem to have (=> meaning "is analogous to"):
>  > >  functor => 1)
>  > >  const functor => 4)
>  > >
>  > > while the proposed semantics seem to be:
>  > >  functor => 1)
>  > >  const functor => 3)
>
> I made a few typos later on in what I wrote.  To clarify:
> 1) functor can be reseated, calls 'operator()' on its referent.
> 2) functor can be reseated, calls 'operator() const' on its referent.
> 3) functor cannot be reseated, calls 'operator()' on its referent.
> 4) functor cannot be reseated, calls 'operator() const' on its referent.
>
>  > I was proposing just:
>  > functor => 1
>  >
>  > and an auxiliary function object could (at 'function'
>  > assignment/initialization time) decide if for a particular target
>  > function object instance, it should be
>  > functor => 3
>
> I'm not quite sure what you mean by "auxiliary function object." Could
> you perhaps suggest some syntax?

See below...

> given the following:
>
> struct ftor {
>    void operator()();
>    void operator()() const;
> };
>
> void my_func(const function<void>& f) { f(); }
>
> what do you propose happens if I call my_func with a boost function
> pointing to 'ftor?  I'm under the impression that your proposal would
> call 'operator()()', which was what I meant above in my statement of
> your proposal.

Yes, the new semantics would call the non-const operator()() of ftor.

> I'm not sure I understand what you're saying here.  Could you write
> out a possible syntax for this?

So, if one wanted to call ftor::operator()() const, the 'auxiliary function 
object' would come into play. It would be a simple set of function objects 
like this:

template<typename F, typename R, typename T1, typename T2, ..., typename TN>
struct invoke_as_constN {
  invoke_as_constN(const F& f) : m_f(f) {}
  R operator()(T1 a1, T2 a2, ..., TN aN) const 
    { return m_f(a1, a2, ..., aN); }
  F m_f;
};

These classes would be used like this:

function<void> f;
function<void> fc;

f = ftor(); 
fc = invoke_as_const0<ftor, void>(ftor());

f(); // calls ftor::operator()()
fc(); // calls ftor::operator()() const via invoke_as_const0

>  > > One pertinent question is, is there a sensible use for a functor with
>  > > semantics 2) or 4).  That is, does it make sense to have a functor
>
> argh!  I meant 3) or 4) here, but I think you got the idea.  It makes
> sense to have a boost.functon that cannot be reseated regardless of the
> constness of the referent.

Yes.

>  > changed. However, see the reason in my prior post why having parallel
>  > function/const_function won't (and probably can't) work.
>
> quoted here:
>  > Perhaps. The one major difference between iterator/const_iterator and a
>  > function/const_function is that iterators have definitive "pointed-to"
>  > types, e.g., iterator to int and iterator to const int. The same does
>  > not quite apply to function, because it "points to" some
>  > dynamically-chosen type that always has an operator() const and may have
>  > an operator() as well. I think that because of this discrepancy the
>  > decision to call const or non-const shouldn't be up to the 'function'
>  > itself (i.e., function or const_function),
>
> Just some thought...suppose you had an iterator it over a container of
> functor base class objects with virtual 'operator()()'. If you call:
> (*it)();
> it would call the derived object's operator()().  if you have a
> "const iterator" (NOT const_iterator), the same thing would happen.
> The difference is that the iterator cannot be moved. This const
> iterator would be analogous to a "const boost.function" which could
> not be reseated.
>
> Now if you have a "const_iterator" cit into this container and call:
> (*cit)();
> it would call the derived's 'operator()() const'.  Of course an iterator
> of type "const const_iterator" would do the same, but not be movable.
> Supposing there were a boost.const_function, this would be the
> analogous type (if const, can't be reseated).
>
> now, on to your discussion below:
>  > The conversions may even be impossible :). Thinking about this, for
>  > instance, with the above my_function_object class:
>  >
>  > boost::function<int, int, int> f = my_function_object();
>  > boost::const_function<int, int, int> fc = f;
>  >
>  > So "f" should call my_function_object::operator() and fc should call
>  > my_function_object::operator() const? Can't happen: f doesn't even know
>  > my_function_object::operator() const exists, because it only references
>  > the non-const version, so what actually happens is that fc targets a
>  > copy of f, which targets the non-const my_function_object::operator()!
>
> I don't think that the above line should cause fc to target f as it
> would a function object of any other type.
> const_function would not target function, but cause a conversion from
> type function to type const_function. This is an altogether different
> beast.  Now, the big question is as follows:  Is it possible to detect
> during a conversion from function to const_function (either at compile
> or runtime) whether the referent of an already created boost.function
> has an 'operator() const'.

I believe the answer to this is 'no'. Once the assignment of a target to a 
boost::function object has been completed, the target's type information is 
lost. Anything we didn't lookup during the assignment we won't have access 
to. So if boost::function only looks up a non-const operator(), we don't know 
how to access operator() const when we copy the boost::function object into a 
boost::const_function object. Granted, we could lookup both operator() and 
operator() const, but then we're back to stub routines :(.

> take the following code:
> ---<snip>---
> struct my_functor {
>   void operator()() { } // no const
> };
>
> int main() {
> // ...
> my_functor* f = new my_functor();
> my_functor const* fc = f;
>
>  (*f)();
>  (*fc)();
>  return 0;
> }
> ---<snip>---
>
> A compiler should not accept it.  I like to think that the same sort
> of detection can be made in a conversion from boost.function to
> boost.const_function, but due to casting stuffs, perhaps it cannot be
> determined until runtime (I only vaguely understand the implementation
> of boost.function)? At which point a runtime fault of some sort
> sort could occur.

Having the ability to convert from boost.function to a boost.const_function 
requires a const version to always exist, even if it is invalid. Such a 
restriction can be a great annoyance. I think that using the wrapper 
(invoke_as_constN above, though perhaps will some sugar trickery to make it 
easier on the fingers) is the best alternative. Whether the const or 
non-const operator() is called should be dependent on the target ("pointee") 
of the boost.function, and not on whether a boost.function or a 
boost.const_function is used. 

>  > > As far as making the semantic change, I vote for doing so.  While
>  > > Boost.Function is already "out there", I think that the current
>  > > semantics confusing.  If/When these changes are released, A notice
>  > > should go in the Boost Release notes stressing such a semantic
>  > > change.
>  > >
>  > >
>  > > ron
>  >
>  > Does Boost have Release Notes?
>  >
>  > 	Doug
>
> I was thinking of what appears on the main web page after a release.

        Doug