Qt-interest Archive, May 2007
Qt 4.x classes implementation question
Message 1 in thread
Hi, there:
I browsed a bit the Qt source code and I noticed that in Qt 4.x lots of
classes have a private class member with the name d which is usually a
pointer to an object of class <class name of d>Private. These private
classes seem to contain data but they can contain other methods as well. The
other normal class methods make intense use of this object data members or
methods.
Now, I don't understand WHY the classes have been implemented this way!? Is
it done on purpose? It makes extending Qt classes almost impossible if not
completely impossible because the logic uses so much the d member which is
private and a derived class doesn't have access to it.
I recently tried to extend the odbc driver (qsql_odbc.cpp). It is
impossible! The only choice left is to create another sql driver, copy and
paste the code from the existing one and then change it.
Am I missing something?
Thanks
--
[ signature omitted ]
Message 2 in thread
Well. The reason is for binary compatibility...
Once the API is locked for a major + minor version (4.1, 4.2 etc) they
cant change (as in add, remove or modify) a classes methods without
breaking it...
This allows for any 4.2 version to be run and allows for plugins etc to
be distributed without concern for the actual QT...
However, I find in practice, you are correct... it makes deriving from
the non-item classes tough.
Quite often, TT is VERY good about the hidden class using the public API
for just that reason, but all too often, they forget and use the private
classes API directly..
I think TT may be seeing the limit of their binary compatibility as
well... Just some food for thought... It seems that they are breaking
binary compat much more often and having to rev the minor number....
Just a view...
I had hit the same thing many times in 3.X but much less in 4.X since
they came out with the Model-View world...
Scott
> -----Original Message-----
> From: B.C. [mailto:bikerc@xxxxxxxxx]
> Sent: Monday, April 30, 2007 8:54 PM
> To: qt-interest@xxxxxxxxxxxxx
> Subject: Qt 4.x classes implementation question
>
> Hi, there:
>
> I browsed a bit the Qt source code and I noticed that in Qt 4.x lots
of
> classes have a private class member with the name d which is usually a
> pointer to an object of class <class name of d>Private. These private
> classes seem to contain data but they can contain other methods as
well.
> The
> other normal class methods make intense use of this object data
members or
> methods.
>
> Now, I don't understand WHY the classes have been implemented this
way!?
> Is
> it done on purpose? It makes extending Qt classes almost impossible if
not
> completely impossible because the logic uses so much the d member
which is
> private and a derived class doesn't have access to it.
>
> I recently tried to extend the odbc driver (qsql_odbc.cpp). It is
> impossible! The only choice left is to create another sql driver, copy
and
> paste the code from the existing one and then change it.
>
> Am I missing something?
>
>
> Thanks
>
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
Message 3 in thread
On 30.04.07 21:42:07, Scott Aron Bloom wrote:
> Well. The reason is for binary compatibility...
>
> Once the API is locked for a major + minor version (4.1, 4.2 etc) they
> cant change (as in add, remove or modify) a classes methods without
> breaking it...
Just a short note: This is not the full truth. There's a page on
techbase.kde.org that explains what exactly one can change in a Class
without breaking BC. For example you can add functions that are
non-virtual.
Andreas
--
[ signature omitted ]
Message 4 in thread
Hi,
> I think TT may be seeing the limit of their binary compatibility as
> well... Just some food for thought... It seems that they are breaking
> binary compat much more often and having to rev the minor number....
Why do you say binary compatibility has been broken very often? This has never
been the case in Qt 4 as far as I know.
--
[ signature omitted ]
Message 5 in thread
Hi,
> I think TT may be seeing the limit of their binary compatibility as
> well... Just some food for thought... It seems that they are breaking
> binary compat much more often and having to rev the minor number....
Why do you say binary compatibility has been broken very often? This has never
been the case in Qt 4 as far as I know.
---------------
Sorry... my grammer may not of been clear... I dont think they have broken binary comap according to the rules of all 4.2.X must be bin compat, and the same for 4.1.X and now 4.3.X
However, what I ment, is base on what I see in 4.3, the "new" functionality is limited, however, a lot of bugs have been fixed. But in order to fix them properly, TT has to break bin compat, and thus cant make 4.3.1, 4.2.4.
That does not mean there is not new functionality... just that based on what I saw in the 3.X releases, their lifespan was longer, but the fixes in the 4.X line are forcing minor version revs more often to MAINTAIN the bin compat rules.
Scott
--
[ signature omitted ]
Message 6 in thread
Hi,
> Sorry... my grammer may not of been clear... I dont think they have broken binary comap according to the rules of all 4.2.X must be bin compat, and the same for 4.1.X and now 4.3.X
>
> However, what I ment, is base on what I see in 4.3, the "new" functionality is limited, however, a lot of bugs have been fixed. But in order to fix them properly, TT has to break bin compat, and thus cant make 4.3.1, 4.2.4.
>
> That does not mean there is not new functionality... just that based on what I saw in the 3.X releases, their lifespan was longer, but the fixes in the 4.X line are forcing minor version revs more often to MAINTAIN the bin compat rules.
Ah, I see what you mean.
Here are approximate release dates based on the date of the open-source Qt/X11
tarballs on the Trolltech FTP server:
Qt 3.0.0 2001-10-15
Qt 3.1.0 2002-11-12
Qt 3.2.0 2003-07-22
Qt 3.3.0 2004-02-04
Qt 4.0.0 2005-06-27
Qt 4.1.0 2005-12-19
Qt 4.2.0 2006-10-04
Qt 4.3.0 2007-...
It's true Qt 4.1.0 was released quite soon after Qt 4.0.0. Other than that
there's no real shift in Qt releases. In any case I don't think this is
directly related to binary compatibility issues. Rather, new functionality is
added to Qt more often based on customer wishes (although I know some
customers would rather like more stability and bug-fixing than more new
functionality as already expressed on this mailing list).
Why do you think "new" functionality in Qt 4.3.0 is limited compared to
previous releases? There are improvements such as :
Vista style
QtScript
new QMdiArea class
new QSslSocket class
...
and I don't see they're less important than improvements brought by Qt 4.2 or
Qt 4.1.
I'm not saying bug fixing is never taken into account when deciding to bump
the minor version, but I certainly do not think bug fixing is the driving
force behind minor Qt releases.
--
[ signature omitted ]
Message 7 in thread
Wow.. I guess I feel the fool... It just felt that I was on 3.x lines for a lot longer (I started on 3.0) but it appears tht 8-14 months is pretty standard...
And Im not counting the 4.1 release as that was a clear anomoly...
Though when I looked at the 4.3 list of code, most of it appeard to be prtty "bug fix ish" with new classes to support that bug fix... Is the new QMdiArea is a replacement, with out much added value (still no tabs at the top, but it will be easier to add them) then the current QWorkspace.
Scott
________________________________
From: Dimitri [mailto:dimitri@xxxxxxxxxxxxx]
Sent: Tue 5/1/2007 11:08 AM
To: qt-interest@xxxxxxxxxxxxx
Subject: Re: Qt 4.x classes implementation question
Hi,
> Sorry... my grammer may not of been clear... I dont think they have broken binary comap according to the rules of all 4.2.X must be bin compat, and the same for 4.1.X and now 4.3.X
>
> However, what I ment, is base on what I see in 4.3, the "new" functionality is limited, however, a lot of bugs have been fixed. But in order to fix them properly, TT has to break bin compat, and thus cant make 4.3.1, 4.2.4.
>
> That does not mean there is not new functionality... just that based on what I saw in the 3.X releases, their lifespan was longer, but the fixes in the 4.X line are forcing minor version revs more often to MAINTAIN the bin compat rules.
Ah, I see what you mean.
Here are approximate release dates based on the date of the open-source Qt/X11
tarballs on the Trolltech FTP server:
Qt 3.0.0 2001-10-15
Qt 3.1.0 2002-11-12
Qt 3.2.0 2003-07-22
Qt 3.3.0 2004-02-04
Qt 4.0.0 2005-06-27
Qt 4.1.0 2005-12-19
Qt 4.2.0 2006-10-04
Qt 4.3.0 2007-...
It's true Qt 4.1.0 was released quite soon after Qt 4.0.0. Other than that
there's no real shift in Qt releases. In any case I don't think this is
directly related to binary compatibility issues. Rather, new functionality is
added to Qt more often based on customer wishes (although I know some
customers would rather like more stability and bug-fixing than more new
functionality as already expressed on this mailing list).
Why do you think "new" functionality in Qt 4.3.0 is limited compared to
previous releases? There are improvements such as :
Vista style
QtScript
new QMdiArea class
new QSslSocket class
...
and I don't see they're less important than improvements brought by Qt 4.2 or
Qt 4.1.
I'm not saying bug fixing is never taken into account when deciding to bump
the minor version, but I certainly do not think bug fixing is the driving
force behind minor Qt releases.
--
[ signature omitted ]
Message 8 in thread
This is well known idiom called "pimple". Google for details, but in
short it has several properties:
1. Faster compilation because the headers files got less dependencies
and includes.
2. Binary compatibility - data members can be added and removed,
without changing public class's size.
3. Hiding implementation details and cleaning up interface headers -
the public header files got clearer, because they contain less
implementation-specific stuff.
4. Gives implicit and explicit sharing and COW almost at no price.
5. Introduces some overhead - all data access get another indirection
level, plus every instance of the object requires a dynamic
allocation.
On 5/1/07, B.C. <bikerc@xxxxxxxxx> wrote:
> Hi, there:
>
> I browsed a bit the Qt source code and I noticed that in Qt 4.x lots of
> classes have a private class member with the name d which is usually a
> pointer to an object of class <class name of d>Private. These private
> classes seem to contain data but they can contain other methods as well. The
> other normal class methods make intense use of this object data members or
> methods.
>
> Now, I don't understand WHY the classes have been implemented this way!? Is
> it done on purpose? It makes extending Qt classes almost impossible if not
> completely impossible because the logic uses so much the d member which is
> private and a derived class doesn't have access to it.
>
> I recently tried to extend the odbc driver (qsql_odbc.cpp). It is
> impossible! The only choice left is to create another sql driver, copy and
> paste the code from the existing one and then change it.
>
> Am I missing something?
>
>
> Thanks
>
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
--
[ signature omitted ]
