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. s...@reibert.com ---------------------- > -------- Original Message -------- > Subject: Re: object-model: Return by value, reference or pointer? (or > something else?) > From: "Hyrum K. Wright" <hyrum_wri...@mail.utexas.edu> > Date: Wed, October 13, 2010 2:47 pm > To: dev@subversion.apache.org > > > On Wed, Oct 13, 2010 at 3:16 PM, Steinar Bang <s...@dod.no> wrote: > >>>>>> "Hyrum K. Wright" <hyrum_wri...@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
