private inheritance vs containment

  • Permalink
  • submit to reddit
  • Email
  • Follow


I know that this one has been discused many times and every single book
about C++ advices to first consider containment.

But I feel that there is a legitimate use of private inheritance when a
single condition is met (the base class has no virtual functions, so
inheriting from your class will not have a customization point you don't
intent to give) and the (small) extra performance private inheritance
gives is needed.

Any comments on my thinking.

Thanks in advance.

Sam.

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Reply Sam 5/27/2007 6:27:17 PM

See related articles to this posting


Sam wrote:
> I know that this one has been discused many times and every single book
> about C++ advices to first consider containment.
> 
> But I feel that there is a legitimate use of private inheritance when a
> single condition is met (the base class has no virtual functions, so
> inheriting from your class will not have a customization point you don't
> intent to give) and the (small) extra performance private inheritance
> gives is needed.

As a general advice, you may want to check out this C++ FAQ Lite topic:
[24] Inheritance - private and protected inheritance
http://www.parashift.com/c++-faq-lite/private-inheritance.html

and this message and thread from the past for a particular situation
where private inheritance is very useful:
http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/35c34091a34298f8/f4b765eb77950dfa#f4b765eb77950dfa

However, I cannot imagine a case where private inheritance will give
you any extra performance over containment. Can you give an example?

-- 
Seungbeom Kim

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Reply Seungbeom 5/28/2007 6:29:03 AM

Sam <sakarab@yahoo.com> wrote:

> I know that this one has been discused many times and every single book
> about C++ advices to first consider containment.
> 
> But I feel that there is a legitimate use of private inheritance when a
> single condition is met (the base class has no virtual functions, so
> inheriting from your class will not have a customization point you don't
> intent to give) and the (small) extra performance private inheritance
> gives is needed.
> 
> Any comments on my thinking.

Just the opposite is true. Consider:

class Foo {
public:
    virtual void func();
};

class Bar : private Foo {
public:
    virtual void func(); // override here
};

To do the same with containment would require an extra class:

class FooChild : public Foo {
public:
    virtual void func(); // override here
};

class Bar {
    FooChild foo;
};

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Reply Daniel 5/28/2007 6:31:14 AM

Seungbeom Kim wrote:
> Sam wrote:
>> ... and the (small) extra performance private inheritance
>> gives is needed.
> 
> However, I cannot imagine a case where private inheritance will give
> you any extra performance over containment. Can you give an example?
> 

When a contained object member function is called, its "this" pointer
must be calculated and passed to it. On the other hand in an inheritance
relationship the "this" pointer is the same with the derived object. No
calculation needed. Example:

struct A
{
     void do_work();
};

// containment
class B
{
private:
     A  mA;
public:
     void do_work()      { mA.do_work(); }
}

// private inheritance
class C : private A
{
public:
     void do_work()      { A::do_work(); }
}

int main()
{
     B    b;

     // gets address of b, calculates address of
     // B::mA and calls A::do_work()
     b.do_work();

     C    c;

     // gets address of c, directlly calls A::do_work()
     c.do_work();
}

Sam.

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Reply Sam 5/28/2007 12:17:39 PM

In article <f3erhm$fnq$1@mouse.otenet.gr>, Sam <sakarab@yahoo.com>
wrote:

> Seungbeom Kim wrote:
> > Sam wrote:
> >> ... and the (small) extra performance private inheritance
> >> gives is needed.
> > 
> > However, I cannot imagine a case where private inheritance will give
> > you any extra performance over containment. Can you give an example?
> > 
> 
> When a contained object member function is called, its "this" pointer
> must be calculated and passed to it. On the other hand in an inheritance
> relationship the "this" pointer is the same with the derived object. No
> calculation needed.

The above is a micro-optimization that the compiler can likely take care
of itself.

> Example:
> 
> struct A
> {
>      void do_work();
> };
> 
> // containment
> class B
> {
> private:
>      A  mA;
> public:
>      void do_work()      { mA.do_work(); }
> }
> 
> // private inheritance
> class C : private A
> {
> public:
>      void do_work()      { A::do_work(); }
> }
> 
> int main()
> {
>      B    b;
> 
>      // gets address of b, calculates address of
>      // B::mA and calls A::do_work()
>      b.do_work();
> 
>      C    c;
> 
>      // gets address of c, directlly calls A::do_work()
>      c.do_work();
> }

In the above code, the B::do_work function would likely be expanded
inline which means the "calculation" you speak of is done at compile
time, not run time. No performance advantage here.

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Reply Daniel 5/28/2007 5:27:15 PM

Daniel T. wrote:
> Sam <sakarab@yahoo.com> wrote:
> 
>> I know that this one has been discused many times and every single book
>> about C++ advices to first consider containment.
>>
>> But I feel that there is a legitimate use of private inheritance when a
>> single condition is met (the base class has no virtual functions, so
>> inheriting from your class will not have a customization point you don't
>> intent to give) and the (small) extra performance private inheritance
>> gives is needed.
>>
>> Any comments on my thinking.
> 
> Just the opposite is true.
> 

I don't really understand what your point is.
Can you elaborate please?

Sam.

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Reply Sam 5/28/2007 5:32:26 PM

In article <f3d8g6$o8l$1@news.Stanford.EDU>, Seungbeom Kim
<musiphil@bawi.org> wrote:

> 
> However, I cannot imagine a case where private inheritance will give
> you any extra performance over containment. Can you give an example?

struct Private
{
   void foo(){};
}

class A:private Private
{
public:
   using Private::foo;
};

class B
{
   Private b;
public:
   void foo() {b.foo();}
};

A  a;
B b;

b.foo() directly calls B::foo(), which calls Private::foo() but
a.foo() directly calls Private::foo().  Your compiler probably
will optimize the excess call away but private inheritance guarantees
the direct call of Private::foo().

Further private inheritance gives instant documentation that A uses
foo of Private with no changes. and using statements are ussually
shorter and less error prone than forwarding functions.  Take your
pick.


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Reply Carl 5/28/2007 7:48:09 PM

Sam <sakarab@yahoo.com> wrote:
> Daniel T. wrote:
> > Sam <sakarab@yahoo.com> wrote:
> > 
> > > I know that this one has been discused many times and every
> > > single book about C++ advices to first consider containment.
> > >
> > > But I feel that there is a legitimate use of private inheritance
> > > when a single condition is met (the base class has no virtual
> > > functions, so inheriting from your class will not have a
> > > customization point you don't intent to give) and the (small)
> > > extra performance private inheritance gives is needed.
> > >
> > > Any comments on my thinking.
> > 
> > Just the opposite is true.
> 
> I don't really understand what your point is. Can you elaborate
> please?

Maybe the FAQ will help:
http://www.parashift.com/c++-faq-lite/private-inheritance.html#faq-24.3

My point is that a legitimate use of private inheritance is when the
base class *does* have at least one virtual function, and you want to
override that function, but don't want the child class to be convertible
into the parent class.

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Reply Daniel 5/29/2007 12:40:37 AM

On May 27, 9:27 pm, Sam <saka...@yahoo.com> wrote:
> I know that this one has been discused many times and every single book
> about C++ advices to first consider containment.
>
> But I feel that there is a legitimate use of private inheritance when a
> single condition is met (the base class has no virtual functions, so
> inheriting from your class will not have a customization point you don't
> intent to give) and the (small) extra performance private inheritance
> gives is needed.

I use it in one of my template libraries.  The basic idea is that the
class implements an abstract interface, but that interface cannot be
accessible externally or to derived classes; the class limits access
to that interface via a mutex.  This ensures that the class itself can
cast to the abstract class under its own terms but nothing else can.
It's difficult to describe in a post, but here is the link.
http://capsule-ta0kira.sourceforge.net/
http://capsule-ta0kira.sourceforge.net/#IOS

Kevin P. Barry


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Reply ta0kira 5/29/2007 12:44:45 AM

Daniel T. wrote:
> In article <f3erhm$fnq$1@mouse.otenet.gr>, Sam <sakarab@yahoo.com>
> wrote:
> 
>> When a contained object member function is called, its "this" pointer
>> must be calculated and passed to it. On the other hand in an inheritance
>> relationship the "this" pointer is the same with the derived object. No
>> calculation needed.
> 
> The above is a micro-optimization that the compiler can likely take care
> of itself.

Our perspective differ. You call it "micro-optimization", I call it "(small)
extra performance", others are concerned about the overhead of a virtual call
and others don't (virtual call's overhead compared to the containment overhead
is almost the same, fetch one extra address, the address of a function in the
first case, the address of the this pointer of the contained object in the
later).

> 
>> Example:
>>
>> struct A
>> {
>>      void do_work();
>> };
>>
>> // containment
>> class B
>> {
>> private:
>>      A  mA;
>> public:
>>      void do_work()      { mA.do_work(); }
>> }
>>
>> // private inheritance
>> class C : private A
>> {
>> public:
>>      void do_work()      { A::do_work(); }
>> }
>>
>> int main()
>> {
>>      B    b;
>>
>>      // gets address of b, calculates address of
>>      // B::mA and calls A::do_work()
>>      b.do_work();
>>
>>      C    c;
>>
>>      // gets address of c, directlly calls A::do_work()
>>      c.do_work();
>> }
> 
> In the above code, the B::do_work function would likely be expanded
> inline which means the "calculation" you speak of is done at compile
> time, not run time. No performance advantage here.
> 

There are cases where the compiler can optimize the "calculation" / passing of
the this pointer, if for example

1. the address of the container object is the same with the contained object
2. the code of the A::do_work() function is known to the compiler not to use
any class member variables or methods so it doesn't need a this pointer
3. the called functions is known to access only class member variables that
can be calculated as offset from the address of the container object.

The above list of course is not exhaustive and is implementation dependent.
But private inheritance is not (implementation dependent).

Sam.

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Reply Sam 5/29/2007 4:49:44 PM

Daniel T. wrote:
> Sam <sakarab@yahoo.com> wrote:
>> Daniel T. wrote:
>>> Sam <sakarab@yahoo.com> wrote:
>>>
>>>> But I feel that there is a legitimate use of private inheritance
>>>> when a single condition is met (the base class has no virtual
>>>> functions, so inheriting from your class will not have a
>>>> customization point you don't intent to give) and the (small)
>>>> extra performance private inheritance gives is needed.
>>>>
>>>> Any comments on my thinking.
>>> Just the opposite is true.
>> I don't really understand what your point is. Can you elaborate
>> please?
> 
> Maybe the FAQ will help:
> http://www.parashift.com/c++-faq-lite/private-inheritance.html#faq-24.3
> 
> My point is that a legitimate use of private inheritance is when the
> base class *does* have at least one virtual function, and you want to
> override that function, but don't want the child class to be convertible
> into the parent class.
> 

I feel there is a misunderstanding going on here and after (re)reading my
original post it possibly is my fault.

Please change the words "But I feel that there is a legitimate use of private
inheritance" with "But I feel that there is **one more** legitimate use of
private inheritance".

Does this make a difference?

Sam.

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Reply Sam 5/29/2007 4:50:14 PM

On 5/29/07 4:49 PM, in article f3i6uv$pmu$1@mouse.otenet.gr, "Sam"
<sakarab@yahoo.com> wrote:

> Daniel T. wrote:
>> In article <f3erhm$fnq$1@mouse.otenet.gr>, Sam <sakarab@yahoo.com>
>> wrote:
>>
>>> When a contained object member function is called, its "this" pointer
>>> must be calculated and passed to it. On the other hand in an inheritance
>>> relationship the "this" pointer is the same with the derived object. No
>>> calculation needed.
>>
>> The above is a micro-optimization that the compiler can likely take care
>> of itself.
>
> Our perspective differ. You call it "micro-optimization", I call it "(small)
> extra performance", others are concerned about the overhead of a virtual call
> and others don't (virtual call's overhead compared to the containment overhead
> is almost the same, fetch one extra address, the address of a function in the
> first case, the address of the this pointer of the contained object in the
> later).

There is no "extra performance" obtained by using private inheritance
instead of containment in the example below - because the
"computational work" required by the semantics of either approach is
the same. In both cases, two methods are called and each is passed a
"this" pointer (at least conceptually) as a hidden argument. Since
neither of the "this" pointer arguments so passed is any more
expensive for the compiler to obtain than the other - and since
obtaining neither pointer requires any additional runtime information
over and above what is needed to obtain the other pointer - there is
no basis for concluding that private inheritance offers any
performance advantage (however minuscule) over containment.

In particular, any comparison between containment and virtual method
dispatching is simply erroneous. The compiler does not need b's
address in order to obtain b.mA's address. Because b.mA is located at
a known location within a B object (which in the code below happens to
be zero), the compiler can just as easily pass mA as a "this" pointer
argument as it can a pointer to b itself.

And real-world C++ compilers bear this observation out: on a typical
machine architecture, local variables are referenced as offsets
relative to a stack pointer. So, for example, if b is located at
0(SP), then mA would also be found at 0(SP) (in the example below) -
but even if mA were located 4(SP) or 8(SP) or wherever - there would
be no additional overhead incurred: instead of passing 0(SP) to each
of the two methods, the compiler would pass 0(SP) to the first method
and 4(SP) to the second and do so no less efficiently.

>>
>>> Example:
>>>
>>> struct A
>>> {
>>>      void do_work();
>>> };
>>>
>>> // containment
>>> class B
>>> {
>>> private:
>>>      A  mA;
>>> public:
>>>      void do_work()      { mA.do_work(); }
>>> }
>>>
>>> // private inheritance
>>> class C : private A
>>> {
>>> public:
>>>      void do_work()      { A::do_work(); }
>>> }
>>>
>>> int main()
>>> {
>>>      B    b;
>>>
>>>      // gets address of b, calculates address of
>>>      // B::mA and calls A::do_work()
>>>      b.do_work();
>>>
>>>      C    c;
>>>
>>>      // gets address of c, directlly calls A::do_work()
>>>      c.do_work();
>>> }
>>
>> In the above code, the B::do_work function would likely be expanded
>> inline which means the "calculation" you speak of is done at compile
>> time, not run time. No performance advantage here.
>
> There are cases where the compiler can optimize the "calculation" / passing of
> the this pointer, if for example
>
> 1. the address of the container object is the same with the contained object
> 2. the code of the A::do_work() function is known to the compiler not to use
> any class member variables or methods so it doesn't need a this pointer
> 3. the called functions is known to access only class member variables that
> can be calculated as offset from the address of the container object.
>
> The above list of course is not exhaustive and is implementation dependent.
> But private inheritance is not (implementation dependent).

Compiled code is always "implementation-dependent." Eliminating a
second load instruction to pass the "this" argument to the second
method is just as much an optimization as optimizations #1-3 on the
list above. So when comparing the efficiencies of alternate
approaches, it only makes sense to assume an optimally efficient C++
compiler. Otherwise, if one is going to assume that the C++ compiler
does not produce optimally efficient code - then one cannot also
assume that the inefficiencies of the compiler-generated code (and
likewise, whatever optimizations the compiler did apply) will only
favor private inheritance. Yet that is exactly the argument that is
being made here: that the compiler will be smart enough to optimize
away a second load instruction for a this pointer argument when
calling the second method - but at the same time the compiler cannot
be smart enough to eliminate the load instructions completely because
they are not being used at all.

Greg


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

0
Reply Greg 6/1/2007 6:53:04 AM
comp.lang.c++.moderated 10649 articles. 9 followers. Post

11 Replies
327 Views

Similar Articles

[PageSpeed] 40


  • Permalink
  • submit to reddit
  • Email
  • Follow


Reply:

Similar Artilces:

inheritance vs. containment
What would be the theoretical advantages of containment over inheritance? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Mohammad wrote: > What would be the theoretical advantages of containment over > inheritance? Nothing, if you need polymorphism and everything if you don't. There are several books ruminating on the topic, one is Design Patterns Explained, this topic comes up pretty frequently in Herb Sutters books... and IIRC Scott Meyers mentions this as well. One major idea here is coup...

Inheritance vs containment for policies
Hello all, The methodology of policy-based design states that one should inherit from policy classes and, of course, these classes must provide an agreed-upon public interface and semantics. I would like to understand better why inheritance, rather than containment, is espoused. The only things I can see that inheritance provides beyond containment is the possibility of polymorphism and access to protected members. Since neither of these are needed when trying to gain access to the functionality of a policy class, why is inheritance espoused over containment? Thanks, Dave [ See h...

Private vs. protected inheritance
Hi dear programmers I looked for the difference between private and protected inheritance, but couldn't find anything. Here is my sample code: #include <iostream> using std::cout; using std::endl; class Base { public: Base() { cout << "***Base constructor called***" << endl; } ~Base() { cout << "***Base destructor called***" << endl; } protected: void coutAnything() { cout << "Anything" << endl; } }; class Derived : protected Base { public: Derived() { cout << "***Derived constructor called***&qu...

Inheritance vs containment for policies
Hello all, The methodology of policy-based design states that one should inherit from policy classes and, of course, these classes must provide an agreed-upon public interface and semantics. I would like to understand better why inheritance, rather than containment, is espoused. The only things I can see that inheritance provides beyond containment is the possibility of polymorphism and access to protected members. Since neither of these are needed when trying to gain access to the functionality of a policy class, why is inheritance espoused over containment? Thanks, Dave "Dave&qu...

Private interface using reinterpret_cast vs. inheritance
Try this here too (a bit modified)... looks like no success in comp.lang.c++ ;) ---- Hi! I'd like to implement a private interface and I have the choices mentioned in the subject. The implementation using private inheritance is probably cleaner but it also adds some space and time overhead compared to the 'cast' -method. The problem with the cast method is that I don't know whether its C++ standard-compliant and/or portable? Example: // Inheritance method class LayerData { public: virtual int usefullStuffToLayer() = 0; virtual Object* getObjectInterface() = 0; }...

Yet another inheritance vs containment question
Hi, I see there already is at least one fresh thread going on about inheritance vs. containment. So it might not be such a great idea to start yet another one on this subject. If so I'm sorry... Jerry Coffin posted some code a couple of months ago, code that I can adapt and find good use for in an application I'm writing. It contains multiple inheritance, public and private, and that made me wonder about the whole topic of inheritance vs containment. The code is: #include <locale> #include <algorithm> template<class T> class table { typedef typename std::cty...

Private inheritance vs internal class declaration
MSVC seems to have a tough time with this program: struct A { struct L {}; }; struct B: private A::L { struct L {}; }; struct C: public B::L // <-- Error: see below { }; int main() { C c; } --- error C2247: 'A::L' not accessible because 'B' uses 'private' to inherit from 'A::L' It seems to me that A::L and B::L are completely different classes, and the fact that B inherits privately from A::L should effectively hide the A::L interface from B's users. It also seems that MSVC is the only compiler complaining about this. Both g+...

Is there any better approach to private inheriting from the STL containers?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm writing 2 classes which is intended to be used like any other STL containers: // begin code class Lrv { public: Lrv(); Lrv(const Lrv &rhs); explicit Lrv(int number); Lrv &operator=(const Lrv &trailer); operator bool() const; const int &phase; const int &number; const bool &trailer; bool is_compatible_with(const Lrv &trailer) const; bool matches(unsigned constraint) const; private: int _phase, _number; bool _...

Contained procedure vs. private module procedures
What is best ? I have several times faced this choiche, and usually choosed between the 2 options on a matter of convenience, more or less long argument list vs. the possibility of a procedure to become public because it may be needed outside its module, sometime in the future. Are there more formal, or experience-proven, rules ? Thanks in advance Gigi "GianLuigi Piacentini" <ggpiace@tin.it> wrote in message news:525071a0$0$23124$4fafbaef@reader2.news.tin.it... > What is best ? > I have several times faced this choiche, and usually choosed betwee...

Private interface using reinterpret_cast vs. inheritance (long)
Hi! I'd like to implement a private interface and I have the choices mentioned in the subject. The implementation using private inheritance is probably cleaner but it also adds some space and time overhead compared to the 'cast' -method. The problem with the cast method is that I don't know whether its C++ standard-compliant and/or portable? Example: // Inheritance method class LayerData { public: virtual int usefullStuffToLayer() = 0; virtual Object* getObjectInterface() = 0; }; class Layer { public: void doSomething(LayerData* p) { int stuff = p-&g...

Private Inheritance and Publice Inheritance
Hi, Could someone here tell me some links/pdfs/tutorials to know about the difference between Private Inheritance and Public Inheritance ? I am unable to get info w.r.t it. Thx in advans, Karthik Balaguru karthikbalaguru <karthikbalaguru79@gmail.com> wrote: > Could someone here tell me some links/pdfs/tutorials to know about the > difference between Private Inheritance and Public Inheritance ? > I am unable to get info w.r.t it. http://www.parashift.com/c++-faq-lite/private-inheritance.html karthikbalaguru wrote: > Could someone here tell me some links/pdfs/tutorials to...

Interface inheritance vs Implementation inheritance.
(x-posted to c.object and c.l.java.programmer)First, a quick bit about my background; most of my OO experience comesfrom Java, with some C++ in my past. Recently in comp.object, there was a thread "Inheritance of implementation: what is reason of". While the subject line could use some grammatic tweaking, the point was eventually made clear.I was thinking about it, and it seems to me that implementationinheritance is a convenience that leads to bad design and mistakes. Byconvenience, I mean that often a programmer will design the an interfaceand the implementation together in one s...

Containers of iterators vs. containers of references
Relatively new to STL use. I coded up a bunch of container code with lots of iterators. Now I question whether I want to have so much nested iterator syntax. For example, if you are coding a compiler and you have classes such as BasicBlock. Each basic block has predecessors and successors in the control flow graph. Right now, I am storing these as iterators: list<list<BasicBlock>::iterator> Predecessors; list<list<BasicBlock>::iterator> Successors; This leads to messy looking code. I have a GetFirstPred() method that now returns something of type: list<list<B...

Function vs Sub /Public vs Private
I'm hoping someone can tell me if there is any performance benefit in my applications between distinguishing a code routine as a Function or a Sub or if there is a performance benefit between identiying a Function as a Function or a Private Function (or Sub as a Sub or a Private Sub) in code modules. I understand that using Private Functions or Private Subs limits the scope from which it can be called, but I'm wondering if there is any speed or overhead benefit in making the distinction. I know I can't call a Sub using "=SubName()" in the event procedure of a control, o...

Inheritance based type conversion and private inheritance
Hello everybody! I have just been playing around a little with inheritance based type conversion and I am using Microsoft Visual C++ 2005 Express Edition to compile the following code: template <typename T> class SmartPtr { T* m_ptr; public: SmartPtr( T* ptr = 0 ) : m_ptr( ptr ) {} ~SmartPtr() { delete m_ptr; } template <typename U> operator SmartPtr<U>() { // An accessible conversion from type // pointer-to-T to type pointer-to-U // must exist for this to compile. return SmartPtr<U>...

std::container::iterator vs std::container::pointer
Hi all, I tried looking this up in the sgi docs but it didn't provide any concrete answer to what I'm looking for. Basically, is there any difference between using ::iterator for a container vs using ::pointer? I did a quick experiment and replaced all the ::iterator in my code with ::pointer and it seems to work the same. What I'm think is on the surface they're the same but perhaps there're some subtle differences beneath the surface that I'm unaware of? Thanks "Vivi Orunitia" <Vivi@blackmagevillage.com> wrote in message news:Xns94841E297AB88...

Private access modifier and Inheritance (Inheritance implementation in Java)
Hi everybody! I have a question about how Inheritance is implemented in Java. This code example is in the JLS (Java Language Specification) "8.2.1.3 Inheritance with private" Section: class Point { int x, y; void move(int dx, int dy) { x += dx; y += dy; totalMoves++; } private static int totalMoves; void printMoves() { System.out.println(totalMoves); } } class Point3d extends Point { int z; void move(int dx, int dy, int dz) { super.move(dx, dy); z += dz; totalMoves++; } } A guy on the web gave the following explanation for the previous code snippet: <...

what is private inheritance
Hi I have a following sample code class base and class derived. I have inherited the base class as private and tried to compile the code its giving an error "conversion from 'class derived *' to 'class base *' exists, but is inaccessible" If I inherit using public it works well ... I am not very clear about the private inheritance I will be happy if someone can guide me ... when shall I use public, private and protected inheritance ------------------------------------------------------- #include<iostream> using namespace std; class base{ public: int b; vir...

How to... private inheritance ?!
Hi all, Apologies if the subject has been already discussed but I have been unable to find what I am looking for. My background is predominantly C+ + and while I have been trying to familiarise myself with Java I have come across something I can't get my head around. In C++ one can create an interface through a pure abstract class then derive from that interface privately, whilst providing concrete implementation of the methods exposed by the interface. The reason one might want to implement a private inheritance is to force the user of the concrete class to cast it to the interface with...

private inheritance
#include <iostream> class Foo{ public: Foo(){std::cout<<"Foo ";}; }; class Bar:Foo{ public: Bar(){std::cout<<"Bar ";}; }; class FooToo: virtual Foo{ public: FooToo(){std::cout<<"FooToo ";}; }; class FooTooBar: virtual FooToo,virtual Bar{ public: FooTooBar(){std::cout<<"FooTooBar ";}; }; main (){ FooTooBar x; } should x be instantiated o should it give compiler error? Aleksandr Rulev wrote: > #include <iostream> > > class Foo{ > public: > Foo(){std::cout<<"Foo ";}; &...

Under vs inheritance
This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C35D05.C1B5E990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am currently reading up on the history behind inheritance in postgres and found this interesting post back in May 2000. http://archives.postgresql.org/pgsql-hackers/2000-05/msg01349.php From reading other posts, it seems that there is the idea that since under is single inheritance then tables "under" another are all really in that same relation only they act the as expected to t...

composition vs 'leaf-class mixins' (vs class inheritance)
I have a design question inspired by Rails 3 internals. In Design Patterns in Ruby, the Strategy pattern is cited as a way to vary an algorithm following the oft-spoken "prefer composition over inheritance" advice. For a concrete example, let's say we wanted to fight in the matrix: class Person attr_accessor :skills def initialize(skills) @skills = skills end def fight @skills.each { |skill| skill.invoke } end end class KungFu def invoke puts "5-fisted punch" end end class Dodge ...

why don't the STL containers all inherit from a common container class to allow generic iteration?
Subject says it all really. I have been in Javaland for a while where you do have this capability. I am aware of Meyers Effective STL item 2 ("beware of the illusion of container-independent code") but I don't think item 2 applies when all you want to do is iterate over a container. This is the simple case that people want to do most of the time (IMHO). Of course if you want to do something else like reverse iterate etc then with C++ you can. But it does seem mysterious to me why it is more awkward to do a generic iteration for the most common case. I realise that in t...

Should 'public virtual' always become 'private virtual'? & using private inheritance
class base { // other members public: virtual ~base() { } virtual void virtualMethod1()=0 ; virtual void virtualMethod2()=0 ; virtual void virtualMethod3()=0 ; } ; I derive a class from base. I want to make all the virtual functions as private. class derived : public base { // other members public: virtual ~derived() { } void myPublicInterface1() ; void myPublicInterface1() ; private: virtual void virtualMethod1()=0 ; virtual void virtualMethod2()=0 ; virtual void virtualMethod3()=0 ; } ; I did the above considerin...