Re: [boost] Heads up - string_ref landing

Subject: Re: [boost] Heads up - string_ref landing
From: Yakov Galka (ybungalobill_at_[hidden])
Date: 2012-12-16 04:56:02

On Sun, Dec 16, 2012 at 12:48 AM, Dave Abrahams <dave_at_[hidden]> wrote:

>  on Wed Dec 12 2012, Gottlob Frege <gottlobfrege-AT-gmail.com> wrote:
> [...]
> >
> > Qt's QString has both empty() and isNull() and they are not always the
> > same.  Basically empty() is a zero-byte string, but null is a
> > never-been-set-or-allocated string.
>
> That's dumb, though.
>

It is the matter of value semantics vs. pointer semantics. QString is "more
like" a pointer to a referenced counted string.

 > ie
> >
> > QString name = database.get("Name");
> >
> > name.empty() == true  means the Name field was empty
> > name.isNull() == true  means the Name field doesn't exist in the
> database.
> >
> > Somewhat like optional<string>.
> >
> > I am NOT saying whether this is a good thing.  Just a widely known
> example
> > of interpretation.
>
> I AM saying it's a bad thing! :-)
>

I agree with you that the null state of QString is a bad thing. But this by
itself does not justify interpreting an empty() string to be false. Let me
explain.

The conversion to bool usually tests the validity of the object so one can
do some other operations on it. For instance this is what it means in
iostreams (stream is in non-fail state so one can continue reading &
writing to it) and pointers (not null so one can dereference it). These
examples are of well understood validness of states. On the other hand, for
strings, it is dubious that empty() strings are in any way invalid. All
operations still can be done on them, like concatenation, find, operator []
with index <= size(), etc...

Having said that, personally I do not object to empty() being interpreted
as false. I am only trying to judge this suggestion objectively.

Cheers,
-- 
Yakov