Re: [Libxmlplusplus-general] const std::string& return types.

[murrayc t-online de (Murray Cumming)]

On Fri, 2002-11-15 at 15:05, Christophe de VIENNE wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Le Vendredi 15 Novembre 2002 14:29, Murray Cumming a écrit :
> > I am very uncomfortable with function signatures such as this:
> > const std::string& Node::name() const;
> >
> > because
> > a) It is untargetted optimisation, and it's too early for that.
> 
> True. It can be seen as a way of 'saying' : this method returns the exact 
> content of an internal field, but you cannot change it.
> 
> > b) It makes orphaned references possible.
> > c) std::string can be implemented with reference-counting to make
> > copying more efficient - I believe that newer versions of libstdc++ do
> > this.
> 
> Do you mean the one given with g++ 3.x ?

I'm not sure. I have been told that it is in g++ 3.x. I believe that the
C++ spec allows it anyway, so that's where the optimisation should
happen.

>  well I thought it was not.
> Moreover can we stat that all libxml++ will use this implementation of 
> std::string ?

No, but they can tell us if they need something to be optimised.

> > Christophe, if you agree then I will change all these methods to look
> > like this instead:
> > std::string get_name() const;
> 
> 
> Well, I'm (for now) half convinced only. since we return a const referenced 
> object, it will force the calling code either to copy the string immediately, 
> either to call a const function on it (which is fine in a non threaded 
> context).
> And keeping an orphan reference on it is, in my mind, more a mistake of the 
> lib user than a lack of robustess of the lib.

I think the API shouldn't encourage people to make this mistake.

>  The use of const references 
> does not, usually, to this.

Well it isn't done very often. It's generally frowned upon.

-- 
> 
> Murray Cumming
> murray usa net
> www.murrayc.com