Re: New public API

["Alexey Parshin" <alexeyp@gmail.com>]

IMHO, ref counting is bad :( Every time I've used strings with ref counting
it was giving me one problem or another. Of course, it depends on coding
style..

We can solve that problem partually if we return "const string&".

In that case, if one wants just to use a string w/o altering its content -
it can be done like this:

const string& myString = myClass.myMethod();
cout << myString << endl;

Does it make sense to you? This approach is pretty effective.

2006/2/21, Ilya Volynets <ilya@total-knowledge.com>:
>
> 1. Don't know. Maybe yes maybe no
> In any case - it's probably be bad with gcc.
> 2. Let's see if we can get reasonable ref counting
>
> -----Original Message-----
> From: Krzysztof Rzymkowski <rzymek@gmail.com>
> Date: Tue, 21 Feb 2006 00:24:56
> To:C++ Servlet Engine Discussion <cppserv@total-knowledge.com>
> Subject: Re: New public API
>
> On Mon, 2006-02-20 at 22:37 +0000, Ilya Volynets wrote:
> > I am aware of retval optimization, though I am not sure about semantics
> in case of C++ - what if copy constructor has side effects?
> >
> Are you sure there's a guarantee that a copy constructor will be called
> when an object is returned by value? I think there's no such guarantee,
> nor there should be any.
>
> > As for optimizations on copy from
> > The library, I'm not sure again - I
> > think it's *supposed* to copy in this case, but I don't remember.
> >
> > Auto-ptr/ref counting is something I'd prefer, and it's semantically
> closest to java
>
> Now the question is: is allocating heap memory via new is that much
> faster then copying an object? (Though in case of a big vector is sure
> is)
>
> >
> > -----Original Message-----
> > From: Krzysztof Rzymkowski <rzymek@gmail.com>
> > Date: Mon, 20 Feb 2006 23:15:18
> > To:C++ Servlet Engine Discussion <cppserv@total-knowledge.com>
> > Subject: Re: New public API
> >
> > On Mon, 2006-02-20 at 11:00 -0800, Ilya A. Volynets-Evenbakh wrote:
> > > One thing I was thinking about (and even started using in some cases)
> > > is to change methods returing collections. The way it is now:
> > > virtual std::vector<std::string>  getAttributeNames()
> > > This means that whole vector, as well as every string inside will be
> copied
> > > (possibly twice - inside function when creating retval, and then to
> the
> > > actual
> > > return value). Now, instead we could change signiture as follows:
> > > virtual void getAttributeNames(std::vector<std::string> &out)
> > > This will avoid unnessesary copying.
> > >
> > > Java does not have to worry about it, since it returns references, and
> thus
> > > only one copy of object is created.
> >
> > It is possible for a STL implementation to user reference counting in
> > vector's copy constructor, thought the SGI's STL does simple copying.
> > It is as well possible for the compiler to use return value optimization
> > [1], thought it is not always possible to write the getters in a way
> > which allows RVO.
> >
> > Another option would be to use std::auto_ptr [2] or boost::shared_ptr
> > [3].
> >
> > I would like to keep the API as close to the Java version as it is
> > possible. So I'd rather stick with option 1 (ignore the problem) or 2
> > user some sort of reference counting.
> >
> > [1] http://cpptips.hyperformix.com/cpptips/ret_val_opt
> > [2] http://gcc.gnu.org/onlinedocs/libstdc
> > ++/latest-doxygen/classstd_1_1auto__ptr.html
> > [3] http://www.boost.org/libs/smart_ptr/shared_ptr.htm
> --
>



--
Alexey Parshin,
http://www.sptk.net