CopperSpice Forum

Posted: **Tue Sep 01 2020 12:15 pm**

Perhaps I'm just having a brain fart? Perhaps I had a brain fart the other day when I left a comment in the code that sent me down this path this morning.

Given all of the changes when forking from Qt, do all of the containers provide parentage? The documentation is not clear. If most things are now wrappers for STL implementations which have no concept of parentage, then I have to ask . . . do all of these containers assume parentage of the objects they contain? No exceptions, no gotcha's, no "on Thursdays when it rains and Fred's at the keyboard" situations.

I had a comment a comment in the Diamond code near a section like this

Code: Select all

    if ( m_settings.m_options.preloadClipper() )
    {
        fileName = m_settings.syntaxPath() + "syn_clipper.json";
        m_syntaxPatterns[fileName] = new SyntaxPatterns( fileName );
    }

Wondering if I could still be certain the "new SyntaxPatters()" object would be parented by the QMap m_syntaxPatters. Not as straight forward as it sounds because SyntaxPatterns is a gadget.

Code: Select all

class SyntaxPatterns
{
    CS_GADGET( SyntaxPatterns )

public:
    SyntaxPatterns( QString fileName );
    SyntaxPatterns( const SyntaxPatterns &patterns );

    SyntaxPatterns &operator = ( const SyntaxPatterns &other );

    QStringList key_Patterns;
    QStringList class_Patterns;
    QStringList func_Patterns;
    QStringList type_Patterns;
    QStringList constant_Patterns;
    QString commentSingle;
    QString commentStart;
    QString commentEnd;
    QString pattern_file;
    bool ignoreCase;

private:
    QByteArray readSyntaxFile();

};

I decided to dig into this comment when I discovered my non-parented QObject based singleton class Overlord wasn't getting its destructor called on the way out. I don't remember seeing that before. I seem to always remember that as long as it was a QObject based object, parented or not, as long as it was created _after_ QApplication it got cleaned up on the way out the door. Perhaps I just have faulty memory?

Anyway, I would like some clarification/documentation on this issue.

Thank you.

Posted: **Wed Sep 02 2020 4:52 pm**

If most things are now wrappers for STL implementations

Just to clarify, every container in CopperSpice was redesigned to wrap (using composition) an existing container in the STL. We also split up the QMap and QHash containers into four containers QMap, QMultimap, QHash, and QMultiHash. Using hand rolled containers at this point in the development of C++ is not advisable. For example, using a "range based for loop" with a copy on write container can be very expensive. We also have the advantage that accessing a container does not require thread synchronization.

We support both the STL and Qt API so very little code needs to be changed when migrating and the learning curve is reduced.

To answer your question about ownership, the rules are the exact same in CopperSpice as it was in Qt. Nothing has changed since containers never participate in QObject ownership.

The way it works is as follows:

Parented QObject instances are destroyed by their parent
Unparented QObject instances are not destroyed by anyone, you must call QObject::deleteLater()
At the end of the program, static Singleton instances should be destroyed in program shutdown

Posted: **Thu Sep 03 2020 12:13 am**

Thank you for your response. I was specifically wondering about QGagets.

CS_GADGET( Themes )

Actually, more than wondering a bit about this

declared in class header

Code: Select all

QMap <QString, Themes> m_themes;

in class source

Code: Select all

Themes *theme = new Themes( lst[fld++].trimmed(), true ); // name

// do some stuff to fill this in

m_themes[theme->name()] = *theme;
delete theme;

Never messed much with Gadgets. They don't require or appear to support a parent. The QMap has a solid copy of a dynamically allocated object which has been deleted. I know it is actually making a copy because this stuff all works. You can visit my repo and pull down the diamond-themes branch to verify for yourself if you wish.

https://github.com/RolandHughes/diamond

Yeah, I know, I should store the pointer and leave the dynamic one alive. It was much easier to deal with a solid object. For various reasons I had to make several of these data classes Gadgets instead of full QObjects. Tired now and don't remember what all of the reasons were. I've been at this for quite a while. After this weekend I hope to be grovelling for a pull request to get Diamond rolled in.

Of course, if I decide to find out what the real answer is here I will have to spend a few weeks getting Valgrind to run on Diamond.

CopperSpice Forum

Containers and parentage

Containers and parentage

Re: Containers and parentage

Re: Containers and parentage