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: Öö Tiib on 23 Jul 2010 08:23 On 23 juuli, 09:09, Stuart Redmann <DerTop...(a)web.de> wrote: > > On 22 juuli, Stuart Redmann wrote: > > > C++ offers the means to extend the const correctness even over > > > pointers: > > > > class SomeClass > > > { > > > public: > > > void foo () const {} > > > void bar () {} > > > > }; > > > > class AnotherClass > > > { > > > protected: > > > SomeClass* SomeObject; > > > public: > > > AnotherClass (SomeClass* Object) > > > : SomeObject (Object) > > > {} > > > SomeClass* GetObject () > > > { > > > return SomeObject; > > > } > > > const SomeClass* GetObject () const > > > { > > > return SomeObject; > > > } > > > > }; > > > > int main () > > > { > > > SomeClass a; > > > const AnotherClass b (&a); > > > b.GetObject ()->foo (); // OK > > > b.GetObject ()->bar (); // Compilation error: b is const > > > > AnotherClass c (&a); > > > c.GetObject ()->foo (); // OK > > > c.GetObject ()->bar (); // OK: c is not const > > > > } > > > > Stroustrup mentiones this technique in his book (can't cite the page > > > since I seem to haave mislaid it). Although it's a pain in the neck to > > > write const-overloaded accessors for member pointers, this is a > > > technique that can extend const-correctness so that it works for > > > everything. > > On 22 Jul., Öö Tiib wrote: > > > Yes, this is obvious. Only problem of it is that *SomeObject is not > > const within implementation of some const member of AnotherClass and > > so may be modified by mistake there. Special smart pointer that > > extends constness by its nature removes that issue as well. > > I see what you mean. I think the following template class should > achieve this: > > // Wrapper for plain pointers that behaves as const-correct > // accessor. > template<class t_Class> > class ConstCorrectAccessor > { > t_Class* m_InternalPointer; > public: > ConstCorrectAccessor (t_Class* Pointer) > : m_InternalPointer (Pointer) > {} > > // Accessor methods with const-correct overload. > const t_Class* operator-> () const {return m_InternalPointer;} > t_Class* operator ->() {return m_InternalPointer;} > > }; Yes, something like that ... operator*() is missing. > class SomeClass > { > public: > void foo () const {} > void bar () {} > > }; > > class AnotherClass > { > public: > ConstCorrectAccessor<SomeClass> SomeObject; > public: > AnotherClass (SomeClass* Object) > : SomeObject (Object) > {} > > void foo () const > { > SomeObject->foo (); // OK > SomeObject->bar (); // Error: Non-const method on SomeObject. > } > > }; > > int main () > { > SomeClass a; > const AnotherClass b (&a); > b.SomeObject->foo (); // OK > b.SomeObject->bar (); // Compilation error: b is const > > AnotherClass c (&a); > c.SomeObject->foo (); // OK > c.SomeObject->bar (); // OK: c is not const > > } > > Do you know whether such a thing is part of the STL/boost? No, but usually i want RAII as well for such a polymorphic component. So i took "boost::scoped_ptr<>" and modified it into a "component_ptr<>" with transitive constness. Probably it might be idea to add custom deleter (like boost::shared_ptr<> has), since polymorphic things are often created and destroyed by factories. Also, custom deleter helps when wrapping some sort of "handle" (lets say from some C library) into class.
From: Nick Keighley on 27 Jul 2010 04:28
Subject: Oppinion on 'least priviledge', 'const correctness', etc. [it's a good idea to include the subject in your post] On 20 July, 14:36, "Francesco S. Carta" <entul...(a)gmail.com> wrote: > Alexander <alva...(a)gmail.com>, on 20/07/2010 06:00:45, wrote: > > Wherever I find something on the topic, these are considered positive. it increases security. You *know* the function didn't modify the parameter. It gives your compiler clues as to your intent which may allow it to do a better job of optimisation. > > Why? I only find it time-consuming. Could you respond (preferably on > > comp.programming) why it can be considered as such, but motivated, > > that is without responses like "it's good software engineering > > practice", "it's just better", etc... I'm a learner, and I think now > > is the best time to shape out practices and priorities. you limit the scope of identifiers don't you? (really, don't you?!). Think how much simpler it would be if they were all global <sarcasm!>. This limits who can access them. Well const is another varient. As is static on a function declaration. <snip> > I don't know about "least privilege", I'll look it up. from wikipedia "In information security, computer science, and other fields, the principle of least privilege, also known as the principle of minimal privilege or just least privilege, requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user or a program on the basis of the layer we are considering) must be able to access only such information and resources that are necessary to its legitimate purpose." <snip> -- 'And, Of course, I must give you the standard warning about metaphoric deformations.' 'All right,' Marvin said. `I'd like to hear about it.' 'I just gave it,' Blanders said. `But I will give it again. Watch out for metaphoric deformations.' (Robert Sheckly, Mindswap) |