Subject: Re: [boost] [ICL] some improvement proposals. Making selectors return const reference
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2011-05-23 05:16:33
Hi Denis, list,
thanks for your interest in Boost.ICL and for your input.
First a side note on the subject line:
You did what is stated in the boost discussion policy
Put the Library Name in the Subject Line
[ICL] some improvement proposals.
Actually as you can see on the list the convention that is actually
[boost][Libraryname] bla bla
for the developers list and
[Boost-users][Libraryname] bla bla
for the user's list.
*Would someone update the web page accordingly?*
Next I'd like to refer to a suggestion you've sent in off-list:
2011/5/16 Denis <denis_at_[hidden]>:
> Hi Joachim
> I also think that the functions upper() lower() first() last() have to
> return const reference to domain_type instead of domain_type.
> It is the same for int/double/time but has sense for my blobs.
> Returning domain_type implies copying.
> Same logic as std::vector's at().
This is interesting.
With first() and last(), I don't think it is possible, because,
dependent on the type of interval, we may generate a local temporary
object via increment (++) or decrement (--), which can not be referred
On the contrary for upper() and lower(), we should always be able to
pass the constant reference of the member variables of the interval as
return value. As you say, this avoids copying operations that might
decrease efficiency, if domain_type objects are large.
I think a modification to the code can be done without breaking
existing code, at least I hope so. We could use
typedef boost::call_traits<domain_type>::param domain_return_type
as return type of lower() and upper(), so pass by value can be kept
for built in types.
Still I am kind of reluctant when I think of implementing this optimization:
(1) Return by value works well and fast for the majority of
applications where domain_type is built-in or small
(2) Return by value allows for compiler optimizations that are taking
care for copy elision in many cases.
(3) It would be nicer if all selectors had the same signatures (simplicity).
(4) Customization of intervals will become more obscure, less
understandable by the new domain_return_type.
(5) We'd increase expert-friendliness for a concern that is relatively local:
Using ICL::intervals and interval_containers with large domain objects
is unfavorable anyway. If efficiency is a mayor issue, we would have
to consider not using the large objects directly in intervals but
introducing a level of indirection. We may refer to them through
(smart)pointers or iterators which are small and use an induced
ordering for the interval containers for the Compare template
x < y <=> (*x) < (*y)
So I'm not shure what to do. Currently I tend to consider an
implementation of the proposal.
-- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk