ansaurus

Question

in Qt we uses more pointers, is there any advantages?

Answer 1

+3 A:

Looks like it's safe to do stack allocation. See this answer. In the case of Symbian, it might differ, though. This question brings up some good points.

I think with Symbian, you have a limited stack space, and many of the objects themselves use data sharing which is allocated on the heap anyway. In that regard, it might be a good idea to keep doing it dynamically.

SB 2010-08-17 13:53:00

it's safe, but it's usually not what you want. The widget will be destroyed immediately when leaving the block. Exceptions are QDialogs brought up with exec() (which blocks).

Frank 2010-08-17 17:00:08

Answer 2

+3 A:

QListView* newlist = new QListView(); //This is good? if so why?

Only if you store the newlist pointer somewhere and delete it manually later.

If possible, I would suggest allocating you widgets on the stack. This is not possible, however, when using the technique I'm about to explain.

When designing complex widgets you would normally create an object tree of widgets. Meaning that every widget, except for the root widget, has a parent. When a parent is deleted, it will automatically delete all its children. This method is very convenient because you will only need to keep track of the root widget.

In your case, you'd do something like this:

QListView* newlist = new QListView(parentWidget);

Job 2010-08-17 14:03:44

Answer 3

+2 A:

See my my reply about QObjects. In short: One creates widgets on the heap, as they usually must survive the current method, and they cannot be assigned nor copied. QWidgets delete their children when they themselves are deleted (or more general, QObjects delete their children), so there is usually no memory management problem if you pass a parent to the widget.

Frank 2010-08-17 14:31:03

@frank, Thanks for the answer. one thing i am not getting in your description is "they cannot be assigned nor copied"what does it exactly tells, cant we assign values, cant we copy them using copy constructors ?

Shadow 2010-08-18 05:14:47

@Shadow: Neither, both the copy ctor and operator= are private for QObjects. That's why they are passed around as pointers. QObjects aren't values, they have an "identity". Even if you implement e.g. operator= for a subclass, assigning one QObject to another breaks the semantics. E.g., the signal/slot connections are not copied.

Frank 2010-08-18 06:19:37

@Frabk, i analyzed http://doc.trolltech.com/4.5/shared.html#overview here carefully, i found one more doubt. QPixmap p1, p2; p1.load("image.bmp"); p2 = p1; // p1 and p2 share datahere p2 and p1 are shared from Qt prospective but not from the programmer prospective right. in General assigning one object to another leads to deep-copy right? but Qt says it will be shallow copy.. what if i change value of p2 here?

Shadow 2010-08-18 06:22:49

@Frabik, Sorry to disturb you again, i want to clarify this concept so i'm bugging.. Hey one more thing "signal/slot connections are not copied" what it tells, you mean assigning one signal to another? i have never done till now

Shadow 2010-08-18 06:32:55

@Shadow: No, it means, if you add a public copy constructor or assign operator to your own QObject subclass (you shouldn't), and do MyQObject b = a;. The signal/slot connections a is involved in won't be copied. And signal/slots are the major reason to derive from QObject in the first place.

Frank 2010-08-19 07:21:13

@Shadow: re deep copy: Qt often uses implicit sharing, i.e. copy-on-write. That means the objects share the same data until one of the copies gets modified. It then "detaches" from the shared data, copying the shared data and modifying its own copy. So the behavior to the user is like its copied, thus *implicit* sharing. That's used for the containers and for QPixmap and QImage, for example.

Frank 2010-08-19 07:28:07

Thanks for the clarification Frank.. Thanks lot :)

Shadow 2010-08-19 09:12:58

ansaurus

tags:

views:

answers:

in Qt we uses more pointers, is there any advantages?

related questions