Re: [boost] [ICL] some improvement proposals. Making selectors return const reference
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 http://www.boost.org/community/policy.html which says: 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 established is [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@camfex.cz>:
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 to. 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 parameter. x < y <=> (*x) < (*y) So I'm not shure what to do. Currently I tend to consider an implementation of the proposal. Thoughts? Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
Hi Another option could be to expose _lwr and _upr as public members of interval (modelling after std::pair's `first` and `second`). On Mon, May 23, 2011 at 1:16 PM, Joachim Faulhaber <afojgo@googlemail.com>wrote:
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 http://www.boost.org/community/policy.html which says: 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 established is
[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@camfex.cz>:
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 to.
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 parameter.
x < y <=> (*x) < (*y)
So I'm not shure what to do. Currently I tend to consider an implementation of the proposal.
Thoughts?
Joachim
-- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
Hi Denis, 2011/5/23 Denis <comp.lib.boost.devel@camfex.cz>:
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@googlemail.com> wrote:
Hi Denis, list,
thanks for your interest in Boost.ICL and for your input.
[..]
2011/5/16 Denis <denis@camfex.cz>:
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@camfex.cz>:
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
participants (2)
-
Denis -
Joachim Faulhaber