2015-09-10 9:49 GMT+02:00 Blasche Alexander <alexander.blas...@theqtcompany.com>: > >>> Another inefficiency of the QIODevice approach would be that each frame > Hi, > >>> would have to be serialized to a QByteArray on the user API side just to be >> >unserialized on the backend side again. I have yet to see a backend API that >> >doesn't deal with a frame based API. There is simply nothing gained. >> >>I don't get why each frame would have to be serialized if >>QCanBusDevice inherits QIODevice. The implementation of >>QCanBusDevice::writeFrame() would not change. It would, on the other >>hand, require to implement QIODevice::writeData() which would either >>call QCanBusDevice::writeFrame() or directly the backend API >>effectively doing some "unserialization". > > The question is how you get to the serialized QCanBusFrame in the first place. > > Based on your suggestion above the usual order of calls for a QIODevice based > API across the stack is such that > > const char* serialized_frame = ... > device->write(serialized_frame; > -> device->writeData(serialized_frame, size); // deserializes > serialized_frame > -> device->writeFrame(frame) // based on your suggestion above > > How did the user create serialized_frame if not using some QDataStream > operator that created it from QCanBusFrame? Surely you cannot expect the API > user to create the data stream representing a frame from scratch but via > QCanBusFrame? > > I am sorry all I see is artificially passing everything through a > serialization process where the top and the bottom of the call series end up > with the same QCanBusFrame. Then I may as well permit the user to directly > call writeFrame(). And that's what we did. > > Let me ask you this, why do you want it to be a QIODevice? It's not because > the Qt docs stating "The QIODevice class is the base interface class of all > I/O devices in Qt", is it? For me the API just doesn't fit and that's reason > enough for me to contradict the QIODevice documentation ;) > > -- > Alex
I do not object that the user can directly call writeFrame(). And I agree that using the QIODevice API in such case would lead to an unnecessary overload. Nonetheless, I think that, as it has been done with QUdpSocket, adding the QIODevice API to the existing CAN API would only make the Qt framework more coherent. (It is just a matter of taste and policy.) To be clear, I don't want the QCanBusDevice API to fit inside the QIODevice API, but I would find it more coherent if QCanBusDevice would offer the QIODevice API as a fallback ; the current CAN API would still be public and the recommended way to use QCanBusDevice. Benjamin _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
