performance of pointers in class

Discussion in 'C++' started by jayden.shui@gmail.com, Dec 11, 2012.

  1. Guest

    Dear All,

    I see many codes, especially GUI codes with pointers in class, for example

    class MainWindow
    {
    private:
    Dialog *m_dialog1;
    Dialog *m_dialog2;
    Menu *m_menu;
    ToolBar *m_toolBar;
    TreeCtrl *m_treeCtrl;
    ...
    }

    My questions is that why not just use the object itself, like

    class MainWindow
    {
    private:
    Dialog m_dialog1;
    Dialog m_dialog2;
    Menu m_menu;
    ToolBar m_toolBar;
    TreeCtrl m_treeCtrl;
    ...
    }

    Any advantages and disadvantages for using pointers in the class? (performance, memory and so on)

    Thank you so much and best regards,

    Jayden
     
    , Dec 11, 2012
    #1
    1. Advertising

  2. On 12/11/2012 1:15 PM, wrote:
    > I see many codes, especially GUI codes with pointers in class, for example
    >
    > class MainWindow
    > {
    > private:
    > Dialog *m_dialog1;
    > Dialog *m_dialog2;
    > Menu *m_menu;
    > ToolBar *m_toolBar;
    > TreeCtrl *m_treeCtrl;
    > ...
    > }
    >
    > My questions is that why not just use the object itself, like
    >
    > class MainWindow
    > {
    > private:
    > Dialog m_dialog1;
    > Dialog m_dialog2;
    > Menu m_menu;
    > ToolBar m_toolBar;
    > TreeCtrl m_treeCtrl;
    > ...
    > }
    >
    > Any advantages and disadvantages for using pointers in the class? (performance, memory and so on)


    Generally speaking the use of pointers is recommended where there is
    either a possibility to refer to different objects during the lifetime
    of the 'MainWindow', or where the pointed-to object may not exist (i.e.
    the pointer is allowed to be NULL). Lazy allocation of dynamic memory
    is actually a combination of the two concepts; in that case we only
    allocate a 'ToolBar' (for example) when we need it, and not right away
    when we construct a 'MainWindow'.

    V
    --
    I do not respond to top-posted replies, please don't ask
     
    Victor Bazarov, Dec 11, 2012
    #2
    1. Advertising

  3. Ian Collins Guest

    wrote:
    > Dear All,
    >
    > I see many codes, especially GUI codes with pointers in class, for example
    >
    > class MainWindow
    > {
    > private:
    > Dialog *m_dialog1;
    > Dialog *m_dialog2;
    > Menu *m_menu;
    > ToolBar *m_toolBar;
    > TreeCtrl *m_treeCtrl;
    > ...
    > }
    >
    > My questions is that why not just use the object itself, like
    >
    > class MainWindow
    > {
    > private:
    > Dialog m_dialog1;
    > Dialog m_dialog2;
    > Menu m_menu;
    > ToolBar m_toolBar;
    > TreeCtrl m_treeCtrl;
    > ...
    > }
    >
    > Any advantages and disadvantages for using pointers in the class? (performance, memory and so on)


    There are many reasons why pointers are used in GUI component class and
    most GUI component librarians I've used use the pointer model.
    Sometimes not all the member objects are required (may be null) in every
    container instance. Another reason may be the pointer types (such as
    Menu) in your example will be base classes and the user may initialise
    the window object with derived types.

    Also consider the complexity of your MainWindow constructor if all of
    the contained object constructor parameters had to be passed! It's
    common practice to build the window components and then pass then to the
    main window type instance. Otherwise the main window type would have to
    have member functions to manipulate each of its contained types.

    --
    Ian Collins
     
    Ian Collins, Dec 11, 2012
    #3
  4. Öö Tiib Guest

    On Tuesday, 11 December 2012 23:34:30 UTC+2, Scott Lurndal wrote:
    > Paavo Helde <> writes:
    > >Performance and memory are not an issue unless there are zillions of
    > >objects.

    >
    > I don't see how the number of objects has any bearing on pointer-vs-reference.


    Then you did not read OP's question nor Paavo's answer. It was NOT
    pointer-vs-reference situation at all. It was pointer data member vs
    direct data member.


    > Ignore blanket statements like "don't use pointers in C++".


    There are indeed quite few reasonable usages for raw pointer data member
    in C++ language left, sorry.

    Reasonable is to do like that:
    1) When you do not need optionality or polymorphism of a component
    then use direct member, it is most efficient.
    2) When you need optionality or polymorphism of component then use
    std::unique_ptr. It is lot less error-prone than pointer while
    efficiency is about same.
    3) When the member is meant as a reference back to whole inside
    component then use (guess what?) a reference.
    4) When it is aggregate (not component) then depending on situation
    either std::unique_ptr or std::shared_ptr fit best for the task.
    5) When the member is for some weaker, non-owning relation with
    something then std::weak_ptr fits best for that.
    6) When the relation is one-to-many then choose best fitting
    container for that.

    So can you tell what is the relation for what a raw pointer data
    member is reasonable representation in current C++?
     
    Öö Tiib, Dec 12, 2012
    #4
  5. Guest

    On Tuesday, December 11, 2012 7:15:13 PM UTC+1, Jayden wrote:
    > Dear All,
    >
    >
    >
    > I see many codes, especially GUI codes with pointers in class, for example
    >
    >
    >
    > class MainWindow
    >
    > {
    >
    > private:
    >
    > Dialog *m_dialog1;
    >
    > Dialog *m_dialog2;
    >
    > Menu *m_menu;
    >
    > ToolBar *m_toolBar;
    >
    > TreeCtrl *m_treeCtrl;
    >
    > ...
    >
    > }
    >
    >
    >
    > My questions is that why not just use the object itself, like
    >
    >
    >
    > class MainWindow
    >
    > {
    >
    > private:
    >
    > Dialog m_dialog1;
    >
    > Dialog m_dialog2;
    >
    > Menu m_menu;
    >
    > ToolBar m_toolBar;
    >
    > TreeCtrl m_treeCtrl;
    >
    > ...
    >
    > }


    When it comes to UI toolkits, some of them are somewhat opinionated on teh lifetime of UI widgets. In particular, there's toolkits (or parts thereof) who kinda insist on UI widgets being deleted automatically when underlying system resources get freed. In those cases, if you want to have a referenceto some UI elements in a "containing" widget, you're obliged to use pointers. (But I would argue that in those cases you can just as well use facilities to go from underlying system's representation of a widget, e.g. a handle, to a corresponding C++ object instance).

    Another reason (more general) to have a pointer is that you want to "replace" one of those objects, but they aren't copiable (in particular, C++ representations of UI widgets often aren't). You are, therefore, obliged to freethe "old" one and put a "new-ed" one in it's place.

    And, of course, what Victor said about NULL (although, UI widgets often have "not created" state, where C++ object exists, but has no underlying "system resource").

    Goran.
     
    , Dec 12, 2012
    #5
  6. Scott Lurndal <> wrote:
    > Paavo Helde <> writes:
    >
    >> In general, using pointers makes the code more complex and error-prone.

    >
    > In general, generalizing about the use of pointers is complex and error-prone.
    >
    >> One should try to avoid them if possible.

    >
    > Not true at all.
    >
    >> Sometimes this is not possible,
    >> for example if the actual type of objects is not known at compile time
    >> (polymorphic objects) or the information needed for construction the
    >> subobjects is not available at the time of construction of the host
    >> object.
    >>
    >> Performance and memory are not an issue unless there are zillions of
    >> objects.

    >
    > I don't see how the number of objects has any bearing on pointer-vs-reference.


    Noone was talking about pointer vs reference. The discussion was about
    dynamic vs automatic allocation.

    > The number of objects is the same regardless of how they are accessed.


    It's not about how they are accessed, but about how they are created and
    destroyed.

    > The number of objects only has an effect on performance if the memory space
    > the objects reside in is constrained (i.e. one begins to page objects out
    > to make room for others).


    There is certainly a difference between one single big allocation for a
    compound object vs several small allocations for each subobject.
    If the objects are small (and pointers generally getting larger), this is
    especially true.

    > This is true regardless of pointer or reference to object.
    >
    >> Using pointers usually means some performance loss because of
    >> dynamic allocation and indirect access overhead

    >
    > This exhibits a lack of understanding of the underlying processor; whether the
    > object is accessed via a "C++ Reference" or via a "Pointer", the generated
    > code will be usually identical. Particularly in RISC systems. There are some cases
    > where pointer-based access _may_ result in an extra instruction when compared
    > to a reference, but only on CISC architectures where non-load-store instructions
    > allow direct access to memory ; even in this case, the overhead will be subsumed
    > by noise and won't be measurable.


    The point is not reference vs pointers, but direct access vs indirect
    access (pointer or reference).
    Direct object access also permits more optimizations (like inlining)
    because the dynamic type of the object is always identical to the static
    type.

    > Yes, there is some (quite minor, often O(1)) overhead for allocation and
    > deallocation.


    And this is exactly the point. It is usually O(1) regarding the size of the
    allocated memory for one call. But it's O(n) regarding the number of
    allocations.
    This means, the size of the objects does not matter, the number of
    allocations does.
    Also, the asymptotical performance with respect to the allocation size is
    not really relevant, since C++ objects don't tend to be that large. The
    constant factor will dominate and it is certainly not neglectable for
    dynamic allocation.

    > On the other hand, using dynamic allocations (in conjunction with lookaside lists
    > and ::eek:perator new) can often result in better cache locality and higher L1/2/3
    > cache hit rates for certain algorithms due to the ability of the application
    > programmer to control memory placement.


    I really doubt that it's often. For general purpose programming the
    locality provided by direct members is probably almost always the best you
    can get. And it's for free, no custom allocators or obscure new operators
    needed.

    > Use what makes sense for your application.
    >
    > Ignore blanket statements like "don't use pointers in C++".


    Agreed.

    Tobi
     
    Tobias Müller, Dec 12, 2012
    #6
  7. Nobody Guest

    On Tue, 11 Dec 2012 10:15:13 -0800, jayden.shui wrote:

    > I see many codes, especially GUI codes with pointers in class, for example


    > My questions is that why not just use the object itself, like


    For many GUI toolkits, the only way to create a "widget" is to call a
    function which returns a pointer. And the objects often do not support
    copying (either the type is incomplete, in which case dereferencing
    will generate a compile-time error, or the copy may simply not work
    correctly, or at all).

    The reasons why GUI toolkits might work like this are many, but
    irrelevant to your question; if it's not possible to get anything other
    than a pointer, the application has to use pointers.
     
    Nobody, Dec 12, 2012
    #7
  8. Guest

    > Any advantages and disadvantages for using pointers in the class? (performance, memory and so on)

    Generally, I always go for direct objects and stack allocation unless thereis a specific reason I need a pointer. Before calling new or malloc(), make sure there at least one good reason why. Otherwise, don't. Why add the complexity of memory management if you don't have to?

    You might need a pointer because the object has virtual functions. A pointer might be the only way the library containing the object allows you to construct instances through some factory. There might also be multiple top level objects owning one instance of the inner object, which again requires pointers or some other equivalent such as smart pointers.

    There are some downsides to containing pointers. First there is the error prone nature of cleaning up your allocations that we all know and love/hate.If you are creating a performance critical application, accessing lots of small objects allocated randomly on the heap will cause a lot of cache misses. You want things laid out linearly in memory if at all possible and direct object containment is one way to do that. Lots of small allocations and deallocations can also fragment the heap, making it look like you have lessmemory available then there actually is.
     
    , Dec 16, 2012
    #8
  9. Guest

    On Tuesday, December 11, 2012 1:15:13 PM UTC-5, Jayden wrote:
    > Any advantages and disadvantages for using pointers in the class? (performance, memory and so on)



    Generally, I always go for direct objects and stack allocation unless there
    is a specific reason I need a pointer. Before calling new or malloc(),
    make sure there at least one good reason why. Otherwise, don't. Why add
    the complexity of memory management if you don't have to?

    You might need a pointer because the object has virtual functions. A pointer
    might be the only way the library containing the object allows you to construct
    instances through some factory. There might also be multiple top level objects
    owning one instance of the inner object, which again requires pointers or some
    other equivalent such as smart pointers.

    There are some downsides to containing pointers. First there is the error prone
    nature of cleaning up your allocations that we all know and love/hate. If you
    are creating a performance critical application, accessing lots of small
    objects allocated randomly on the heap will cause a lot of cache misses. You
    want things laid out linearly in memory if at all possible and direct object
    containment is one way to do that. Lots of small allocations and deallocations
    can also fragment the heap, making it look like you have less memory available
    then there actually is.
     
    , Dec 16, 2012
    #9
  10. Balog Pal Guest

    On 12/11/2012 7:15 PM, wrote:
    > I see many codes, especially GUI codes with pointers in class, for example
    >
    > class MainWindow
    > {
    > private:
    > Dialog *m_dialog1;
    > Dialog *m_dialog2;
    > Menu *m_menu;
    > ToolBar *m_toolBar;
    > TreeCtrl *m_treeCtrl;
    > ...
    > }


    My guess would be that the GUI framework used forces or encourages this way.

    > My questions is that why not just use the object itself, like
    >
    > class MainWindow
    > {
    > private:
    > Dialog m_dialog1;
    > Dialog m_dialog2;
    > Menu m_menu;
    > ToolBar m_toolBar;
    > TreeCtrl m_treeCtrl;
    > ...
    > }


    If you used say MFC, the code would look like this. As uses 2-phase
    init. When you actually create the UI dialog, you issue
    m_dialog1.Create() that will do all the magic and store the handle.


    Other frameworks may go for one-phase init, so you use pointer (possibly
    a smart one), and spell m_pDialog1 = new FooDialog(...);

    > Any advantages and disadvantages for using pointers in the class? (performance, memory and so on)


    Non-smart pointers can create many problems, especially if they are
    "owned", as I'd expect here. If replaces with suitable smart pointers
    the difference is pretty light and irrelevant -- compared to general
    performance of the framework's design.
     
    Balog Pal, Dec 16, 2012
    #10
    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. E11
    Replies:
    1
    Views:
    4,955
    Thomas Weidenfeller
    Oct 12, 2005
  2. Phil
    Replies:
    1
    Views:
    675
    llewelly
    Sep 16, 2003
  3. muser
    Replies:
    3
    Views:
    785
    Ron Natalie
    Sep 18, 2003
  4. A
    Replies:
    3
    Views:
    481
    Alan Kelon
    Oct 29, 2003
  5. cerr

    pointers, pointers, pointers...

    cerr, Apr 7, 2011, in forum: C Programming
    Replies:
    12
    Views:
    739
Loading...

Share This Page