[Solved] Basic QIODevice subclass in Qt4

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

[paucoma]

Hehe, thanks Gerolf. Man, what bad luck having chosen QFile for a "random" QIODevice to see where it would emit the signal.

[andre]

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

[giesbert]

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

[goetz]

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

[giesbert]

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.

[andre]

Is there a reason you set the key twice in the first example?

[giesbert]

Ups, no,

It was first in the c'tor, then the additional function.
I should add a c'Tor without the key...

Thanks for the hint.

[andre]

I hope you don't mind that I edited the wiki entry itself too :)

[giesbert]

All is fine :-)
I now changed the code and also on gitorious.

[paucoma]

Wow, Fantastic, Marvelous, Wonderful, Excellent!!
You guys Rock!
I've tried the classes out and great, I'm sure many will benefit from your brilliant contributions!

I've added a couple modifications to your SimpleCryptDevice class.
SimpleCryptDevice.h
@
// ----- construction -----
/**

• Constructor.
• Constructs a SimpleCryptDevice instance.
• The underlyingDevice needs to be set with setDevice.
• The crypt key can be set by setKey.
• @param parent parent object, see Qt documentation
  /
  SimpleCryptDevice(QObject parent=0);
  // ----- methods ----
  /**
• Sets the underlyingDevice
  /
  void setDevice(QIODevice underlyingDevice) {m_underlyingDevice = underlyingDevice;}
  /**
• Returns the last error that occurred.
  /
  int lastError() const {return m_crypto.lastError();}
  signals:
  /*
• This signal is emitted when SimpleCryptDevice writes a block of raw data to the underlying device.
  /
  void blockWritten();
  @
  SimpleCryptDevice.cpp
  @
  SimpleCryptDevice::SimpleCryptDevice(QObject parent)
  {
  }
  int SimpleCryptDevice::writeBlock(const QByteArray& bytesToWrite)
  {
  //...
  //..
  //.
  emit blockWritten();
  return realBytesWritten;
  }
  return 0;
  }
  @

Justification of modification:

• blockWritten() signal
  ** to provide feedback to a QProgressBar.
  *** I externally calculate how many blocks will be written dependent on the block size chosen
• Bare constructor
  ** to connect the signals before I define the device.
• lastError()
  ** to have access to the last error

Although the compiled code works fine, I would apreciate if you point out any error / malpractice I have done.

Thanks loads again!

[andre]

There is a potiential danger, that you have not set the underlying device before you start using the device if you take it out of the constructor. Because of the guarantee what was there before your modification, there is no check for that. Other than that, I can think of no major issues.

[giesbert]

That was exactly why the underlying device was part of the constructor. It does not make sense to reuse the SimpleCrypDevice with another base device. And also not without an underlying device.

The signal looks good. I will add it to gitorious and the wiki.