Subclassing QString to add more functionality?

Question

Trying to add functionality to QString but get build errors ?? And if I am missing things??

#ifndef CSTRING_H
#define CSTRING_H

#include <QString>
#include <QStringList>
#include <QObject>


class CString : public QString, public QObject
{
    Q_OBJECT
public:
    explicit CString(QObject *parent = 0);
    QStringList Find(QString qstrSearch);//all occurances

signals:

public slots:

};

#endif // CSTRING_H

#include "cstring.h"

CString::CString(QObject *parent) :
    QString(parent)     //ERROR IS POINTING TO HERE
{
}


QStringList Find(QString qstrSearch)//all occurances
{//indexOf, contains
    QStringList qstrList;



    return qstrList;
}

Build error

Subclassing QString is a bad idea -- QString does not have a virtual destructor, and QStrings get passed by value a lot which means you are likely to get bit by object slicing. A better approach would be to create free functions instead (i.e. not member functions, just functions that take and/or return QString objects) — Jeremy Friesner, Aug 05 '13 at 23:57
The immediate cause of the error: `QString` is not derived from `QObject` and doesn't have a constructor that takes `QObject*`, so don't try to initialize it with one. I concur with Jeremy Friesner - QString is not designed to be derived from. You want to reconsider your design. — Igor Tandetnik, Aug 06 '13 at 00:15

score 2 · Answer 1 · answered Aug 06 '13 at 05:03

2

QString(parent) Qstring does not have a constructor taking a QObject-parent as parameter. Therefor the compiler tries to cast your QObject to closest Matching constructor, which probably would be QString ( QChar ch )

answered Aug 06 '13 at 05:03

Sebastian Lange

3,879
1
19
38

SpongeBobFan · Answer 2 · 2013-08-06T08:15:33.360

2

You should use composition instead of inheritance here, because QString is not designed for subclassing. You can get a lot of troubles if you will subclass it.
Do something like this:

class CString : public QObject //if you're really need this class to be QObject, that's not always a good idea
{
    Q_OBJECT
public:
    explicit CString(QObject *parent = 0) : 
        QObject(parent), 
        mString() //QString have no constructors with parameter QObject*...
    {
    }

private:
    QString mString;
}

Of course, implementation should be in cpp file, it's just a short example

edited Aug 06 '13 at 08:15

answered Aug 06 '13 at 07:08

SpongeBobFan

964
5
13

Why would you store a ``QString*``, and not a simple ``QString``? – Marc Plano-Lesay Aug 06 '13 at 07:22
You can store either `QString*` or `QString`, it doesn't matter. Or have I missed something? – SpongeBobFan Aug 06 '13 at 08:09
Well, you can. But I can't see any reason to use a pointer here, and you'll have to explicitely handle copies, deletion, ... – Marc Plano-Lesay Aug 06 '13 at 08:11
I think you're right, using pointer here is not a good idea, edited answer – SpongeBobFan Aug 06 '13 at 08:16
-1: this is very bad advice, your `CString` class doesn't behave like any string (in particular a QString) at all, so don't try to pretend it does by giving it a misleading name. – Frerich Raabe Aug 06 '13 at 08:23
Sorry for misleading name, just used the name author used in his code. Subclassing `QString` is worse anyway – SpongeBobFan Aug 06 '13 at 08:35

score 2 · Accepted Answer · answered Aug 06 '13 at 08:21

Don't derive classes form QString since it wasn't designed with polymorphy in mind (note that it has no virtual methods, in particular no virtual destructors) If you want to provide new utility functions, just use free functions - you may want to put them in a namespace:

namespace CString {
    QStringList find(const QString &search);
}

Subclassing QString to add more functionality?

3 Answers3