Re: [boost] [ICL] some improvement proposals. Making selectors return const reference

Subject: Re: [boost] [ICL] some improvement proposals. Making selectors return const reference
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2011-05-26 06:44:55

Hi Denis,

2011/5/23 Denis <comp.lib.boost.devel_at_[hidden]>:
> Hi
> Another option could be to expose _lwr and _upr as public members of
> interval (modelling after std::pair's `first` and `second`).

Radical  =O

BTW, we do not *top post* on the boost developers list, and we do not
*over quote*. This serves the goal of readability and conciseness of
discussions. Bear in mind that your postings are archived and may be a
source of information for quite some time. So you may want to consider
reading the boost discussion policy:
http://www.boost.org/community/policy.html

> On Mon, May 23, 2011 at 1:16 PM, Joachim Faulhaber <afojgo_at_[hidden]>
> wrote:
>>
>> Hi Denis, list,
>>
>> thanks for your interest in Boost.ICL and for your input.
[..]
>>
>> 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.
>>
[..]
>> 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
>> parameter.
>>
>> x < y <=> (*x) < (*y)
>>
>> So I'm not shure what to do. Currently I tend to consider an
>> implementation of the proposal.
>>
>> Thoughts?

2011/5/23 Denis <comp.lib.boost.devel_at_[hidden]>:
> Hi
> Another option could be to expose _lwr and _upr as public members of
> interval (modelling after std::pair's `first` and `second`).

Yes, this would simplify things a lot. But we'd sacrifice information
hiding also. This would be an invitation for people doing really ugly
and dangerous things with intervals and interval containers.

Regards,
Joachim

-- 
Interval Container Library [Boost.Icl]
http://www.joachim-faulhaber.de