Oppinion on 'least priviledge', 'const correctness', etc.
in [General Programming]
|
Prev: Simple Hack TO Get $1500 To Your PayPal Account.
Next: Const correctness (was Re: Oppinion on 'least priviledge', 'constcorrectness', etc.)
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
From: Daniel on 21 Jul 2010 15:27 On Jul 21, 2:42 pm, Jim Janney <jjan...(a)shell.xmission.com> wrote: > The const declaration is part of the method's > contract. It's the programmer's responsibility to see > that the method fulfills that contract > But what exactly is the contract? The meaning of const is what the C++ standard says it is. -- Daniel
From: Francesco S. Carta on 21 Jul 2010 16:31 Daniel <danielaparker(a)gmail.com>, on 21/07/2010 12:17:28, wrote: > 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 above statement seems partly wrong to me: up to a some degree, the compiler can enforce the C++ specification, and in this case, it specifies that a const method cannot change the members of the object it is called upon (unless they're declared "mutable") - in practice, though, this means that the compiler does its best to forbid that method to /directly/ change those members, so yes, the compiler cannot fully enforce the directive, but that does not mean that such a directive does not exist: obviously, the compiler control can be circumvented, but that would be a deliberate choice of the programmer, for which the programmer takes on all responsibilities. > The compiler cannot rely on conventions, and > cannot take advantage of them to produce more efficient code. But it can rely on the code it analyses. In all the cases where a compiler is able to prove its "right" to do some optimization, it will do it - if properly instructed to do so, eventually. For example, even if some variable is not declared as "const", if the analysis can prove that no instruction changes that variable during some particular lapse of time, then the compiler is free to cache its value for performance reasons. All the features, keywords and checks are there only for the human advantage and protection, the computer does not care if the code it runs is safe or clever - it can perfectly run as hell on the abyss' edge without falling, as long as its code "works". Making that code "to work" is the human task, and additionally, humans create conventions to "stay on the path" and they instruct compilers to "recall to the human to stay on the path". At least, all the above is what I have understood about these subjects so far, though, I'm not an implementer nor a C++ standard expert, so you might take my words with a grain of salt. -- FSC - http://userscripts.org/scripts/show/59948 http://fscode.altervista.org - http://sardinias.com
From: Öö Tiib on 21 Jul 2010 16:51 On 21 juuli, 16:29, Lew <no...(a)lewscanon.com> wrote: > Öö Tiib wrote: > > "Const Correctness" 39,000 results, "Favor Immutability" 1,080. It is > > That's a measure of how often a particular phrase turns up, not how often the > topic comes up. Your "research' is a complete red herring. Probably so, i was surprised myself. > > more about how to create immutable classes, while in C++ you do not > > need to (but may) make special classes for constant instances. > > Yeesh. "How to create immutable classes" *is* a discussion of "favor > immutability". How come you didn't include those stats in your count? Hm? Ok. In C++ when you need immutable instance of some class you just declare it const so no much discussion there either. You may have mutable instances of the very same class. Compiler does not let you to modify immutable instance (unless implementer uses evil techniques, results of some of whose may be undefined). Sometimes you also may make entirely immutable classes, like in Java. Usually it is done for well-separating immutable superclasses, interfaces. Class can not have 'const' base in C++. It makes also sense when immutable is entirely different object (like for example immutable picture is different from one yet to paint). 'final' aids in creation of immutable classes but it does not itself create/guarantee immutability of classes. We are on equal grounds there. > Maybe Java doesn't use a fancy term; when discussing immutability and final we > just say, "making things final" or "making things immutable" or other phrases > with the word "final" and "immutable", and everyone understands that we talk > about that because of the advice to "favor immutability" without having to > quote that particular chapter title. Thanks for explaining, the terms have different meaning and mechanics. Greater goal to make the data that should be immutable really hard to modify by accident is same. > No one lasts long in Java without hearing about Joshua Bloch's /Effective > Java/, whence came the phrase "favor immutability", and no one progresses far > as a Java programmer without studying that book. > > So strengthen your google-fu and try again, and don't quote misleading and > irrelevant statistics. Sorry, if it offended you. If it is major clear chapter in industry standard then there are less to discuss about. C++ is older, community has not unfortunately established such industry-wide good policy standard. const correctness is widely accepted, yes. However, there are still legacy libraries around that simply ignore it at places and demand privileges that they do not deserve. That is nuisance that automatically increases amount of ongoing discussions and complaints, too. > Lew wrote: > >> Again, that's not the claim. The claim is that 'final' is similar for Java to > >> what 'const' is in C++, in certain ways. > Öö Tiib wrote: > > Ok. Making primitive immutable with 'final' is yes in certain ways > > same. It is mostly perhaps used for naming single constant values, not > > write protection? You can also make a pointer immutable with 'final'. > > That is sometimes done in C++ too but usually one uses a reference for > > it ('const' is not needed at all). > > Java doesn't have C++ references; what Java calls "reference" is actually a > pointer. Yes, what i meant was that C++ 'reference' is sort of immutable pointer. C++ has pointers too and one may make these immutable with 'const' but it is rarely made so, possibly the whole feature is for compatibility with C. > Lew wrote: > >> Everyone here seems to think that Java 'final' is just nothing a-'tall like > >> C[++] 'const'. They are, of course, mistaken. > Öö Tiib wrote: > > 'const' yes, feels more oriented for not giving (and taking) unneeded > > privileges locally. Major feature of 'const' is to declare that code > > will not modify the object pointed to by a pointer through that > > pointer. Other feature is to declare that function does not modify its > > parameter and third is to show that member function does not modify > > the object. How you do any of these with 'final'? > > Java cannot access an object by a pointer to a pointer, since those don't even > exist, so that purpose isn't needed. I meant that variable declared final can be still modified by calling its methods, unless it is of immutable class (that simply does not have such methods)? Modifying such variables is made lot harder in C++ by 'const'. > 'final' applied to a function parameter > has a cognate purpose - the function cannot change the contents of the > parameter. To prevent anything (not just a member function) from modifying > the object, Java uses 'final', but on the attributes of the object, not the > method. Yes. Different mechanics here. Ok. Thanks for clearing it up.
From: Öö Tiib on 21 Jul 2010 17:31
On 21 juuli, 22:17, Daniel <danielapar...(a)gmail.com> wrote: > 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. const member function can not modify any data members of object but the ones marked explicitily as always 'mutable' (such are rare), nor can it call other non-const member functions of it nor can it call the non-const member functions of its data members. Compiler can take advantage even of unmodified mutable things staying immutable in the frame where compiler wants to optimize something. Do not underestimate compiler writers. These are clever guys. 'const' is there for to help programmers and optimizations are lesser concern. Protection can be circumvented by const_cast. One using it has likely to prove to his comrades that it was least evil thing in situation he was in to do. That will be hard to prove to better of peers since C++ is extremely flexible. That leaves only state pointed at by raw pointer members in class that stay mutable. I already told why it is so, such raw pointer may point at something that is not part of the state of class. OTOH i have also seen policies that declare raw pointers as 'not C++' and forbid usage of raw pointers. Smart pointers however may keep and enforce constness as transitive depending on type of relation whose abstraction they are. |