If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register or Login
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Re: howto restric a method to being absolutely constant

Superbonzo his example only solves something if programmers wrap all their pointers in pseudo_const_ptr<T>. If they have "regular" pointers in their classes then the const method will still compile. Now I can't force programmers to wrap their pointers any more then I can force them to only call const members. Thus, although it illustrates the behavior I want very well it doesn't solve the basic problem at all! @Lindley: Is this wrapper a decorator?

An absolute_const qualifier on the method would force any implementation of the virtual operator()() in a derived class to only read the objects state and the state of any other object to which there are pointers in the object. Non-const arguments can still be changed but that isn't relevant.

Which brings me back to my question: is their something like an absolute_const qualifier? read_only might also be good name for such a qualifier. I'm guessing the answer is no in which case I'm stuck with const.

I know this restriction isn't just useful in multi-threaded applications but it's a good example of applications where you could use such a qualifier.

Re: howto restric a method to being absolutely constant

Originally Posted by ssouffri

Superbonzo his example only solves something if programmers wrap all their pointers in pseudo_const_ptr<T>. If they have "regular" pointers in their classes then the const method will still compile. Now I can't force programmers to wrap their pointers any more then I can force them to only call const members. Thus, although it illustrates the behavior I want very well it doesn't solve the basic problem at all!

I'm confused. Why do you have to "force" other programmers to do anything? What's the context here? I thought you were just asking for the sake of your own code's safety.

It's pretty much impossible to absolutely, positively FORCE another coder to write code which doesn't change anything if they're absolutely determined to do so. No matter what qualifier you try to put on, they can const_cast it away. So you need to define your requirements better before we can suggest the best approach to meeting them.

@Lindley: Is this wrapper a decorator?

Not really, but it serves a similar purpose.

Which brings me back to my question: is their something like an absolute_const qualifier? read_only might also be good name for such a qualifier. I'm guessing the answer is no in which case I'm stuck with const.

Re: howto restric a method to being absolutely constant

Superbonzo his example only solves something if programmers wrap all their pointers in pseudo_const_ptr<T>.

But superbonzo's example is how you would usally control the state of your object,
and his example is 100 times better than overloading per every class you write,
wouldn't you agree?

If they have "regular" pointers in their classes then the const method will still compile. Now I can't force programmers to wrap their pointers any more then I can force them to only call const members.

You're enforcing rules on your own class, so what's the problem here?

An absolute_const qualifier on the method would force any implementation of the virtual operator()() in a derived class to only read the objects state and the state of any other object to which there are pointers in the object. Non-const arguments can still be changed but that isn't relevant.

No, theoretically speaking, "absolute const" would mean that
any operators that affect its state of, such as assignment, is "guaranteed to fail"
no matter where, when, what, and how it was invoked.
And frankly speaking, I wouldn't want this type of monopoly to be set as the standard.

Which brings me back to my question: is their something like an absolute_const qualifier?

why do you think this should fail to compile?
the compiler is doing exactly what its supposed to do.
At what point do you think ConstObject is not a const ConstObject?
That's right, never.
Therefore,
ConstObject can freely call const and non-const member functions of any other classes
whatsoever.

So again, if you're good enough to be working for the company,
you need to start thinking about the const qualifier in terms operator invocation,
not merely a sign that says "don't change"

Re: howto restric a method to being absolutely constant

But superbonzo's example is how you would usally control the state of your object,
and his example is 100 times better than overloading per every class you write,
wouldn't you agree?

No. I think you missed the point of what I would like to do. I'm not simply using inheritance because I like it. My whole point was that superbonzo's code doesn't allow me to restrict the behaviour of any classes that derive from my functor interface. At most it can help people who code those derived classes not to make those mistakes. But it doesn help my interface restrict the behaviour of those subclasses. Weather they wrap their pointers or not is completely in their hands. And the compiler won't be able to spot errors if they don't.

Originally Posted by potatoCode

You're enforcing rules on your own class, so what's the problem here?

I'm anticipating on potential errors in the many classes which will be written by people, including myself, that will implement my interface.

Originally Posted by potatoCode

No, theoretically speaking, "absolute const" would mean that
any operators that affect its state of, such as assignment, is "guaranteed to fail"
no matter where, when, what, and how it was invoked.
And frankly speaking, I wouldn't want this type of monopoly to be set as the standard.
No.

Writing interfaces is all about clearly defining functionality and restricting usage to just that functionality for the sake of avoiding coding errors. Even if you can't see them, I have good reasons for wanting such restrictive behavior. It's existence wouldn't mean you would have to use it everywhere. You don't use const everywhere, do you, but at times it is very useful for restricting usage of objects.

Originally Posted by potatoCode

why do you think this should fail to compile?
the compiler is doing exactly what its supposed to do.
At what point do you think ConstObject is not a const ConstObject?
That's right, never.
Therefore,
ConstObject can freely call const and non-const member functions of any other classes
whatsoever.

Maybe I wasn't clear. My point was that if operator() was qualified as "absolutely_const" then it would fail to compile. In other words the desired code behaviour would be enforced by the compiler, unless you use mutable attributes. But at least you will have gotten a fair warning. Which would be great!

Originally Posted by potatoCode

So again, if you're good enough to be working for the company,
you need to start thinking about the const qualifier in terms operator invocation,
not merely a sign that says "don't change"

What company, what is that supposed to mean? I'm thinking about it in terms of general member invocation. Const says: calling this member of an object will not change the object. I want absolute_const to say: calling this member will not change anything other than the arguments provided to the member. But since it doesn't exist I will have to rely on const and good documentation!