class Test
{
public:
typedef boost::function<void()> Action;

void action()
{
}

Action getAction() const
{
return boost::bind(&Test::action, this);
}
};

Above code does not compile on Visual Studio 2005 Express Edition
because getAction is a "const" method. Is this compliant with the
standard? This seems counterintuitive to me since the state of the
object is not changed by calling this method.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

I don't understand your problem and requirement.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Hello Francis,

your code doesn't compile because the pointer 'this' is of type 'const
Test*' within your const member function 'Test::getAction()'. You're
trying to bind this const pointer as first parameter to the non-const
member function Test::action() which expects a non-const pointer Test*
as first parameter. Your compiler is certainly rejecting ill-formed
code in this regard because the standard doesn't allow implicit const
casts.

The solution is to make both member functions either const or non-
const. This makes their 'this' pointers of the same type and doesn't
require an ugly const_cast in Test::getAction().

Note, that if it did compile you'd be able to do something like this:
void do_something(const Test& x)
{ x.getAction()(); }
which might change the object even though a const reference has been
passed to the function. It works against the idea of constness.

Cheers,
SG

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 12 Aug., 22:41, francis_r <francis.ramme...@gmail.com> wrote:
> class Test
> {
> public:
> typedef boost::function<void()> Action;
>
> void action()
> {
> }
>
> Action getAction() const
> {
> return boost::bind(&Test::action, this);
> }
>
> };
>
> Above code does not compile on Visual Studio 2005 Express Edition
> because getAction is a "const" method. Is this compliant with the
> standard? This seems counterintuitive to me since the state of the
> object is not changed by calling this method.

I'm thinking the compiler is right. In a const method you are trying
to
provide a none const access to your method "action"! "action" is
allowed
to change the content...



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

francis_r wrote:
> class Test
> {
> public:
> typedef boost::function<void()> Action;
>
> void action()
> {
> }
>
> Action getAction() const
> {
> return boost::bind(&Test::action, this);
> }
> };
>
> Above code does not compile on Visual Studio 2005 Express Edition
> because getAction is a "const" method. Is this compliant with the
> standard?

Yes. The point is that 'this' is a pointer to a const Test, while bind would
need a pointer to a non-const Test. BTW, I guess you could have reduced the
example even further:

...
void getAction() const
{
boost::bind( &Test::action, this); // anonymous temporary
}
...

> This seems counterintuitive to me since the state of the
> object is not changed by calling this method.

By the same logic, you would also be able to return references to non-const
members from const memberfunctions, after all returning a reference doesn't
change them. No, if that would compile, it would be a hole in the
const-ness of the object, so it shouldn't.

Uli


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Aug 13, 10:58 pm, Ulrich Eckhardt <dooms...@knuut.de> wrote:
> francis_r wrote:
> > class Test
> > {
> > public:
> > typedef boost::function<void()> Action;
>
> > void action()
> > {
> > }
>
> > Action getAction() const
> > {
> > return boost::bind(&Test::action, this);
> > }
> > };
>
> > Above code does not compile on Visual Studio 2005 Express Edition
> > because getAction is a "const" method. Is this compliant with the
> > standard?
>
> Yes. The point is that 'this' is a pointer to a const Test, while bind would
> need a pointer to a non-const Test. BTW, I guess you could have reduced the
> example even further:
>
> ...
> void getAction() const
> {
> boost::bind( &Test::action, this); // anonymous temporary
> }
> ...
>
> > This seems counterintuitive to me since the state of the
> > object is not changed by calling this method.
>
> By the same logic, you would also be able to return references to non-const
> members from const memberfunctions, after all returning a reference doesn't
> change them. No, if that would compile, it would be a hole in the
> const-ness of the object, so it shouldn't.

Interestingly enough, it does compile in VS2008 when using its own
std::tr1 implementation for function & bind, rather than Boost. Thanks
for clarifying why this is a problem - I've reported it to MS as a
bug:

https://connect.microsoft.com/Visual...dbackID=361784


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Aug 12, 4:41 pm, francis_r <francis.ramme...@gmail.com> wrote:

> Above code does not compile on Visual Studio 2005 Express Edition
> because getAction is a "const" method. Is this compliant with the
> standard? This seems counterintuitive to me since the state of the
> object is not changed by calling this method.

In this case, there's absolutely nothing wrong with a 'const_cast',
but the compiler is correct in not implicitly converting 'this' to a
pointer to non-const.
Kevin P. Barry

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 21 Aug., 15:28, ta0k...@yahoo.com wrote:
> On Aug 12, 4:41 pm, francis_r <francis.ramme...@gmail.com> wrote:
>
> > Above code does not compile on Visual Studio 2005 Express Edition
> > because getAction is a "const" method. Is this compliant with the
> > standard? This seems counterintuitive to me since the state of the
> > object is not changed by calling this method.
>
> In this case, there's absolutely nothing wrong with a 'const_cast',
> but the compiler is correct in not implicitly converting 'this' to a
> pointer to non-const.
> Kevin P. Barry
>
In this case - as is usually the case - there is everything wrong with
a const_cast. We must presume that the caller wants to use the
function, and if he does so, our constant object will be changed -
possibly resulting in undefined behaviour.

/Peter

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Aug 21, 5:02 pm, peter koch larsen <peter.koch.lar...@gmail.com>
wrote:

> In this case - as is usually the case - there is everything wrong with
> a const_cast. We must presume that the caller wants to use the
> function, and if he does so, our constant object will be changed -
> possibly resulting in undefined behaviour.

The function doesn't modify the instance with the 'const_cast', and
what happens after the function's return isn't the concern of that
function. Sure, if the object is unconditionally 'const' then that
would be undefined behavior, but otherwise the 'const'-ness of the
function isn't compromised. In this case it's the class' author's
responsibility to document that calling the 'getAction' function on a
'const'-defined instance causes undefined behavior. In fact, I can't
think of a *more* appropriate circumstance to use a 'const_cast',
though such a move requires minor documentation for proper usage, as
does nearly every other non-trivial interface.
Kevin P. Barry

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 12 Aug, 21:41, francis_r <francis.ramme...@gmail.com> wrote:
> class Test
> {
> public:
> typedef boost::function<void()> Action;
>
> void action()
> {
> }
>
> Action getAction() const
> {
> return boost::bind(&Test::action, this);
> }
>
> };
>
> Above code does not compile on Visual Studio 2005 Express Edition
> because getAction is a "const" method. Is this compliant with the
> standard? This seems counterintuitive to me since the state of the
> object is not changed by calling this method.

If your reasoning were valid the following would also be allowed:

class Test
{
public:
typedef int& Action;

int action;

Action getAction() const
{
return action;
}

void ModifyConst() const
{
getAction() = 42;
}
};

You will see that getAction does not modify the state of the object
and yet this is clearly wrong for exactly the same reason that
your example is wrong.

The general principal for const-correctness is that given only a
pointer to a const object you should never be able to call a non-const
method or modify a non-mutable value without explicitly casting away
constness.

Clearly your example is not const-correct:
const Test* tp;
tp->getAction()(); // calling non-const method

You can no-more be "a bit" const-correct than you can be "a bit"
pregnant.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]