«

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

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

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

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++?

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.

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 :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

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.

> 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.

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.

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.