[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