Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Oppinion on 'least priviledge', 'const correctness', etc.

Reply
Thread Tools

Oppinion on 'least priviledge', 'const correctness', etc.

 
 
Öö Tiib
Guest
Posts: n/a
 
      07-23-2010
On 23 juuli, 09:09, Stuart Redmann <(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
 
Jorgen Grahn
Guest
Posts: n/a
 
      07-25-2010
On Thu, 2010-07-22, Juha Nieminen wrote:
> Jorgen Grahn <(E-Mail Removed)> wrote:
>> But I don't quite understand the rest of his reasoning.

>
> What is so unclear about it?


My full paragraph was:

>> He said "the const version of the member function"; I see no ambiguity
>> there. But I don't quite understand the rest of his reasoning.
>> Especially in the presence of aliasing.


I really focused on the obvious non-ambiguity of "the const version of
the member function", and didn't bother to read the rest carefully. I
should have phrased that differently; sorry.

It also turns out it *was* ambiguous, because I wasn't thinking of
overloading members by const -- I was thinking of whether the const in

void Foo::bar() const { ... }

usually matters for efficiency.

> Which is more efficient, this:
>
> const char& operator[](unsigned index) const
> {
> return str[index];
> }
>
> or this:
>
> char& operator[](unsigned index)
> {
> deep_copy_if_needed();
> return str[index];
> }
>
> ?
>
> That's how a class using copy-on-write would need to be implemented.


Sure, that's a drastic difference.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Oppinion on 'least priviledge', 'const correctness', etc. Alexander Java 38 07-23-2010 12:23 PM
Second Oppinion? FingAZ Computer Support 3 05-26-2006 04:28 AM
Oppinion regarding grid layout vs flow layout NWx ASP .Net 4 02-19-2004 08:56 PM



Advertisments