[Solved] Basic QIODevice subclass in Qt4
-
If you've read my post completly, you could also do:
@
#include "scIODev.h"scIODev::scIODev(QIODevice *parent):
QIODevice(parent)
{
pIODev = parent;
}qint64 scIODev::readData(char *data, qint64 maxSize)
{
qint64 bytesRead = pIODev -> read (data, maxSize); //Line 11
return bytesRead;
}qint64 scIODev::writeData(const char* data, qint64 maxSize)
{
qint64 i = pIODev -> write(data, maxSize); //Line 17
return i;
}
@Just calling
@
qint64 bytesRead = QIODevice::readData(data, maxSize);
@must result in a linker error, as you call your pure virtual base functions, which does not exist! You must call on pIODev!
-
Man you guys are quick :) , greatly apreciated!
Gerolf: Tried it and several other combinations, still have the protected error.
So I have the protected function problem..
OK, so how do I access the inherited virtual function, if its in the protected domain.
@
QFile file("output.dat");
scIODev dv(&file);
dv.writeData( &data, len ) // <-- This should first access my function
//Then I want to pass on the processed data to writeData() implemented by QFile
@Something is wrong with my structure then.
I have meerly tried to copy and customize the ""Writing a Custom IODevice":http://doc.qt.nokia.com/qq/qq12-iodevice.html" Example.
Why are the pure virtual functions in QIODevice protected ?
-
What you seem to miss is how you call functions from a baseclass, and you seem to confuse the notions of a base class and a parent. A parent object is something used throughout Qt to maintain parent/child relationships, automatic destruction of children, and (for widgets) control rendering and if a widget is going to be a top level window or not. A baseclass on the other hand is the class that is specialized by your class. It is an is-a relationship, while the parent-child relationship is a has-a relationship.
If you want to call functions from a baseclass, you do something this:
@
QIODevice::readData();
@However, those functions are pure virtual for QIODevice, so calling them isn't going to work. You will have to implement them for your class using the public API of whatever classes you are using in your implementation. Calling them does make sense if you are not subclassing QIODevice, but a more specialized subclass of QIODevice that already has those implemented as something sane (such as QFile, as suggested before).
The problem is, I think, that you seem to want your class to work with any QIODevice as a "parent", as as to chain them. Did I get that correctly? If so, then perhaps "this class":http://libqxt.bitbucket.org/doc/0.6/qxtpipe.html can either function as a base class or as inspiration for you.
-
[quote]
how do you get a protected error for a public function?
read and write are public methods.
[/quote]Gerolf: ooops, I read that code too quickly... comes from looking at the same (similar) code too many times. Sorry, you are right. That solution I will have to look into... That was actually in the previous post too.. sorry for not paying attention.. Since in the Documentation it says only readData and writeData need to be reimplemented I had that idea quite fixed in my head and wasn't thinking about the other functions.
bq. The problem is, I think, that you seem to want your class to work with any QIODevice as a “parent”, as as to chain them. Did I get that correctly?
Correct!, I should have expressed that desire earlier.. I thought that too much information at once would confuse. but yes, I would like it to work on multiple classes which derive from QIODevice such as QBuffer and QFile.
I will have a read, thanks.
Thanks both very much for the quick and helpful responses!
Ultimately I will probably inherit QFile for the moment and use base class calls, untill the challenge to extend to other IODevices comes.
-
Hi,
I created a wiki page as porting of the QQ 12 article to Qt 4:
"wiki":http://developer.qt.nokia.com/wiki/CustomIoDevice
the main code is:
@
qint64 CryptDevice::readData(char* data, qint64 maxSize)
{
qint64 deviceRead = underlyingDevice->read(data, maxSize);
if (deviceRead == -1)
return -1;
for (qint64 i = 0; i < deviceRead; ++i)
data[i] = data[i] ^ 0x5E;return deviceRead;}
qint64 CryptDevice::writeData(const char* data, qint64 maxSize)
{
QByteArray buffer((int)maxSize, 0);
for (int i = 0; i < (int)maxSize; ++i)
buffer[i] = data[i] ^ 0x5E;
return underlyingDevice->write(buffer.data(), maxSize);
}
@ -
Thanks Gerolf, Great iniciative in porting the code!
So if I understand correctly,
-- readData() and writeData(...) are not part of the general class Interface and therefore I can be pretty sure that "normally" it won't be called on its own, but only indirectly through read().
-- If I subclass QIODevice I should keep protected the reimplementations of readData(...) and writeData(...) to ensure this.
-
-
Yea, the bad habit, or lets call it lazyness, of interpreting Bytes as string is just the quickest way to output "insignificant" data when you want to see that something is there or something is changing.
On the other hand looking at the class declaration:
@
class CryptDevice : public QIODevice
{
public:
explicit CryptDevice(QIODevice* deviceToUse, QObject* parent);
...
@is this necessary because you have no other constructor that accepts a QObject ?
could it be broken down to
@
class CryptDevice : public QIODevice
{
public:
CryptDevice(QObject* parent);
explicit CryptDevice(QIODevice* deviceToUse);
...
@@
CryptDevice::CryptDevice(QIODevice* deviceToUse) :
underlyingDevice(deviceToUse)
{
}
CryptDevice::CryptDevice(QObject* parent) :
QIODevice(parent)
{
}
@On a side note: What about the Q_OBJECT macro? I understand that this needs to be included when you want to use signals and slots mechanism.
Thanks for the update.
-
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.
-
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.
-
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. -
[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.
-
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?