A couple of newbie QT questions

[fishing_boat]

Hi, I was looking at QT as a cross-platform language to use and I had a couple questions/concerns I couldn't find answers to online.

1. I heard from a friend's friend (info is a bit sketch) that we couldn't inherit or override anything. This seems false as from what I've seen you can inherit and create custom widgets. So are there restrictions on inheriting/overriding at all? Are there specific classes/widgets that we're not allowed to extend?

2. I'd like to know if there are a lot of debugging issues involved with multiple platform deployment (sorta like Java's write once debug everywhere..). I haven't found any posts really relating to this issue or going in depth, so I'd like to hear from those who've actually deployed to multiple platforms (actually just OSX/Linux - I'm planning to develop in Windows).


Thanks in advance!

[squidge]

Qt isn't a cross-platform language. It's a cross-platform framework. Underneath it's all C++, so of course you can inherit and override things as you wish, in fact, this is how a lot of the functionality is obtained. You take a standard component (say, a QTextEdit), modify it to suit by creating your own class, inheriting QTextEdit, and overriding various methods.

Debugging is the same - if you can debug your C++ code already, you can debug your Qt framework code. The only added extra is a "Debugging helper" that gives more meaningful information about some of the classes such as QString.

[fishing_boat]

Bad use of language; I know it's all C++ under. It's just that I'm was concerned about what I heard and wasn't sure if there were any classes that Trolltech made un-inheritable or if they simply disallow inheritance for specific classes. Good to know that's not the case.

As for debugging, mostly I mean like it works on Windows XP say, but then some weird behaviour pops up as I run it on Ubuntu or OSX. Happens on Java, but that might be because I have to compile it on different platforms itself and their compiler's aren't exactly the same.

[ChrisW67]

1. I heard from a friend's friend (info is a bit sketch) that we couldn't inherit or override anything. This seems false as from what I've seen you can inherit and create custom widgets. So are there restrictions on inheriting/overriding at all? Are there specific classes/widgets that we're not allowed to extend?

Inheritance works, it's just C++. There are some restrictions in the case of multiple inheritance where ancestor classes are derived from QObject. Only one ancestor can be derived from QObject, and it must be listed first in the class definition. I've never run foul of this restriction... perhaps others here have?

[fishing_boat]

I'm a bit muddy on LGPL. I know that I can release my software close-source, and need to link dynamically and that if I change anything in QT itself I need to release that.

However this is a bit confusing to me:

"The LGPL contains no special provisions for inheritance, because none are needed. Inheritance creates derivative works in the same way as traditional linking, and the LGPL permits this type of derivative work in the same way as it permits ordinary function calls"

It says it's similar to traditional linking (statically right?) which I can't do if I want my code to be close-sourced; then it says it permits this like ordinary function calls which implies that we can use it without open-sourcing.

So if I do extend a QT object but I don't add it to the QT library (ie it's part of my code), do I need to open-source?

[squidge]

No, as your not modifying the Qt source code. Secondly, if you read the Nokia exception license (not the LGPL license) you get the additional rights of being able include material from header files, and so derive from that material. You also get other rights which you probably don't care about at the moment, but sometimes will be useful.

[axeljaeger]

One more thing about inheritance: In Java, you cannot override a method that was marked as "final". So the default is that you can override a method. In C++, it is the other way around: To mark a method as overwriteable you have to mark it as "virtual". You can only override the methods from Qt that nokia marked virtual. Sometimes people argue that there is not enough virtual methods in Qt but I have not seen any limitations here. It is just another theory how people come to conclusions like your fellow there.

[fishing_boat]

I know it's bad, but are we forbidden by Nokia from redefining an inherited non-virtual function? (I'm not going to do it, just curious)

[wysota]

No, Nokia doesn't forbid you from redefining non-virtual functions. But your C++ knowledge should tell you it doesn't make much sense to reimplement non-virtual methods.

[axeljaeger]

You are not forbidden to do that. C++ usually allows you to shot yourself in the foot. It just will not work as expected so you should only do it if you know what you are doing.

Is there any conrete example where you would need that? If you need it, you very likely try to use the API in a wrong way.

[frog]

I got an example where simple inheritance constraint is a pain.
I m working on a Network module.

I want to design a client and and server class.
The first could derive from QTcpSocket and the second from QTcpServer but I'd like those two classes to share base attributes and methods.

are mysimple class definitions

class someclass ;
class base 
{
public: 
 base ():someattribute(){}
~  base(){}
someclass someattribute;
};
class client : public QTcpSocket, public base
{
Q_OBJECT
public: 
client (QOject *o):QTcpSocket(o),base(){}
~ client (){}
 
};
class server : public QTcpServer, public base
{
Q_OBJECT
public:
server  (QOject *o): QTcpServer(o),base(){}
~ server (){}
};

class someclass ;
class base 
{
public: 
 base ():someattribute(){}
~  base(){}
someclass someattribute;
};
class client : public QTcpSocket, public base
{
Q_OBJECT
public: 
client (QOject *o):QTcpSocket(o),base(){}
~ client (){}

};
class server : public QTcpServer, public base
{
Q_OBJECT
public:
server  (QOject *o): QTcpServer(o),base(){}
~ server (){}
};

To copy to clipboard, switch view to plain text mode 

while this C++ quite acceptable moc compiler get stuck and require base class to be an QObject.
If the base class becomes a QOject such as

class base : public virtual QOject
{
Q_OBJECT
public: 
 base (QOject *o):QOject(o),someattribute(){}
~  base(){}
someclass someattribute;
};

class base : public virtual QOject
{
Q_OBJECT
public: 
 base (QOject *o):QOject(o),someattribute(){}
~  base(){}
someclass someattribute;
};

To copy to clipboard, switch view to plain text mode 

there are ambiguities @ compilation time that the compiler can't resolve.

[fishing_boat]

Nonono. For sure I'm not going to be doing that; just curious about what Nokia does or does not enforce.

Thanks for the feedback.

[axeljaeger]

You would usually not inherit the sockets but have a class and the sockets as member.

[squidge]

I know it's bad, but are we forbidden by Nokia from redefining an inherited non-virtual function? (I'm not going to do it, just curious)

Think about it for a minute. If you have a base class BC and you inherit from it and call it IC, and then override non-virtual function F. What will happen?

BC *base = new IC();
IC *iclass = new IC();

base->F(); // Calls the original function
iclass->F(); // Calls your overridden function

Now, if we make F virtual, F() will always call your overridden function regardless. Therefore it doesn't make sense to override a function that isn't virtual, unless you are only ever going to call it through your inherited class type, rather than the base class type. Even then, it just means confusion, as you could have some code calling the Qt function, and some calling your function. Lots of fun with the debugger will begin.

Nokia will not hunt you down for doing the above.

[fishing_boat]

I know how virtual/non-virtual works in C++... just curious about what Nokia allows.

[squidge]

They'll come down on you hard if you put there code in your own software and make it closed source without a commercial license, unless that code has been excluded by the Nokia exception license included with Qt. It's really that simple. Including headers for the purpose of using and inheriting from Qt objects is one such exemption.

Have you read the Nokia exception license?

[fishing_boat]

I've read the licensing information at http://qt.nokia.com/products/licensing and the LGPL (tried to at least, some of that licencing stuff is confusing). I don't think that's what you're talking about though, are you talking about the bottom of "http://qt.nokia.com/doc/4.6/lgpl.html"?

I don't think I'll be statically linking anything or copy+pasting their code into mine if that's what you mean. by "put their code in your own software".

[squidge]

The Nokia exception license is different depending on if you use 4.5 (where its V1.0) or 4.6 (V1.1).

The 1.0 version for QT4.5 and earlier goes like this:

Nokia Qt LGPL Exception version 1.0

As a special exception to the GNU Lesser General Public License
version 2.1, the object code form of a "work that uses the Library"
may incorporate material from a header file that is part of the
Library. You may distribute such object code under terms of your
choice, provided that the incorporated material (i) does not exceed
more than 5% of the total size of the Library; and (ii) is limited to
numerical parameters, data structure layouts, accessors, macros,
inline functions and templates.

Whereas the V1.1 version for Qt 4.6 is:

Nokia Qt LGPL Exception version 1.1

As an additional permission to the GNU Lesser General Public License version
2.1, the object code form of a "work that uses the Library" may incorporate
material from a header file that is part of the Library. You may distribute
such object code under terms of your choice, provided that:
(i) the header files of the Library have not been modified; and
(ii) the incorporated material is limited to numerical parameters, data
structure layouts, accessors, macros, inline functions and
templates; and
(iii) you comply with the terms of Section 6 of the GNU Lesser General
Public License version 2.1.

Moreover, you may apply this exception to a modified version of the Library,
provided that such modification does not involve copying material from the
Library into the modified Library's header files unless such material is
limited to (i) numerical parameters; (ii) data structure layouts;
(iii) accessors; and (iv) small macros, templates and inline functions of
five lines or less in length.

Furthermore, you are not required to apply this additional permission to a
modified version of the Library.

Both can be found in the LGPL_EXCEPTION file in the same directory as the other license documents.