Pointer Vs non-pointer member variable

Discussion in 'C++' started by ittium, Jun 27, 2011.

  1. ittium

    ittium Guest

    Group,
    Are there any guidelines regarding, choosing pointer vs non-pointer
    member variables for a class
    thanks
    Ittium
    ittium, Jun 27, 2011
    #1
    1. Advertising

  2. On 6/27/2011 10:12 AM, ittium wrote:
    > Are there any guidelines regarding, choosing pointer vs non-pointer
    > member variables for a class


    Yes, I am sure you can find hundreds of "guidelines" of that sort. Most
    likely they are going to be tied to "associativity" and "containment"
    relationships. Learn about those, and you can write your own "guidelines".

    V
    --
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Jun 27, 2011
    #2
    1. Advertising

  3. ittium

    Jorgen Grahn Guest

    On Mon, 2011-06-27, ittium wrote:
    > Group,
    > Are there any guidelines regarding, choosing pointer vs non-pointer
    > member variables for a class


    Use non-pointer unless you have a reason not to.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Jun 27, 2011
    #3
  4. On 27 Jun., ittium wrote:
    > Group,
    > Are there any guidelines regarding, choosing pointer vs non-pointer
    > member variables for a class
    > thanks
    > Ittium


    That's easy: Always choose non-pointer if possible.

    Note that there are few cases where you have to use pointer, for
    example if the object that is pointed to is managed by a different
    class:

    class Application
    {
    public:
    void DoSomething ();
    };

    class SomeClass
    {
    private:
    Application* App_;

    public:
    SomeClass (Application* App)
    : App_ (App)
    {}

    void foo ()
    {
    App_->DoSomething ();
    }
    };

    Here SomeClass uses a plain pointer to the Application class since
    this class is created and managed by some third entity.

    Another case is when the member is managed by the class itself but
    cannot be created in the constructor of the class. In that scenario
    you are forced to use pointers. However, you should use some smart
    pointer:

    class Slave
    {};

    class Master
    {
    public:
    Master ();
    void Initialize ()
    {
    Slave_ = std::auto_ptr<Slave> (new Slave ());
    }

    private:
    std::auto_ptr<Slave> Slave_;
    };

    In this case the life-time of Slave_ will be a subset of the life-time
    of Master.

    Regards,
    Stuart
    Stuart Redmann, Jun 30, 2011
    #4
  5. ittium

    SG Guest

    On 27 Jun., 16:25, Victor Bazarov <> wrote:
    > On 6/27/2011 10:12 AM, ittium wrote:
    >
    > > Are there any guidelines regarding, choosing pointer vs non-pointer
    > > member variables for a class

    >
    > Yes, I am sure you can find hundreds of "guidelines" of that sort.  Most
    > likely they are going to be tied to "associativity" and "containment"
    > relationships.  Learn about those, [...]


    Richt. There are many different ways of how some inter-object
    relationship can be implemented:

    class sub {...};
    class foo1 { sub real_sub_object; ... };
    class foo2 { sub* stupid_pointer; ... };
    class foo3 { vector<sub> vect; ... };
    class foo4 { unique_ptr<sub> up; ... };
    ...

    Especially in the presence of neat little building blocks like
    standard containers and unique_ptr I think the number of good reasons
    why somebody should implement an "is-part-of" or "is-made-up-out-of"
    relationship (containment) with a raw pointer (see foo2) is
    approaching zero. A raw pointer basically means association. If you
    want to use raw pointers to model containment you also have to
    "override" the class' default copy semantics by providing custom or
    explicitly disabling copy ctor, assignment operator and dtor. IMHO,
    it's best to avoid it if possible. Let other, smaller building blocks
    handle all the necessary management or use the objects as "real data
    members" in these cases.

    Cheers!
    SG
    SG, Jun 30, 2011
    #5
  6. ittium

    Fred Guest

    On Jun 27, 12:42 pm, Jorgen Grahn <> wrote:
    > On Mon, 2011-06-27, ittium wrote:
    > > Group,
    > > Are there any guidelines regarding, choosing pointer vs non-pointer
    > > member variables for a class

    >
    > Use non-pointer unless you have a reason not to.
    >


    I tend to do the opposite - use pointer unless you have a reason not
    to.

    For example:
    MyClass.h:
    // Using non-pointer

    #include Other.h
    class MyClass {
    public:
    Other myOther;
    // etc.
    };

    // Using pointer

    class Other;
    class MyClass {
    public:
    Other *myOther;
    // etc.
    };

    Now if MyClass.h is included in a lot of other files,
    using the non-pointer version will cause all of those
    files to be re-compiled whenever there is a change to
    Other.h (assuming you have the correct dependencies
    specified in your Makefile).

    Using the pointer version, only MyClass.C will be
    re-compiled when Other.h changes - there will not be
    any re-compiles of the files including MyClass.h unless
    they also include Other.h separately.

    --
    Fred K
    Fred, Jun 30, 2011
    #6
  7. Fred <> writes:

    > I tend to do the opposite - use pointer unless you have a reason not
    > to.

    [...]
    > Now if MyClass.h is included in a lot of other files, using the
    > non-pointer version will cause all of those files to be re-compiled
    > whenever there is a change to Other.h (assuming you have the correct
    > dependencies specified in your Makefile).
    >
    > Using the pointer version, only MyClass.C will be re-compiled when
    > Other.h changes - there will not be any re-compiles of the files
    > including MyClass.h unless they also include Other.h separately.


    Designing your data model to optimize the behavior of the tools you use
    is an strange strategy (and I doubt you'll save a lot of compile time,
    but this depends on your code). The difference between embedding and
    pointing to is not purely cosmetic.

    Another real problem with this is that the systematic use of pointers
    brings C++ to the level of Java from the point of view of data locality,
    fragmenting memory as much as possible, and probably adds tons of
    indirections in the resulting binary, forbiding many optimizations
    because of the ensuing potential aliasing between pointers. Slowdown,
    code bloat.

    I really can't see any real benefit to your "trick". You're basically
    wrecking your design and sabotaging the work of the compiler.

    -- Alain.
    Alain Ketterlin, Jul 1, 2011
    #7
  8. ittium

    Jorgen Grahn Guest

    On Thu, 2011-06-30, Fred wrote:
    > On Jun 27, 12:42 pm, Jorgen Grahn <> wrote:
    >> On Mon, 2011-06-27, ittium wrote:
    >> > Group,
    >> > Are there any guidelines regarding, choosing pointer vs non-pointer
    >> > member variables for a class

    >>
    >> Use non-pointer unless you have a reason not to.
    >>

    >
    > I tend to do the opposite - use pointer unless you have a reason not
    > to.
    >
    > For example:
    > MyClass.h:
    > // Using non-pointer
    >
    > #include Other.h
    > class MyClass {
    > public:


    You mean private, right?

    > Other myOther;
    > // etc.
    > };
    >
    > // Using pointer
    >
    > class Other;
    > class MyClass {
    > public:
    > Other *myOther;
    > // etc.


    Here you also have to add constructors, destructors etc -- things
    which were not needed in the first version.

    > };
    >
    > Now if MyClass.h is included in a lot of other files,
    > using the non-pointer version will cause all of those
    > files to be re-compiled whenever there is a change to
    > Other.h


    Not enough reason IMHO. But I do something like this if Other.h is
    very dirty and would pull in lots of macros and cruft, like some Unix
    system include files.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
    Jorgen Grahn, Jul 1, 2011
    #8
    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. slide_o_mix
    Replies:
    0
    Views:
    420
    slide_o_mix
    Oct 15, 2003
  2. Alex
    Replies:
    0
    Views:
    393
  3. Fraser Ross
    Replies:
    4
    Views:
    1,043
    Fraser Ross
    Aug 14, 2004
  4. Stephen Howe
    Replies:
    2
    Views:
    287
    Stephen Howe
    Nov 6, 2012
  5. somenath
    Replies:
    10
    Views:
    279
    James Kanze
    Jul 2, 2013
Loading...

Share This Page