thats a, however, I believe aCode:type * const
cannot change the object it points to.Code:type const *
Printable View
thats a, however, I believe aCode:type * const
cannot change the object it points to.Code:type const *
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.
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.
Not really, but it serves a similar purpose.Quote:
@Lindley: Is this wrapper a decorator?
If there were, someone would have mentioned it by now.Quote:
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.
Well I'm not the only one working on my project. So it would be a safety measure for me as much as anyone else.
To bad you can't force this in C++. I'll have to put a few extra exclamation marks in my documentation then.
I would suggest simply notating in the documentation for your interface that implementing class objects must be immutable.
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?
You're enforcing rules on your own class, so what's the problem here?Quote:
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.
No, theoretically speaking, "absolute const" would mean thatQuote:
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.
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.Quote:
Which brings me back to my question: is their something like an absolute_const qualifier?
why do you think this should fail to compile?Quote:
Code:class NotConstObject {
private:
int i;
public:
void nonConstMember(){
i=0;
}
};
class ConstObject{
private:
NotConstObject *nco;
public:
ConstObject(NotConstObject *nco): nco(nco){
}
void operator()() const {
nco->nonConstMember();
}
};
main(void){
NotConstObject nco;
const ConstObject o(&nco);
o();
return 0;
}
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"
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.
I'm anticipating on potential errors in the many classes which will be written by people, including myself, that will implement my interface.
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.
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!
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!
http://www.ddj.com/cpp/184403766
That's essentially a misuse of the type system and I don't recommend it, but it's worth a read.