RE: object-model: Return by value, reference or pointer? (or something else?)

After following this thread with some interest, I cannot help but remark
it is amazing the lengths we all go through because std::string is
anemic.

I work on a Qt application and we debate all the time whether to use STL
or the equivalent 'Q' class (e.g., std::vector versus QValueVector). I
almost always argue for STL for portability, except in the case of
strings. There is nothing like having a full-featured string class
(http://doc.trolltech.com/4.6/qstring.html#isNull) to make you realize
how much std::string is lacking.

Cheers!

--
----------------------
Mark S. Reibert, Ph.D.
svn_at_reibert.com
----------------------
> -------- Original Message --------
> Subject: Re: object-model: Return by value, reference or pointer? (or
> something else?)
> From: "Hyrum K. Wright" <hyrum_wright_at_mail.utexas.edu>
> Date: Wed, October 13, 2010 2:47 pm
> To: dev_at_subversion.apache.org
> 
> 
> On Wed, Oct 13, 2010 at 3:16 PM, Steinar Bang <sb_at_dod.no> wrote:
> >>>>>> "Hyrum K. Wright" <hyrum_wright_at_mail.utexas.edu>:
> >
> >> At this point, it's my turn to get confused.  I'm speaking
> >> specifically of cases where we return STL classes.  Brane's earlier
> >> suggestion to create an implicit bool conversion works fine for our
> >> custom classes.  The problem I'm trying to solve is "how does one
> >> return the equivalent of '(const char *) NULL' in an std::string?"
> >> It's a this point that pointers start coming into play, because a NULL
> >> std::string * is quite feasible, whereas a NULL std::string isn't.
> >
> > Ah, ok.  That was at a different part of the thread... which I avoided
> > responding to because I have any good answers at hand. :-)
> >
> > Do you need the distrinction between an empty string and a NULL?
> >
> > If not then I would return an empty string for a NULL on the C side.
> 
> Yes, so that's a no-go.
> 
> > There's also the consideration that some std::string implementations are
> > deep copying (the gcc version uses refcounting (or at least used to do
> > so), but the VC++ one used to use deep copying.  I'm not sure if that
> > still is the case).
> >
> > Then maybe what you want to return is const std::string& (which leaves
> > you with the headache of managing the life cycle of the std::string, so
> > maybe not... though... you have the context of the wrapper class and
> > could cache them lazily there.  That would increase the footprint of the
> > wrapper, though).
> 
> I don't want the caller to have to depend upon the lifetime of the
> source object, hence the desire to return something by value or a
> newly allocated pointer.
> 
> Additionally, it still wouldn't work, since references have to point
> to some object, hence there is no such thing as a "null reference".
> 
> (This entire conversation is reminding my why I *hate* C++.  To bad
> there isn't too much of an alternative here... :/)
> 
> -Hyrum