[Solved] Basic QIODevice subclass in Qt4

paucoma

Hi
I'm trying, and have been for the whole day with no luck, to subclass a QIODevice to encrypt/dycrypt a file. Something similar to the example valid for Qt3 : "Writing a Custom IODevice":http://doc.qt.nokia.com/qq/qq12-iodevice.html

I have unsucessfully tried to port the code from Qt3 to Qt4.

I have made the most basic subclass and get the following errors:

bq. In member function 'virtual qint64 scIODev::readData(char*, qint64)':
.../src/corelib/io/qiodevice.h:155: error:
'virtual qint64 QIODevice::readData(char*, qint64)' is protected
scIODev.cpp:11: error: within this context
In member function 'virtual qint64 scIODev::writeData(const char*, qint64)':
.../src/corelib/io/qiodevice.h:157: error:
'virtual qint64 QIODevice::writeData(const char*, qint64)' is protected
scIODev.cpp:17: error: within this context

This is my header file: scIODev.h

@
#ifndef SCIODEV_H
#define SCIODEV_H

#include <QIODevice>

class scIODev: public QIODevice
{
Q_OBJECT
public:
scIODev(QIODevice *parent);
private:
QIODevice *pIODev;
protected:
qint64 readData(char *data, qint64 maxSize);
qint64 writeData(const char *data, qint64 maxSize);
};
#endif
@

This is my source file: scIODev.cpp

@
#include "scIODev.h"

scIODev::scIODev(QIODevice *parent):
QIODevice(parent)
{
pIODev = parent;
}

qint64 scIODev::readData(char *data, qint64 maxSize)
{
qint64 bytesRead = pIODev -> readData(data, maxSize); //Line 11
return bytesRead;
}

qint64 scIODev::writeData(const char* data, qint64 maxSize)
{
qint64 i = pIODev -> writeData(data, maxSize); //Line 17
return i;
}
@

I am working on Windows XP in a MinGW/qt environment with "Qt SDK by Nokia v2010.05"

Thanks for any contributions

Edit: due to the general nature of the problem, moved to C++ gurus for now; Andre

andre

This is a basic C++ issue.
The problem is, is that you are in fact trying to access protected methods in another class. The IODevice you should be operating on, is this, not a "parent" QIODevice. I'm not sure why you gave your scIODev a QIODevice as a parent. The standard QIODevice as a QObject* as a parent, and so should your device, I think.

giesbert

Hi,

the base class in general is ok, as it is used as QIODevice (e.g. for a QTextStream).
The problem is that you try to access a protected function of another object, which is not allowed in C++, unless you are of the same class. You are derived.

What you could do is derive from QFile (so you are an IODevice) and overwrite these methods and call the base methods. The you can decrypt and call methods of the base class. Did you try this out?

or you call

qint64 QIODevice::read ( char * data, qint64 maxSize )
qint64 QIODevice::write ( const char * data, qint64 maxSize )

which are public functions.

paucoma

Yup you are right, this is a basic C++ issue and my C++ is a bit rusty.
Thanks for moving the post to the correct group. I've been checking up on the basics a bit.

qiodevice.h implements the virtual function as pure with no body, but the idea is to accept other IODevices as parents, such as QFile, and use their readData or writeData functions after a bit a preprocessing by my subclass scIODev.

so to explicitly access the parent function readData I have corrected the lines to
@
qint64 bytesRead = QIODevice::readData(data, maxSize);
@
@
qint64 i = QIODevice::writeData(data, maxSize);
@

This compiles but then doesn't manage to link properly I get undefined references at the calls of QIODevice::readData and QIODevice::writeData.

The constructor has been corrected to the standard parent of a QIODevice
@
scIODev::scIODev(QObject *parent):
QIODevice(parent)
{
}
@

Andre: using this-> just recursively calls its own function.. I want to use the inherited virtual function.

my main.cpp file is as the following:
@
#include <QFile>
#include <QTextStream>
#include <QDebug>
#include "scIODev.h"

int main()
{
QFile file("output.dat");
scIODev dv(&file);
dv.open(QIODevice::WriteOnly);
QTextStream ts(&dv);
ts << "Hello ";
dv.close();
return 0;
}
@

Gerolf: Thanks for the response. Deriving from QFile and adding functions will probably be what I'll end up doing when I eventually give up, since I'm not progressing much here.. and yet it seemed as a simple thing, at first.. Will need to do some catching up on polymorphism and inheritance.

giesbert

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!

paucoma

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 ?

andre

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.

giesbert

Hi paucoma,

how do you get a protected error for a public function?
read and write are public methods.

only readData and writeData are protected.

paucoma

[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.

giesbert

If you read the docs for IODevices, it states you must implement readData and writeData, that' scorrect. but it didnÄ't say you have to call them! the logic is up to youm, and if you sue another device, use it's public interface.

giesbert

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);
}
@

paucoma

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.

giesbert

you are right, yes

giesbert

Hi,

due to some bug, I updated the Wiki page.
The constructor of the io device was lacking a QObject* parent object pointer. The example had a mistake, as the encrypted data should never be interpreted as string...

it is now shown as hex code.

paucoma

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.

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.