[Development] QList

Philippe philwave at gmail.com
Thu Mar 23 22:30:58 CET 2017


On Thu, 23 Mar 2017 14:22:36 -0700
Thiago Macieira <thiago.macieira at intel.com> wrote:
> > 
> >   return qFindChar(*this, ch, from, cs);
> > 
> > or
> > 
> >   return qFindString(*this, QStringView(&ch, 1), from, cs);
> > 
> > where only the qFoo() functions are exported, but none of the
> > QString/View/Ref members.
> 
> I don't think we're going to go that far. Doing so would mean a lot of work to 
> unexport the entire class and provide only free functions for the entirety of 
> the QString/QStringView API.

Indeed, let me quote Scott Meyer, in his paper "How Non-Member Functions
Improve Encapsulation"

"Based on his work with various string-like classes, Jack Reeves has observed that some functions just don't "feel" right when made non-members, even if they could be non-friend non-members. The "best" interface for a class can be found only by balancing many competing concerns, of which the degree of encapsulation is but one."

http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197?pgno=3




More information about the Development mailing list