Hey guys, In ordered_index there are two scalar insert overloads: std::pair<iterator,bool> insert(const value_type& x); iterator insert(iterator position,const value_type& x); The second version is lacking the bool result, which is sometimes required. In my source code of boost-1_42 I patched the second version like this: ==== .../ordered_index.hpp#2 (text) ==== @@ -97,6 +99,16 @@ struct ordered_unique_tag{}; struct ordered_non_unique_tag{}; +template<class T, class U> +struct auto_cast_pair : std::pair<T, U> +{ + typedef std::pair<T, U> base_pair; + auto_cast_pair(base_pair const& b) : base_pair(b) {} + using base_pair::operator=; + operator T&() { return this->first; } + operator T const&() const { return this->first; } +}; + template< typename KeyFromValue,typename Compare, typename SuperMeta,typename TagList,typename Category @@ -274,14 +286,14 @@ return std::pair<iterator,bool>(make_iterator(p.first),p.second); } - iterator insert(iterator position,value_param_type x) + auto_cast_pair<iterator,bool> insert(iterator position,value_param_type x) { BOOST_MULTI_INDEX_CHECK_VALID_ITERATOR(position); BOOST_MULTI_INDEX_CHECK_IS_OWNER(position,*this); BOOST_MULTI_INDEX_ORD_INDEX_CHECK_INVARIANT; std::pair<final_node_type*,bool> p=this->final_insert_( x,static_cast<final_node_type*>(position.get_node())); - return make_iterator(p.first); + return std::pair<iterator,bool>(make_iterator(p.first),p.second); } template<typename InputIterator> Now it automatically figures which return value one wants. Just an idea. -- Max
Maxim Yegorushkin wrote:
In ordered_index there are two scalar insert overloads:
std::pair<iterator,bool> insert(const value_type& x); iterator insert(iterator position,const value_type& x);
The second version is lacking the bool result, which is sometimes required.
As is, it mirrors std::map's interface. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
________________________________________ De: boost-bounces@lists.boost.org [boost-bounces@lists.boost.org] En nombre de Stewart, Robert [Robert.Stewart@sig.com] Enviado el: viernes, 05 de noviembre de 2010 18:54 Para: boost@lists.boost.org Asunto: Re: [boost] [multi_index] scalar insert interface
Maxim Yegorushkin wrote:
In ordered_index there are two scalar insert overloads:
std::pair<iterator,bool> insert(const value_type& x); iterator insert(iterator position,const value_type& x);
The second version is lacking the bool result, which is sometimes required.
As is, it mirrors std::map's interface.
Correct, this is exactly the rationale behind the difference in the result types of both overloads. Clever as Maxim's suggestion is, I'm reluctant to diverge from the standard without a compelling reason --here the benefit does not seem impressive, since there are efficient ways to determine whether the insertion took place, for instance checking size() before and after trying the insertion. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
On 05/11/10 18:15, JOAQUIN M. LOPEZ MUÑOZ wrote:
________________________________________ De: boost-bounces@lists.boost.org [boost-bounces@lists.boost.org] En nombre de Stewart, Robert [Robert.Stewart@sig.com] Enviado el: viernes, 05 de noviembre de 2010 18:54 Para: boost@lists.boost.org Asunto: Re: [boost] [multi_index] scalar insert interface
Maxim Yegorushkin wrote:
In ordered_index there are two scalar insert overloads:
std::pair<iterator,bool> insert(const value_type& x); iterator insert(iterator position,const value_type& x);
The second version is lacking the bool result, which is sometimes required.
As is, it mirrors std::map's interface.
Correct, this is exactly the rationale behind the difference in the result types of both overloads. Clever as Maxim's suggestion is, I'm reluctant to diverge from the standard without a compelling reason --here the benefit does not seem impressive, since there are efficient ways to determine whether the insertion took place, for instance checking size() before and after trying the insertion.
That is actually a good idea to check size(). The rationale behind the patch was that internally final_insert_ still returns that bool flag, it is just the interface of std::map::insert requires to discard that value. Anyway, checking size() solves my issue. -- Max
On 05/11/10 18:15, JOAQUIN M. LOPEZ MUÑOZ wrote:
________________________________________ De: boost-bounces@lists.boost.org [boost-bounces@lists.boost.org] En nombre de Stewart, Robert [Robert.Stewart@sig.com] Enviado el: viernes, 05 de noviembre de 2010 18:54 Para: boost@lists.boost.org Asunto: Re: [boost] [multi_index] scalar insert interface
Maxim Yegorushkin wrote:
In ordered_index there are two scalar insert overloads:
std::pair<iterator,bool> insert(const value_type& x); iterator insert(iterator position,const value_type& x);
The second version is lacking the bool result, which is sometimes required.
As is, it mirrors std::map's interface.
Correct, this is exactly the rationale behind the difference in the result types of both overloads. Clever as Maxim's suggestion is, I'm reluctant to diverge from the standard without a compelling reason --here the benefit does not seem impressive, since there are efficient ways to determine whether the insertion took place, for instance checking size() before and after trying the insertion.
Performance-wise, it probably requires extra CPU cycles and storage (cache) to check size before and after insertion. I would still vote for another insert overload, maybe insert2() or something, which returns that bool. Since internally final_insert_ always returns it, there is no good reason to waste it. -- Max
Maxim Yegorushkin <maxim.yegorushkin <at> gmail.com> writes:
On 05/11/10 18:15, JOAQUIN M. LOPEZ MUÑOZ wrote:
________________________________________ De: boost-bounces <at> lists.boost.org [boost-bounces <at> lists.boost.org] En nombre de Stewart, Robert [Robert.Stewart <at> sig.com]
As is, it mirrors std::map's interface.
Correct, this is exactly the rationale behind the difference in the result types of both overloads. Clever as Maxim's suggestion is, I'm reluctant to diverge from the standard without a compelling reason --here the benefit does not seem impressive, since there are efficient ways to determine whether the insertion took place, for instance checking size() before and after trying the insertion.
Performance-wise, it probably requires extra CPU cycles and storage (cache) to check size before and after insertion.
I would still vote for another insert overload, maybe insert2() or something, which returns that bool. Since internally final_insert_ always returns it, there is no good reason to waste it.
The (not explicitly stated) reason why the second overload of insert does not return a pair<iterator,bool> is to make ordered containers compatible with std::insert_iterator: http://www.sgi.com/tech/stl/insert_iterator.html Why don't you propose your auto_cast_pair solution as a modification to the standard? As it stands, seems like insert_iterator can be easily modified to cope with a auto_cast_pair return type. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (4)
-
Joaquin M Lopez Munoz -
JOAQUIN M. LOPEZ MUÑOZ
-
Maxim Yegorushkin -
Stewart, Robert