[Solved] Basic QIODevice subclass in Qt4
-
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.
-
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?
-
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?
-
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.
-
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...
-
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...
-
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;
- In that case, will the compiler automatically generate a copy constructor?
-
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] -
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!).
-
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-slotsAnd 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
-
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.
-
[quote author="Volker" date="1300991199"]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!).[/quote]
Wouldn't that be overkill, because you already have access to the underlying QIODevice directly? If you're interested in what was written, couldn't simply connect to that IODevices' bytesWritten() signal?
-
[quote author="Andre" date="1301002233"]
Wouldn't that be overkill, because you already have access to the underlying QIODevice directly? If you're interested in what was written, couldn't simply connect to that IODevices' bytesWritten() signal?[/quote]Only if it's not a QFile!
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.
-
[quote author="Andre" date="1301002233"]
[quote author="Volker" date="1300991199"]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!).[/quote]Wouldn't that be overkill, because you already have access to the underlying QIODevice directly? If you're interested in what was written, couldn't simply connect to that IODevices' bytesWritten() signal?[/quote]
In this case yes, you're right. I had that QSslSocket in mind, but you do not have access to the "regular" TCP socket in that case.
-
There is a more enhanced eexample, also in the wiki now: "Simple Crypt IO Device":http://developer.qt.nokia.com/wiki/Simple_Crypt_IO_Device . It uses the "SimpleCrypt class":http://developer.qt.nokia.com/wiki/Simple_encryption to encrypt the data and stores it via a custom IO device in any other device.