[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: New public API
On Tue, 2006-02-21 at 11:21 -0800, Ilya A. Volynets-Evenbakh wrote:
> Some more thoughts on the subject:
>
> - retval optimization will work perfectly for single-object access
> methods, but
> is far less likely to work for vectors - if they have to be filled out
> from some
> other data, rather then simply copied
True.
> - We are targeting primarily GCC-based systems, so we should not rely
> on some hypothetic optimizations by compiler, but rather stick to what
> current one does. Specifically - what do we know about container copy
> constructors in libstdc++ version of STL?
vector does simple copting, string does somthing smarter as far as I can
see (see [2] below)
> - And finally, in ideal case, I'd prefer for public API part not to
> depend on
> any external library - not even boost.
That is a valid point. So is std::auto_ptr the winner?
>
> Krzysztof Rzymkowski wrote:
>
> >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
> >
> >
> >
>
--