Well, I would say that QueryHitsPrivate is a POD by design. Although it is a class, it is used like a struct and maybe should better be declared as one! I think that would be one of the exceptions for being Feature Envy. What to you think?

Additionally, readPayload() is 20 lines and is perfectly readable and I wouldn’t take it apart unless we are able to reuse the parts, which is not the case now. Furthermore, if we do that for readPayload(), in order to be consistent, we’ll have to do the same for writePayload(), the preapre* functions and cannot see that will bring much.

It might make more sense though to have QueryHits::Result (prepare) read and (prepare) write itself.

atul wrote:Dear all

QueryHits::readPayload seems to be more interested in struct private..

Instead of pulling out the innards of private and filling them, we can push the stream to private…

void QueryHits::readPayload (QDataStream &stream)

{

stream >> p; // p knows its members

readQueryHitsData (stream);
p.readServentId( stream ); // if Id could be arranged to come before, stream >> p would take care of this…
}

The default ctor, QueryHits::QueryHits (), also suffers from being Feature Envy …

Why not give a default ctor to private?

I think private begs to be a full blown class ;-) rather than a POD ;-)