Oppinion on 'least priviledge', 'const correctness', etc.
in [Java Help]
|
Prev: Simple Hack TO Get $1500 To Your PayPal Account.
Next: CPA AFFILIATE NETWORKS AWESOME EARNINGS FROM YOUR HOME
From: Daniel on 21 Jul 2010 12:58 On Jul 21, 11:13 am, Jim Janney <jjan...(a)shell.xmission.com> wrote: > Daniel <danielapar...(a)gmail.com> writes: > > On Jul 20, 2:14 pm, Jonathan Lee <jonathan.lee....(a)gmail.com> wrote: ..> > C++ methods can be declared as const, indicating that they don't > change the state of the objects they are invoked on. . On the contrary, there are no guarantees that they don't change the state of the object, for any meaningful definition of state. There are only restrictions on the first level of data in the object, there are no restrictions on changing the values of embedded variables, or data addressed by a pointer. -- Daniel
From: Öö Tiib on 21 Jul 2010 14:28 On 21 juuli, 19:58, Daniel <danielapar...(a)gmail.com> wrote: > On Jul 21, 11:13 am, Jim Janney <jjan...(a)shell.xmission.com> wrote: > > > Daniel <danielapar...(a)gmail.com> writes: > > > On Jul 20, 2:14 pm, Jonathan Lee <jonathan.lee....(a)gmail.com> wrote: > .> > > C++ methods can be declared as const, indicating that they don't > > change the state of the objects they are invoked on. . > > On the contrary, there are no guarantees that they don't change the > state of the object, for any meaningful definition of state. There > are only restrictions on the first level of data in the object, there > are no restrictions on changing the values of embedded variables, or > data addressed by a pointer. C++ gives no strong guarantees about anything. Notice that Jonathan said 'indicates' not 'guarantees'. It is matter of people who use it to decide what is evil and what is fine. Widespread concept is that method declared const modifying objects state is evil way to mislead users of the interface and only very few things are more evil than lying to your comrades. Lets look why compiler does not enforce it? Well, there are components of object (part of objects state) and there are other objects related by other sense (not part of objects state). Language does not make strong difference at what a pointer member of class points, is it a component, is it otherwise related object or maybe pointed at object is itself abstraction of some sort of relation. Teams policy may make difference, for example by using boost::scoped_ptr<> (or direct data member) for a component and boost::weak_ptr<> (or reference, or raw pointer) for other, non-owning relations. Compiler does know nothing about such policies. Entity that should decide and make difference and give guarantees is between chair and keyboard. Compiler lets to modify all pointed at by members objects, since it assumes that such entity knows exactly what it does. How should compiler give guarantees that such entity has ability to think? Compiler can not think, it is well-known fact. C++1x will introduce more ways to add more detailed attributes to things. It feels like for some that adds even more stuff to circumvent, misuse and then complain about lack of strong guarantees.
From: Öö Tiib on 21 Jul 2010 14:32 On 21 juuli, 21:28, Öö Tiib <oot...(a)hot.ee> wrote: > On 21 juuli, 19:58, Daniel <danielapar...(a)gmail.com> wrote: > > > On Jul 21, 11:13 am, Jim Janney <jjan...(a)shell.xmission.com> wrote: > > > > Daniel <danielapar...(a)gmail.com> writes: > > > > On Jul 20, 2:14 pm, Jonathan Lee <jonathan.lee....(a)gmail.com> wrote: > > .> Oh ... you did not quote anything from them. > > > C++ methods can be declared as const, indicating that they don't > > > On the contrary, there are no guarantees that they don't change the > > C++ gives no strong guarantees about anything. Notice that Jonathan So i mixed up Jim and Jonathan here.
From: Jim Janney on 21 Jul 2010 14:42 Daniel <danielaparker(a)gmail.com> writes: > On Jul 21, 11:13 am, Jim Janney <jjan...(a)shell.xmission.com> wrote: >> Daniel <danielapar...(a)gmail.com> writes: >> > On Jul 20, 2:14 pm, Jonathan Lee <jonathan.lee....(a)gmail.com> wrote: > .> >> C++ methods can be declared as const, indicating that they don't >> change the state of the objects they are invoked on. > > On the contrary, there are no guarantees that they don't change the > state of the object, for any meaningful definition of state. There > are only restrictions on the first level of data in the object, there > are no restrictions on changing the values of embedded variables, or > data addressed by a pointer. The const declaration is part of the method's contract. It's the programmer's responsibility to see that the method fulfills that contract, yes: I wouldn't have it any other way. As with most contracts, the primary benefit is to the method's callers. -- Jim Janney
From: Daniel on 21 Jul 2010 15:17
On Jul 21, 2:28 pm, Öö Tiib <oot...(a)hot.ee> wrote: > Notice that Jonathan said 'indicates' not 'guarantees'. > It is matter of people who use it to decide what is > evil and what is fine. Widespread concept is that > method declared const modifying objects state is evil way > to mislead users of the interface The compiler, though, can only rely on what the language specifies, and the language does not specify that a const method cannot change the object's state. The compiler cannot rely on conventions, and cannot take advantage of them to produce more efficient code. -- Daniel |