Composition using references

Discussion in 'C++' started by anongroupaccount@googlemail.com, Dec 10, 2005.

  1. Guest

    I have an ABC with a protected member that is a reference to an object
    of an ABC type:

    class ABC
    {
    public:
    virtual ~ABC() = 0;
    protected:
    AnotherABC& _member;
    }

    The idea is that my concrete classes will derive from ABC and set
    _member in their initialization lists to the specific type of
    AnotherABC that the particular class needs. However, this can't be done
    as the constructors of the derived classes complain about there being
    no default constructor for ABC.

    Should I simply replace the reference with a const pointer, or should I
    rethink this and save myself from a potentially nasty design flaw? Is
    there a design pattern I could use here?
    , Dec 10, 2005
    #1
    1. Advertising

  2. wrote:
    > I have an ABC with a protected member that is a reference to an object
    > of an ABC type:
    >
    > class ABC
    > {
    > public:
    > virtual ~ABC() = 0;


    your destructor should be protected, not public.

    > protected:



    your data member should be private, not protected.

    > AnotherABC& _member;
    > }



    > The idea is that my concrete classes will derive from ABC and set
    > _member in their initialization lists to the specific type of
    > AnotherABC that the particular class needs.


    Can't do that. Instead, ABC needs a (protected) constructor that sets
    member, and the derived class can call that constructor.

    > However, this can't be done
    > as the constructors of the derived classes complain about there being
    > no default constructor for ABC.


    It won't if you follow the above advice.

    > Should I simply replace the reference with a const pointer, or should I
    > rethink this and save myself from a potentially nasty design flaw? Is
    > there a design pattern I could use here?


    I've given you code below:

    class Other;

    class Base {
    Other& other_; // this is private
    protected:
    virtual ~Base() = 0;
    Base(Other& o) : other_(o) {}
    };

    Base::~Base() {}

    class Derived : public Base {
    public:
    Derived(Other& o) : Base(o) {}
    };

    Best regards,

    Tom
    Thomas Tutone, Dec 10, 2005
    #2
    1. Advertising

  3. Guest

    Thomas Tutone wrote:
    > wrote:
    > > I have an ABC with a protected member that is a reference to an object
    > > of an ABC type:
    > >
    > > class ABC
    > > {
    > > public:
    > > virtual ~ABC() = 0;

    >
    > your destructor should be protected, not public.


    Why is that? I can understand the constructor being protected, but not
    the destructor. Won't this mean that delete won't be able to call the
    destructors of inherited classes through the ABC interface?

    >
    > > protected:

    >
    >
    > your data member should be private, not protected.
    >
    > > AnotherABC& _member;
    > > }


    Why? Must I use access methods in my derived classes when one of the
    main points of the ABC is to provide a generalized declaration for my
    data members in the class hierarchy? Is it inadvisable to have
    protected data at all?

    >
    >
    > > The idea is that my concrete classes will derive from ABC and set
    > > _member in their initialization lists to the specific type of
    > > AnotherABC that the particular class needs.

    >
    > Can't do that. Instead, ABC needs a (protected) constructor that sets
    > member, and the derived class can call that constructor.
    >
    > > However, this can't be done
    > > as the constructors of the derived classes complain about there being
    > > no default constructor for ABC.

    >
    > It won't if you follow the above advice.
    >
    > > Should I simply replace the reference with a const pointer, or should I
    > > rethink this and save myself from a potentially nasty design flaw? Is
    > > there a design pattern I could use here?

    >
    > I've given you code below:
    >
    > class Other;
    >
    > class Base {
    > Other& other_; // this is private
    > protected:
    > virtual ~Base() = 0;
    > Base(Other& o) : other_(o) {}
    > };
    >
    > Base::~Base() {}
    >
    > class Derived : public Base {
    > public:
    > Derived(Other& o) : Base(o) {}
    > };
    >
    > Best regards,
    >
    > Tom


    Thanks for your help, Tom. I hope my questions don't seem too stupid.
    , Dec 10, 2005
    #3
  4. On 10 Dec 2005 12:49:47 -0800, ""
    <> wrote:

    >I have an ABC with a protected member that is a reference to an object
    >of an ABC type:
    >
    >class ABC
    >{
    >public:
    > virtual ~ABC() = 0;
    >protected:
    > AnotherABC& _member;


    You shouldn't use names with a leading underscore for anything (see
    17.4.3.1.2 of the C++ standard).

    >}
    >
    >The idea is that my concrete classes will derive from ABC and set
    >_member in their initialization lists to the specific type of
    >AnotherABC that the particular class needs. However, this can't be done
    >as the constructors of the derived classes complain about there being
    >no default constructor for ABC.
    >
    >Should I simply replace the reference with a const pointer, or should I
    >rethink this and save myself from a potentially nasty design flaw? Is
    >there a design pattern I could use here?


    What Thomas said ... however, if the member is to be derived from ABC,
    you will probably want to store a reference to ABC and not AnotherABC,
    relying on the interface defined in ABC for whatever you need to do
    with it. As it is, you cannot initialize this member with an object of
    type YetAnotherABC, for example, even if that class also derives from
    ABC.

    --
    Bob Hairgrove
    Bob Hairgrove, Dec 10, 2005
    #4
  5. red floyd Guest

    wrote:
    > I have an ABC with a protected member that is a reference to an object
    > of an ABC type:
    >
    > class ABC
    > {
    > public:
    > virtual ~ABC() = 0;
    > protected:
    > AnotherABC& _member;
    > }
    >
    > The idea is that my concrete classes will derive from ABC and set
    > _member in their initialization lists to the specific type of
    > AnotherABC that the particular class needs. However, this can't be done
    > as the constructors of the derived classes complain about there being
    > no default constructor for ABC.
    >
    > Should I simply replace the reference with a const pointer, or should I
    > rethink this and save myself from a potentially nasty design flaw? Is
    > there a design pattern I could use here?
    >


    What's wrong with:

    class AnotherABC;
    class ABC
    {
    public:
    virtual ~ABC() = 0;
    protected:
    ABC(AnotherABC& param) : _member(param) { }
    AnotherABC& _member;
    };
    red floyd, Dec 10, 2005
    #5
  6. wrote:
    > Thomas Tutone wrote:
    > > wrote:
    > > > I have an ABC with a protected member that is a reference to an object
    > > > of an ABC type:
    > > >
    > > > class ABC
    > > > {
    > > > public:
    > > > virtual ~ABC() = 0;

    > >
    > > your destructor should be protected, not public.

    >
    > Why is that? I can understand the constructor being protected, but not
    > the destructor. Won't this mean that delete won't be able to call the
    > destructors of inherited classes through the ABC interface?


    Perhaps you are missing the point. ABC's destructor will never be
    called directly - because the destructor is virtual, it will be the
    destructor of the derived class that will be called, which will in turn
    call the base destructor. The derived destructor has access to the
    protected functions of its parent.

    > > > protected:

    > >
    > >
    > > your data member should be private, not protected.
    > >
    > > > AnotherABC& _member;
    > > > }

    >
    > Why? Must I use access methods in my derived classes when one of the
    > main points of the ABC is to provide a generalized declaration for my
    > data members in the class hierarchy?


    Typically, yes.

    > Is it inadvisable to have
    > protected data at all?


    Typically yes. To quote Stroustrup: "declaring data members protected
    is usually a design error." The C++ Programming Language (3rd ed.)
    sec. 15.3.1.1

    There are exceptions, but that's the usual rule. If your accessor is
    inline, there is typically no overhead to using the accessor.
    >
    > >
    > >
    > > > The idea is that my concrete classes will derive from ABC and set
    > > > _member in their initialization lists to the specific type of
    > > > AnotherABC that the particular class needs.

    > >
    > > Can't do that. Instead, ABC needs a (protected) constructor that sets
    > > member, and the derived class can call that constructor.
    > >
    > > > However, this can't be done
    > > > as the constructors of the derived classes complain about there being
    > > > no default constructor for ABC.

    > >
    > > It won't if you follow the above advice.
    > >
    > > > Should I simply replace the reference with a const pointer, or should I
    > > > rethink this and save myself from a potentially nasty design flaw? Is
    > > > there a design pattern I could use here?

    > >
    > > I've given you code below:
    > >
    > > class Other;
    > >
    > > class Base {
    > > Other& other_; // this is private
    > > protected:
    > > virtual ~Base() = 0;
    > > Base(Other& o) : other_(o) {}


    You are correct - you need an accessor here. E.g.:

    void doAction() { other.doAction(); }

    or

    const Other& other() const { return other_; }

    or whatever... It's not clear (to me, anyway) what you are trying to
    do.

    > > };
    > >
    > > Base::~Base() {}
    > >
    > > class Derived : public Base {
    > > public:
    > > Derived(Other& o) : Base(o) {}
    > > };
    > >


    > Thanks for your help, Tom. I hope my questions don't seem too stupid.


    You're welcome, and they're not stupid. You might consider picking up
    a copy of Effective C++ (3d ed.), which includes a lot of good advice.

    Best regards,

    Tom
    Thomas Tutone, Dec 10, 2005
    #6
  7. Guest

    Thomas Tutone wrote:
    > wrote:
    > > Thomas Tutone wrote:
    > > > wrote:
    > > > > I have an ABC with a protected member that is a reference to an object
    > > > > of an ABC type:
    > > > >
    > > > > class ABC
    > > > > {
    > > > > public:
    > > > > virtual ~ABC() = 0;
    > > >
    > > > your destructor should be protected, not public.

    > >
    > > Why is that? I can understand the constructor being protected, but not
    > > the destructor. Won't this mean that delete won't be able to call the
    > > destructors of inherited classes through the ABC interface?

    >
    > Perhaps you are missing the point. ABC's destructor will never be
    > called directly - because the destructor is virtual, it will be the
    > destructor of the derived class that will be called, which will in turn
    > call the base destructor. The derived destructor has access to the
    > protected functions of its parent.


    Okay, but I want to use ABC as an interface. For example:

    ABC* inst = new SomeDerivedClass();
    delete inst; // I can't delete it, ABC's destructor is protected

    I'm sure this isn't an unusual thing to do, which is why I don't
    understand having a protected destructor in ABC.
    , Dec 10, 2005
    #7
  8. On 10 Dec 2005 13:29:14 -0800, "Thomas Tutone"
    <> wrote:

    >Perhaps you are missing the point. ABC's destructor will never be
    >called directly - because the destructor is virtual, it will be the
    >destructor of the derived class that will be called, which will in turn
    >call the base destructor. The derived destructor has access to the
    >protected functions of its parent.


    This is not true. If the base class' destructor is protected, clients
    using the classes will not be able to call delete on a pointer to the
    base class. They will, however, be able to call delete on pointers to
    the derived classes.

    There are situations where this is the desired behavior, e.g. when a
    virtual destructor is not desirable or needed, as with private
    inheritance.

    --
    Bob Hairgrove
    Bob Hairgrove, Dec 10, 2005
    #8
  9. wrote:
    > Thomas Tutone wrote:
    > > wrote:
    > > > Thomas Tutone wrote:
    > > > > wrote:
    > > > > > I have an ABC with a protected member that is a reference to an object
    > > > > > of an ABC type:
    > > > > >
    > > > > > class ABC
    > > > > > {
    > > > > > public:
    > > > > > virtual ~ABC() = 0;
    > > > >
    > > > > your destructor should be protected, not public.
    > > >
    > > > Why is that? I can understand the constructor being protected, but not
    > > > the destructor. Won't this mean that delete won't be able to call the
    > > > destructors of inherited classes through the ABC interface?

    > >
    > > Perhaps you are missing the point. ABC's destructor will never be
    > > called directly - because the destructor is virtual, it will be the
    > > destructor of the derived class that will be called, which will in turn
    > > call the base destructor. The derived destructor has access to the
    > > protected functions of its parent.

    >
    > Okay, but I want to use ABC as an interface. For example:
    >
    > ABC* inst = new SomeDerivedClass();
    > delete inst; // I can't delete it, ABC's destructor is protected


    Not true. When you call "delete inst," what does the compiler insert
    code to do? Well, first, it calls the destructor for inst. Now inst is
    declared as a pointer to ABC. ABC has a virtual destructor. So
    instead of calling the destructor for an ABC, the compiler inserts code
    to call the destructor for SomeDerivedClass, which presumably has a
    _public_ destructor. SomeDerivedClass, in turn, calls ABC's
    destructor, which SomeDerivedClass is entitled to do, because its
    parent is ABC, and a derived class can call a protected function in its
    parent. So your example will work fine, nothwithstanding your comment.

    > I'm sure this isn't an unusual thing to do, which is why I don't
    > understand having a protected destructor in ABC.


    I hope this makes sense now. If it doesn't, you need to re-review the
    concept of virtual functions.

    Best regards,

    Tom
    Thomas Tutone, Dec 10, 2005
    #9
  10. Thomas Tutone wrote:
    > wrote:
    > > Thomas Tutone wrote:
    > > > wrote:
    > > > > Thomas Tutone wrote:
    > > > > > wrote:
    > > > > > > I have an ABC with a protected member that is a reference to an object
    > > > > > > of an ABC type:
    > > > > > >
    > > > > > > class ABC
    > > > > > > {
    > > > > > > public:
    > > > > > > virtual ~ABC() = 0;
    > > > > >
    > > > > > your destructor should be protected, not public.
    > > > >
    > > > > Why is that? I can understand the constructor being protected, but not
    > > > > the destructor. Won't this mean that delete won't be able to call the
    > > > > destructors of inherited classes through the ABC interface?
    > > >
    > > > Perhaps you are missing the point. ABC's destructor will never be
    > > > called directly - because the destructor is virtual, it will be the
    > > > destructor of the derived class that will be called, which will in turn
    > > > call the base destructor. The derived destructor has access to the
    > > > protected functions of its parent.

    > >
    > > Okay, but I want to use ABC as an interface. For example:
    > >
    > > ABC* inst = new SomeDerivedClass();
    > > delete inst; // I can't delete it, ABC's destructor is protected

    >
    > Not true. When you call "delete inst," what does the compiler insert
    > code to do? Well, first, it calls the destructor for inst. Now inst is
    > declared as a pointer to ABC. ABC has a virtual destructor. So
    > instead of calling the destructor for an ABC, the compiler inserts code
    > to call the destructor for SomeDerivedClass, which presumably has a
    > _public_ destructor. SomeDerivedClass, in turn, calls ABC's
    > destructor, which SomeDerivedClass is entitled to do, because its
    > parent is ABC, and a derived class can call a protected function in its
    > parent. So your example will work fine, nothwithstanding your comment.
    >


    You know what - I'm having a bad day. You are absolutely right and I
    am wrong. My apologies for confusing the issue. The destructor should
    indeed be public. Glad you're awake, even if I'm not.

    Best regards,

    Tom
    Thomas Tutone, Dec 10, 2005
    #10
  11. Guest

    red floyd wrote:
    > wrote:
    > > I have an ABC with a protected member that is a reference to an object
    > > of an ABC type:
    > >
    > > class ABC
    > > {
    > > public:
    > > virtual ~ABC() = 0;
    > > protected:
    > > AnotherABC& _member;
    > > }
    > >
    > > The idea is that my concrete classes will derive from ABC and set
    > > _member in their initialization lists to the specific type of
    > > AnotherABC that the particular class needs. However, this can't be done
    > > as the constructors of the derived classes complain about there being
    > > no default constructor for ABC.
    > >
    > > Should I simply replace the reference with a const pointer, or should I
    > > rethink this and save myself from a potentially nasty design flaw? Is
    > > there a design pattern I could use here?
    > >

    >
    > What's wrong with:
    >
    > class AnotherABC;
    > class ABC
    > {
    > public:
    > virtual ~ABC() = 0;
    > protected:
    > ABC(AnotherABC& param) : _member(param) { }
    > AnotherABC& _member;
    > };


    This is exactly what I came up with in the end (I realised this
    solution shortly after posting the original question).

    Implementation of this idea isn't now a problem, but I have become
    absolutely paranoid that I'm making a terrible design decision. I
    personally didn't think it was a big problem having protected data
    members - they're not public, after all.

    My goal in doing things this way is to get things declared as high up
    in the class hierarchy as possible. _member is going to exist in all
    derived classes - so the best plan of action in my eyes was to put it
    in the protected section of ABC rather than declare it as a private
    member in every derived class. Is this sane?
    , Dec 10, 2005
    #11
  12. Bob Hairgrove wrote:
    > On 10 Dec 2005 13:29:14 -0800, "Thomas Tutone"
    > <> wrote:
    >
    > >Perhaps you are missing the point. ABC's destructor will never be
    > >called directly - because the destructor is virtual, it will be the
    > >destructor of the derived class that will be called, which will in turn
    > >call the base destructor. The derived destructor has access to the
    > >protected functions of its parent.

    >
    > This is not true. If the base class' destructor is protected, clients
    > using the classes will not be able to call delete on a pointer to the
    > base class. They will, however, be able to call delete on pointers to
    > the derived classes.


    Yes - My answer was incorrect. Sorry about that.

    Best regards,

    Tom
    Thomas Tutone, Dec 10, 2005
    #12
  13. Bob Hairgrove wrote:
    > On 10 Dec 2005 12:49:47 -0800, ""
    > <> wrote:
    >
    > >I have an ABC with a protected member that is a reference to an object
    > >of an ABC type:
    > >
    > >class ABC
    > >{
    > >public:
    > > virtual ~ABC() = 0;
    > >protected:
    > > AnotherABC& _member;

    >
    > You shouldn't use names with a leading underscore for anything (see
    > 17.4.3.1.2 of the C++ standard).


    why not?

    one leading underscore followed by a lowercase letter is allowed for
    names anywhere but in global and std namespace. class members fall in
    neither category.

    -- peter
    peter steiner, Dec 10, 2005
    #13
  14. On 10 Dec 2005 13:54:09 -0800, ""
    <> wrote:

    >I personally didn't think it was a big problem having protected data
    >members - they're not public, after all.


    As long as you are the only developer working on your project, and you
    have control over all the code, it is not a problem. However, the
    minute more people have to maintain the project, you have what Bjarne
    Stroustrup refers to as a "maintenance nightmare" -- chasing down
    *all* possible inherited classes and making sure they do not abuse the
    protected members. And if they do, sometimes you cannot do anything
    about it unless the other developer is in agreement. And there will
    always be more classes the next week, or month...

    Better to do things right from the very beginning and keep *all* data
    members private.

    --
    Bob Hairgrove
    Bob Hairgrove, Dec 10, 2005
    #14
  15. peter steiner wrote:
    > Bob Hairgrove wrote:
    > >
    > > You shouldn't use names with a leading underscore for anything (see
    > > 17.4.3.1.2 of the C++ standard).

    >
    > why not?
    >
    > one leading underscore followed by a lowercase letter is allowed for
    > names anywhere but in global and std namespace. class members fall in
    > neither category.
    >


    Yes, it seems to be as you said. But I think the meaning of Standard is
    a bit disputable in this case:


    17.4.3.1.2 Global names
    1. Certain sets of names and function signatures are always reserved
    to the implementation:
    - Each name that contains a double underscore _ _ or begins with
    an underscore followed by an uppercase letter (2.11) is reserved to the
    implementation for any use.
    - Each name that begins with an underscore is reserved to the
    implementation for use as a name in the global namespace.


    Note, the only second part refers to global namespace.

    Cheers
    --
    Mateusz Loskot
    http://mateusz.loskot.net
    Mateusz Loskot, Dec 10, 2005
    #15
  16. On 10 Dec 2005 14:06:58 -0800, "peter steiner" <>
    wrote:

    >> You shouldn't use names with a leading underscore for anything (see
    >> 17.4.3.1.2 of the C++ standard).

    >
    >why not?
    >
    >one leading underscore followed by a lowercase letter is allowed for
    >names anywhere but in global and std namespace. class members fall in
    >neither category.


    Within class namespace, the global namespace is also visible ... it is
    always visible. The whole point is to prevent users of the
    implementation from declaring names which conflict with the names used
    by the implementation, which can be in the global namespace. You have
    no way of excluding those names.

    --
    Bob Hairgrove
    Bob Hairgrove, Dec 10, 2005
    #16
  17. Bob Hairgrove wrote:
    > On 10 Dec 2005 14:06:58 -0800, "peter steiner" <>
    > wrote:
    >
    > >> You shouldn't use names with a leading underscore for anything (see
    > >> 17.4.3.1.2 of the C++ standard).

    > >
    > >why not?
    > >
    > >one leading underscore followed by a lowercase letter is allowed for
    > >names anywhere but in global and std namespace. class members fall in
    > >neither category.

    >
    > Within class namespace, the global namespace is also visible ... it is
    > always visible. The whole point is to prevent users of the
    > implementation from declaring names which conflict with the names used
    > by the implementation, which can be in the global namespace. You have
    > no way of excluding those names.


    i stand corrected and enlightened. that should have been obvious, sorry
    for the hassle and confusion.

    -- peter
    peter steiner, Dec 10, 2005
    #17
  18. * Thomas Tutone:
    >
    > Bob Hairgrove wrote:
    > > On 10 Dec 2005 13:29:14 -0800, "Thomas Tutone"
    > > <> wrote:
    > >
    > > >Perhaps you are missing the point. ABC's destructor will never be
    > > >called directly - because the destructor is virtual, it will be the
    > > >destructor of the derived class that will be called, which will in turn
    > > >call the base destructor. The derived destructor has access to the
    > > >protected functions of its parent.

    > >
    > > This is not true. If the base class' destructor is protected, clients
    > > using the classes will not be able to call delete on a pointer to the
    > > base class. They will, however, be able to call delete on pointers to
    > > the derived classes.

    >
    > Yes - My answer was incorrect. Sorry about that.


    Well no. Your follow-up explanation was incorrect, but your original
    answer was just incomplete.

    Declaring the destructor protected in ABC is indeed a Good Thing To Do,
    because it means instances of the class _have_ to be dynamically
    allocated -- a standard compiler won't then allow anything else.

    Of course then the client code must be offered some means to deallocate.
    A bad way is to provide a delete-yourself public member function. A
    general and good way is to define a common destruction function

    template< typename T > callDelete( T* p ) { delete p; }

    and make that function (as well as std::auto_ptr) a friend of the class.

    As I understand Marshall Cline, this technique will be part of the FAQ
    item dealing with ensured dynamic allocation.

    Currently that FAQ item only mentions the named constructor idiom.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Dec 11, 2005
    #18
  19. Razzer Guest

    Mateusz Loskot wrote:
    > peter steiner wrote:
    > > Bob Hairgrove wrote:
    > > >
    > > > You shouldn't use names with a leading underscore for anything (see
    > > > 17.4.3.1.2 of the C++ standard).

    > >
    > > why not?
    > >
    > > one leading underscore followed by a lowercase letter is allowed for
    > > names anywhere but in global and std namespace. class members fall in
    > > neither category.
    > >

    >
    > Yes, it seems to be as you said. But I think the meaning of Standard is
    > a bit disputable in this case:
    >
    >
    > 17.4.3.1.2 Global names
    > 1. Certain sets of names and function signatures are always reserved
    > to the implementation:
    > - Each name that contains a double underscore _ _ or begins with
    > an underscore followed by an uppercase letter (2.11) is reserved to the
    > implementation for any use.
    > - Each name that begins with an underscore is reserved to the
    > implementation for use as a name in the global namespace.
    >
    >
    > Note, the only second part refers to global namespace.


    No. The meaning of the Standard is clear. You cannot use any identifier
    with a leading underscore as a name (in a declaration) when the thing
    declared is at the global (or std namespace) scope.

    >
    > Cheers
    > --
    > Mateusz Loskot
    > http://mateusz.loskot.net
    Razzer, Dec 11, 2005
    #19
  20. Razzer Guest

    Bob Hairgrove wrote:
    > On 10 Dec 2005 14:06:58 -0800, "peter steiner" <>
    > wrote:
    >
    > >> You shouldn't use names with a leading underscore for anything (see
    > >> 17.4.3.1.2 of the C++ standard).

    > >
    > >why not?
    > >
    > >one leading underscore followed by a lowercase letter is allowed for
    > >names anywhere but in global and std namespace. class members fall in
    > >neither category.

    >
    > Within class namespace, the global namespace is also visible ... it is
    > always visible. The whole point is to prevent users of the
    > implementation from declaring names which conflict with the names used
    > by the implementation, which can be in the global namespace. You have
    > no way of excluding those names.


    The visibility of the object is of no concern. All that matters is if
    it uses double-underscore or an underscore followed by a capital letter
    at any scope or a single underscore at global scope.

    See:
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndeepc/html/deep04202000.asp

    >
    > --
    > Bob Hairgrove
    >
    Razzer, Dec 11, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Roger Leigh
    Replies:
    8
    Views:
    434
    Karl Heinz Buchegger
    Nov 17, 2003
  2. Patrick
    Replies:
    4
    Views:
    360
    Patrick
    Feb 26, 2004
  3. Replies:
    3
    Views:
    447
    Victor Bazarov
    Nov 10, 2004
  4. Tony Johansson

    override when using object composition

    Tony Johansson, Sep 3, 2005, in forum: C++
    Replies:
    1
    Views:
    264
    John Harrison
    Sep 3, 2005
  5. Nick Valeontis

    references and composition

    Nick Valeontis, Nov 9, 2009, in forum: C++
    Replies:
    4
    Views:
    310
Loading...

Share This Page