[Solved] Basic QIODevice subclass in Qt4

giesbert

Hi Paucoma,

Q_OBJECT macro is needed, if this class uses signal slot, but my implementation has not signal/slot, no properties. So only the base classes have signal/slot and those have the macros, that's fine. But I add it, for completeness.

I removed the explicit for the constructor, and set the parent to 0. Two constructors makes no sense, as this device always needs an underlying device. The class en/decrypts data and stores it in the underlying device. Sure you can argue, otherwise you can open/close the device, change the underlying device by a method and open again, yes, but it's a code snippet, a description on how to implement a custom IO device.

andre

Note that the Q_OBJECT macro has more uses than just signal/slot. It also is needed for introspection and things like qobject_cast<>(). That may or may not be nessecairy, but I think it is good practice to include Q_OBJECT by default for QObject derived classes.

paucoma

Hi Gerolf!

Even though the custom IODevice, CryptDevice, does not implement signals and slots itself, it is a class derived from QIODevice which does provide signals, such as:

void aboutToClose ()
void bytesWritten ( qint64 bytes )
void readChannelFinished ()
void readyRead ()

To be able to use these signals from a CryptDevice Object is Q_OBJECT necessary in the definition of CryptDevice? or since QIODevice already declares it, it is not needed.

Your right, it doesn't make much sense to provide a seperate constructor.

I have been reading a bit on the explicit keyword and believe I understand that:

removing the explicit would now allow you to do
@
QBuffer bufferUsedLikeAFile(&dataArray);
SimpleCryptDevice deviceFilter = &bufferUsedLikeAFile;
@
before, with the explicit keyword, it would have thrown a compile error.

andre

[quote author="paucoma" date="1300957763"]Even though the custom IODevice, CryptDevice, does not implement signals and slots itself, it is a class derived from QIODevice which does provide signals, such as:

void aboutToClose ()
void bytesWritten ( qint64 bytes )
void readChannelFinished ()
void readyRead ()

To be able to use these signals from a CryptDevice Object is Q_OBJECT necessary in the definition of CryptDevice? or since QIODevice already declares it, it is not needed.
[/quote]

It is not needed for signals and slots provided by a base class. There are, however, other reasons why you might want to include Q_OBJECT.

paucoma

Thanks Andre for the clarification.

giesbert

bq. To be able to use these signals from a CryptDevice Object is Q_OBJECT necessary in the definition of CryptDevice? or since QIODevice already declares it, it is not needed.

You can use signals and slots from base classes without the Q_OBJECT macro in CryptDevice. But as Andre mentions, there is more (like qobject_cast) that also relies on the meta object system. so now it is added.

@
QBuffer bufferUsedLikeAFile(&dataArray);
SimpleCryptDevice deviceFilter = &bufferUsedLikeAFile;
@

This should not be possible, as QObject assignement is a bad idea. So I also added QBuffer Q_DISABLE_COPY(CryptDevice) to the class. Now, no assignment or copy constructor is possible.

Explicit means it can't be used indirectly for conversion. So I reach the same by using Q_DISABLE_COPY. Explicit makes sense only for one parameter constructors, and the c'tor was changed to two parameters, so it made no sense anymore.

paucoma

Quote from one of the articles I read about the explicit keyword:

"Explicit Constructor in C++ By Mridula":http://www.go4expert.com/forums/showthread.php?t=20756

bq. But explicit on a constructor with multiple arguments has no effect, since such constructors cannot take part in implicit conversions. However, explicit will have an effect if a constructor has multiple arguments and all but one of the arguments has a default value.

Which would be the case since the QObject defaults to 0, right?

giesbert

But it had 2 parameters without default:

@
explicit CryptDevice(QIODevice* deviceToUse, QObject* parent);
@

andre

Normally in Qt, the parent parameter actually defaults 0. Perhaps that should be the case here too:

@
CryptDevice(QIODevice* deviceToUse, QObject* parent = 0);
@

However, even then, I think explicit is not needed. What would potentially be cast to QIODevice* that would not be a valid argument?

giesbert

That's the difference in time :-)

it already is, but the explicit was before the code of the c'tor was changed, and there the C'tor did not default it (in fact between I had 2 c'tors, that's why it couldn't default).

Now we only have one c'tor which has a parent by default 0.

code from above:

@
QBuffer bufferUsedLikeAFile(&dataArray);
SimpleCryptDevice deviceFilter = &bufferUsedLikeAFile;
@

This code could result in a copy constructor / assignment operator call, depending on the compiler. It might be optimized. Both is not allowed for QObjects.

paucoma

Lets see if I understand then:
if we were to define the constructor as explicit:
@
explicit CryptDevice(QIODevice* deviceToUse, QObject* parent=0);
@
@
QIODevice dev;
QIODevice pdev;
CryptDevice cdev_1(&dev); //call to explicit constructor
CryptDevice cdev_2(pdev); //call to explicit constructor
CryptDevice cdev_3(dev); //illegal! -> compiler error (expecting QIODevice)
CryptDevice cdev_4(cdev_1); //call to compiler generated copy constructor
CryptDevice cdev_5 = cdev_1; //call to compiler generated copy constructor
CryptDevice cdev_6 = &dev; //illegal -> compiler error (expecting CryptDevice)
@

[quote] Q_DISABLE_COPY(CryptDevice) to the class. Now, no assignment or copy constructor is possible.[/quote]

@
Q_DISABLE_COPY(CryptDevice)
CryptDevice(QIODevice* deviceToUse, QObject* parent=0);
@
@
QIODevice dev;
QIODevice *pdev;
CryptDevice cdev_1(&dev); //call to constructor
CryptDevice cdev_2(pdev); //call to constructor
CryptDevice cdev_3(dev); // will it try type conversion?
CryptDevice cdev_4(cdev_1); //illegal -> Copy disabled
CryptDevice cdev_5 = cdev_1; //illegal -> operator= disabled
CryptDevice cdev_6 = &dev; //illegal -> operator= disabled
@

Or have I just gotten completly lost...

giesbert

Hi Pau,

I copied your entry and fixed the comments:

if we were to define the constructor as explicit:
@
explicit CryptDevice(QIODevice* deviceToUse, QObject* parent=0);
@
@
QIODevice dev;
QIODevice *pdev;

CryptDevice cdev_1(&dev); //call to explicit constructor
CryptDevice cdev_2(pdev); //call to explicit constructor
CryptDevice cdev_3(dev); //illegal! -> compiler error (expecting QIODevice*)
CryptDevice cdev_4(cdev_1); //call to compiler generated copy constructor --> will not work, as QIODevice has Q_DISABLE_COPY
CryptDevice cdev_5 = cdev_1; //call to compiler generated copy constructor --> will not work, as QIODevice has Q_DISABLE_COPY
CryptDevice cdev_6 = &dev; //illegal -> compiler error (expecting CryptDevice)
@

[quote] Q_DISABLE_COPY(CryptDevice) to the class. Now, no assignment or copy constructor is possible.[/quote]

@
Q_DISABLE_COPY(CryptDevice)
CryptDevice(QIODevice* deviceToUse, QObject* parent=0);
@
@
QIODevice dev;
QIODevice pdev;
CryptDevice cdev_1(&dev); //call to constructor
CryptDevice cdev_2(pdev); //call to constructor
CryptDevice cdev_3(dev); // illegal! -> compiler error (expecting QIODevice)
CryptDevice cdev_4(cdev_1); //illegal -> Copy disabled
CryptDevice cdev_5 = cdev_1; //illegal -> operator= disabled
CryptDevice cdev_6 = &dev; //illegal -> operator= disabled
@

Or have I just gotten completly lost...

paucoma

Hi Gerolf: thanks for fixing the comments.
In the first section I am suposing we dont declare the macro Q_DISABLE_COPY(CryptDevice)

In that case, will the compiler automatically generate a copy constructor?
** If so, are the following legal?
*** CryptDevice cdev_4(cdev_1);
*** CryptDevice cdev_5 = cdev_1;

giesbert

it will try to create it, but it will automatically call the base copy c'tor, which is private --> compiler error

paucoma

Thanks for that clarification, when I try these things I don't know about, I get errors, and it is sometimes hard to understand what the error means, you guys here are really helping me understand whats happening, I'm greatfull! :)

P.S. I need to read more carefully, sorry.. you did do the correct assumption in your first posting.
[quote] will not work, as QIODevice has Q_DISABLE_COPY [/quote]

goetz

Just a short note: It may be handy to provide some custom signal encryptedBytesWritten() just like signals in "QSslSocket:: encryptedBytesWritten()":http://doc.qt.nokia.com/4.7/qsslsocket.html#encryptedBytesWritten. This counts the bytes that were actually written to the underlying device (it might differ from the bytes that went in!).

andre

Not with this implementation it doesn't ;-)

giesbert

And with this implementation, when write returns, the bytes are written :-)
But I should look into this in the my SimpleCryptDevice impl :-) Thanks.

paucoma

Attempting to find out where the bytes are being emited in the case of QFile for example.
I have done a search in QFile.cpp, QIODevice.cpp and even QObject.cpp and none of them actually has the words "emit bytesWritten"

I have found: void bytesWritten(qint64 bytes); in qiodevice.h
Under a signal declaration header macro Q_SIGNALS which I have read to be for "Using Qt with 3rd Party Signals and Slots mechanisms":http://doc.qt.nokia.com/latest/signalsandslots.html#3rd-party-signals-and-slots

And then I searched for the Q_EMIT macro with no findings (except for a comment in qobject) and I have no further ideas.

Any suggestions on where to find out where this signal is being emited?

p.s. This is just a simple curiosity I had, if someone knows it off the top of their head it would be nice to know, otherwise I wouldn't want anybody to waste their time trying to answer the question.

p.p.s. Gerolf: Just noticed your "quoted" signature, was laughing for a good long minute and the smile will probably still be on my face when I wake up tomorrow. :D

giesbert

QIODevice is a base class. It defines the interface.

If you look at the docs of QFile, "it's stated":http://doc.qt.nokia.com/latest/qfile.html#signals :

bq. Unlike other QIODevice implementations, such as QTcpSocket, QFile does not emit the aboutToClose(), bytesWritten(), or readyRead() signals. This implementation detail means that QFile is not suitable for reading and writing certain types of files, such as device files on Unix platforms.

qbuffer.cpp emits it on line 82.

qprocess.cpp emits it on line 980.

qwindowspipewriter.cpp emits it on line 163.

For all sockets, I did not check now.