QObject and copy Constructors

[December]

Hi all,

I am trying to get my head around the model/view way of programming. I am making a simple example using my own class, and have run into a problem. My own class is very simple at this stage, since I'm just trying to get it to work:



class VfAlert : public QObject
{
Q_OBJECT

public:
VfAlert( QObject *parent = 0 ) : QObject( parent ) {}
VfAlert( const VfAlert &alert );
QString title;
};

class VfAlertListModel : public QAbstractListModel
{
Q_OBJECT

public:
VfAlertListModel( const QList<VfAlert> &alerts, QObject *parent = 0 )
: QAbstractListModel(parent), alertList(alerts) {}

// int rowCount(const QModelIndex &parent = QModelIndex()) const;
// QVariant data(const QModelIndex &index, int role) const;
// QVariant headerData(int section, Qt::Orientation orientation,
// int role = Qt::DisplayRole) const;

private:
QList<VfAlert> alertList;
};


and the copy constructor for VfAlert:



VfAlert::VfAlert( const VfAlert &alert )
{
title = alert.title;

};

I had to add the copy constructor because without it, it wouldn't compile.

Now it compiles ok, but I get this warning:


warning: base class 'class QObject' should be explicitly initialized in the copy constructor

That sounds pretty serious, so I'm guessing I shouldn't ignore it, but can't get my head around what exactly I should be doing with a QObject in the copy constructor :eek:

Any ideas?

Thanks

[awhite1159]

QObject does not support copying. It's copy constructor is not public.

[caduel]

And your class does not need to derive from QObject anyway, does it?

(If you have classes that do have to derive from QObject, you can (must) store pointers (preferably smart ones, imho) in a QList.

HTH

PS: To be on the safe side: you must not use smart pointers like boost::shared_ptr for objects that are owned by another QObject (parent*). Otherwise it might get deleted twice... which causes quite a bit of fun.

[wysota]

Your copy constructor doesn't do anything an implicit copy constructor wouldn't do, by the way, so you might not implement it at all (of course if QObject allowed copying, which it does not).

[December]

Thanks for all the responses. the easy solution was not to dervice from QObject. I had planned to use some signals in that vlass, but can re-do the logic to go without.

I didn't know QObjects don't have public copy constructors, never run across that before.

My copy constructor will do lots more later (this was just to get the concept working, not the actual class that will be in the final code) so I can't really do without it.

Got rid of the QObject and it's fine now :)

[wysota]

Thanks for all the responses. the easy solution was not to dervice from QObject. I had planned to use some signals in that vlass, but can re-do the logic to go without.

You can change the design from isA to hasA (I mean have a member variable that is a [pointer to] QObject).