2

I'm having troubles choosing the best solution to my problems. Currently, I'm working on my first C++ project, I'm using Qt BTW, but because I'm a .NET developer, there are some things that bit me concerning C++ :). As you all know, in a gargage collected world, such as Java or .NET, best practice is to use Dependency Injection for loose coupling classes, making it more testable and maintenable, but I have no idea what to do in C++. C++ doesn't have a GC, so we should take care about every memory allocation and that causes too much questions.

For example, I have a class "Rule", which has a member field pointing to "Application" class:

class Rule : public QObject
{
public:
    explicit Rule(QObject *parent = 0);

    unsigned int id();
    void setId(unsigned int id);

    Application* application();
    void setApplication(Application* application)
    {
        m_Application = application
        m_Application->setParent(this);
    }

};

In the constructor, I'm assigning NULL to application instance variable. In setApplication, I'm assigning this as the parent to application. Application instance will be deleted automatically when Rule (the parent) is destroyed, thanks to Qt. Is this a good approach? would it be better if I used smart pointer such as QSharedPointer instead of Application*? What's your experience, what's the drawbacks, what's the best approach. I would gladly listen to your advices. Also there is another tricky part here. What if I gave that class to another developer in the team, or I published the library. The developer could easily write something like:

Application app;
app.setId(1);
Rule rule;
rule.setApplication(&app); //When rule will be destroyed, the program would crash because app is allocated on the stack.

or

Application *app = new Application();
app->setId(20);
Rule *rule = new Rule();
rule->setApplication(app);
Application *appToAnotherLocation = new Application();
rule->setApplication(appToAnotherLocation); // This wouldn't result in memory leak, because app is already child of rule, but if I didn't used Qt this would be a problem... probably :)

Now what about smart pointers? Is there some rules, when we should use them and when we shouldn't? I have a IRepository interface, which always returns QSharedObject instead of pointers. Is this a good approach or am I overusing it?

class IRepository
{
public:
    virtual bool save(Application & application) = 0;
    virtual bool save(Rule & rule) = 0;
    virtual bool save(History & history) = 0;

    virtual bool remove(Application & application) = 0;
    virtual bool remove(Rule & rule) = 0;
    virtual bool remove(History & history) = 0;

    virtual QSharedPointer<Application> getApplication(unsigned int id) = 0;

    virtual QSharedPointer<Rule> getRule(unsigned int id) = 0;
    virtual QList< QSharedPointer<Rule> > getRules(unsigned int applicationId) = 0;

    virtual QSharedPointer<History> getHistory(unsigned int id) = 0;
    virtual QList< QSharedPointer<History> > getHistories(unsigned int applicationId) = 0;
    virtual QList< QSharedPointer<History> > getHistories(unsigned int applicationId, QDateTime dateFrom, QDateTime dateTo) = 0;
};

Thanks. Your help is much appreciated.

Davita
  • 8,928
  • 14
  • 67
  • 119
  • Your example is missing pointers (`*` in declaration is for pointers). btw qt applications have memory management of it's own – BЈовић Nov 06 '11 at 19:28
  • 1
    In general, smart pointers are good, see this description about [RAII](http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization). – Chris O Nov 06 '11 at 19:28
  • 1
    Use smart pointers to express ownership. A raw pointer implies ownership is managed somewhere else. You should almost never use the delete keyword. – Alan Stokes Nov 06 '11 at 19:55

2 Answers2

1

Subjective opinion;

First: like Chris said, smart pointer are a very good alternative for memory leaks. Try always to use them.

Second: a good design approach is to delete pointers only in creators. I mean, one class creates and destroys their pointers. Don't delete pointers in another classes, this will allows you to have more clear, readable and maintainable code.

In your example, Rule 'must' not delete Application pointer. Think about your design: I don't understand why a Rule is an Application parent. I suppose that an Application may work with a lot of rules.

Tio Pepe
  • 3,071
  • 1
  • 17
  • 22
1

As mentionedby others, use smart pointers to express ownership. When using Qt you should read up on Memory management in Qt?

Community
  • 1
  • 1
larsmoa
  • 12,604
  • 8
  • 62
  • 85