Subclassing QNetworkReply

[wysota]

Use the decorator or proxy pattern.

[piotr.dobrogost]

This was the answer that answers my question

What would you say to add Visitor to the mix like this

struct ExtendedNetworkReply : public QNetworkReply
{
    virtual void doStuff() = 0;
    // the rest
};

struct ExtendedNetworkReply : public QNetworkReply
{
    virtual void doStuff() = 0;
    // the rest
};

To copy to clipboard, switch view to plain text mode 

struct SynchNetworkReply : public ExtendedNetworkReply
{
    virtual void doStuff() {};
};

struct SynchNetworkReply : public ExtendedNetworkReply
{
    virtual void doStuff() {};
};

To copy to clipboard, switch view to plain text mode 

struct AsynchNetworkReply : public ExtendedNetworkReply
{
    virtual void doStuff() {};
};

struct AsynchNetworkReply : public ExtendedNetworkReply
{
    virtual void doStuff() {};
};

To copy to clipboard, switch view to plain text mode 

and use doStuff() instead of checking tag? I guess it's more OO style

And two more questions;

1. One can avoid all this subclassing using one dynamic property of QNetworkReply (QObject in fact) to tag replies. Which one you think is better and why?

2. If QNetworkReply is meant to be extended by inheritance and used polimorphically why doesn't it have virtual destructor?

[piotr.dobrogost]

Use the decorator or proxy pattern.

I've found the example of proxy for QNetworkReply here.

I don't quite understand what's the reason for calling base subobject's methods in the following places:

NetworkReplyProxy::NetworkReplyProxy(QObject* parent, QNetworkReply* reply) {
...
setOperation(m_reply->operation());
setRequest(m_reply->request());
setUrl(m_reply->url());
...
}
 
 
// QIODevice proxy...
virtual qint64 bytesAvailable() const { 
return m_buffer.size() + QIODevice::bytesAvailable();    // <-- QIODevice::bytesAvailable() ?
}
 
// not possible...
void setReadBufferSize(qint64 size) {
    QNetworkReply::setReadBufferSize(size);    // <-- ???
    m_reply->setReadBufferSize(size); 
}
 
void errorInternal(QNetworkReply::NetworkError _error)
{
    setError(_error, errorString());    // <-- ???
    emit error(_error);
}

NetworkReplyProxy::NetworkReplyProxy(QObject* parent, QNetworkReply* reply) {
...
setOperation(m_reply->operation());
setRequest(m_reply->request());
setUrl(m_reply->url());
...
}


// QIODevice proxy...
virtual qint64 bytesAvailable() const { 
return m_buffer.size() + QIODevice::bytesAvailable();    // <-- QIODevice::bytesAvailable() ?
}

// not possible...
void setReadBufferSize(qint64 size) {
    QNetworkReply::setReadBufferSize(size);    // <-- ???
    m_reply->setReadBufferSize(size); 
}

void errorInternal(QNetworkReply::NetworkError _error)
{
    setError(_error, errorString());    // <-- ???
    emit error(_error);
}

To copy to clipboard, switch view to plain text mode 

Shouldn't proxy forward all calls to the original object?

[wysota]

In the first case bytesAvailable() of QIODevice is called because the latter has its own internal buffer that can contain some of the data. There is a labs article about it somewhere.