[boost.indirect container] RFC on interface changes
Dear all, I'm working on getting the indirect container library (former smart container lib) ready for a post-review. During the review it was decided to provide overloads of assign(), insert() etc that takes a Range instead of two iterators. That is often a problem because of multiple overloads, that is, we get ambiguity. Basically I think we got two alternatives: 1. template< class Iter > void container::assign( const iterator_range<Iter>& ); ... container c; c.assign( make_iterator_range( some_range ) ); 2. template< class Range void container::assign_range( const Range& ): .... container c; c.assign_range( some_range ); Which one do you prefer? Another issue relates to the null pointer policy, that is, the way we specify how the container is allowed to include nulls. Here's two alternatives: 1. container< T > // null not allowed container< nullable<T> > // null allowed 2. container<T&> // null forbidden container<T*> // null allowed Thansks for your feedback. -Thorsten -- Thorsten Ottosen ---------------------------- Dezide Aps -- Intelligent Customer Support: www.dezide.com Aalborg University --- Decision Support Systems: http://www.cs.aau.dk/index2.php?content=Research/bss C++ Boost: www.boost.org C++ Standard: http://www.open-std.org/JTC1/SC22/WG21/
Thorsten Ottosen wrote:
Dear all,
I'm working on getting the indirect container library (former smart container lib) ready for a post-review.
During the review it was decided to provide overloads of assign(), insert() etc that takes a Range instead of two iterators.
That is often a problem because of multiple overloads, that is, we get ambiguity. Basically I think we got two alternatives:
1. template< class Iter > void container::assign( const iterator_range<Iter>& ); ... container c; c.assign( make_iterator_range( some_range ) );
2.
template< class Range void container::assign_range( const Range& ): .... container c; c.assign_range( some_range );
Which one do you prefer?
I definitely prefer "assign" to "assign_range". Could you say more explcitly what the ambiguity would be if you try to make assign and insert to too much work? Jonathan
"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message news:cub5f6$ulc$1@sea.gmane.org... | Thorsten Ottosen wrote: | > That is often a problem because of multiple overloads, that is, | > we get ambiguity. Basically I think we got two alternatives: | > | > 1. | > template< class Iter > | > void container::assign( const iterator_range<Iter>& ); | > ... | > container c; | > c.assign( make_iterator_range( some_range ) ); | > | > 2. | > | > template< class Range | > void container::assign_range( const Range& ): | > .... | > container c; | > c.assign_range( some_range ); | > | > Which one do you prefer? | | I definitely prefer "assign" to "assign_range". Could you say more explcitly | what the ambiguity would be if you try to make assign and insert to too much | work? yes, the problem shows up when an implicit conversion from Derived* to Base* is needed and when another templated overload exists. The templated overload does not require any conversions and so is deemed a better match. The attached code shows the problem. I guess the problem could be removed with disable_if<>. -Thorsten begin 666 range.cpp M(VEN8VQU9&4@/'9E8W1O<CX-"B-I;F-L=61E(#QB;V]S="]T>7!E7W1R86ET M<R]I<U]P;VEN=&5R+FAP<#X-"B-I;F-L=61E(#QB;V]S="]S=&%T:6-?87-S M97)T+FAP<#X-"@T*=&5M<&QA=&4\(&-L87-S(%0@/@T*<W1R=6-T(&YE=U]V M96-T;W(-"GL-"B @("!T>7!E9&5F('-T9#HZ=F5C=&]R/%0J/B @(" @(" @ M(" @("!T>7!E.PT*(" @('1Y<&5D968@='EP96YA;64@='EP93HZ:71E<F%T M;W(@(" @(&ET97)A=&]R.PT*#0H@(" @=F]I9"!I;G-E<G0H(&ET97)A=&]R M+"!4*B I#0H@(" @>PT*(" @('T-"@T*(" @('9O:60@:6YS97)T*"!I=&5R M871O<BP@5"8@*0T*(" @('L-"B @("!]#0H-"B @("!T96UP;&%T93P@8VQA M<W,@4F%N9V4@/@T*(" @('9O:60@:6YS97)T*"!I=&5R871O<BP@8V]N<W0@ M4F%N9V4F('(@*0T*(" @('L-"B @(" @(" @0D]/4U1?4U1!5$E#7T%34T52 M5"@H("%B;V]S=#HZ:7-?<&]I;G1E<CQ286YG93XZ.G9A;'5E("DI.PT*(" @ M('T-"@T*(" @(&ET97)A=&]R(&)E9VEN*"D-"B @("![#0H@(" @(" @(')E M='5R;B!I=&5R871O<B@I.PT*(" @('T-"GT[#0H-"G-T<G5C="!&;V\-"GL- M"GT[#0H-"G-T<G5C="!"87(@.B!&;V\-"GL-"GT[#0H-"G1E;7!L871E/"!C M;&%S<R!4+"!C;&%S<R!5(#X-"G9O:60@9F]O*"D-"GL-"B @("!N97=?=F5C M=&]R/%0^('8[#0H@(" @=BYI;G-E<G0H('8N8F5G:6XH*2P@;F5W(%4@*3L@ M(" @#0H@(" @=BYI;G-E<G0H('8N8F5G:6XH*2P@=B I.PT*?0T*#0II;G0@ M;6%I;B@I#0I[#0H-"B @("!F;V\\:6YT+&EN=#XH*3L@+R\@;VL-"B @("!F M;V\\1F]O+$9O;SXH*3L@+R\@;VL-"B @("!F;V\\1F]O+$)A<CXH*3L@+R\@ *9&]H#0H-"GT-"@`` ` end
Thorsten Ottosen wrote:
"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message
I definitely prefer "assign" to "assign_range". Could you say more explcitly what the ambiguity would be if you try to make assign and insert to too much work?
yes, the problem shows up when an implicit conversion from Derived* to Base* is needed and when another templated overload exists. The templated overload does not require any conversions and so is deemed a better match.
The attached code shows the problem.
I guess the problem could be removed with disable_if<>.
The attached version uses a similar idea, but should work on compilers without SFINAE. Jonathan begin 666 range.cpp M(VEN8VQU9&4@/'9E8W1O<CX-"B-I;F-L=61E(#QB;V]S="]T>7!E7W1R86ET M<R]I<U]P;VEN=&5R+FAP<#X-"B-I;F-L=61E(#QB;V]S="]S=&%T:6-?87-S M97)T+FAP<#X-"@T*=&5M<&QA=&4\8F]O;"!)<U!O:6YT97(^#0IS=')U8W0@ M:6YS97)T7VEM<&P[#0H-"G1E;7!L871E/#X-"G-T<G5C="!I;G-E<G1?:6UP M;#QT<G5E/B![#0H@(" @=&5M<&QA=&4\='EP96YA;64@0V]N=&%I;F5R+"!T M>7!E;F%M92!)=&5R871O<BP@='EP96YA;64@5#X-"B @("!S=&%T:6,@=F]I M9"!I;G-E<G0H0V]N=&%I;F5R)B!C;G0L($ET97)A=&]R(&ET+"!4*B!T*0T* M(" @('L-"@T*(" @('T-"GT[#0H-"@T*=&5M<&QA=&4\/@T*<W1R=6-T(&EN M<V5R=%]I;7!L/&9A;'-E/B![#0H@(" @=&5M<&QA=&4\='EP96YA;64@0V]N M=&%I;F5R+"!T>7!E;F%M92!)=&5R871O<BP@='EP96YA;64@4F%N9V4^#0H@ M(" @<W1A=&EC('9O:60@:6YS97)T*$-O;G1A:6YE<B8@8VYT+"!)=&5R871O M<B!I="P@8V]N<W0@4F%N9V4F('(I#0H@(" @>PT*(" @(" @("!"3T]35%]3 M5$%424-?05-315)4*"@@(6)O;W-T.CII<U]P;VEN=&5R/%)A;F=E/CHZ=F%L M=64@*2D[#0H@(" @?0T*?3L-"@T*=&5M<&QA=&4\(&-L87-S(%0@/@T*<W1R M=6-T(&YE=U]V96-T;W(-"GL-"B @("!T>7!E9&5F('-T9#HZ=F5C=&]R/%0J M/B @(" @(" @(" @("!T>7!E.PT*(" @('1Y<&5D968@='EP96YA;64@='EP M93HZ:71E<F%T;W(@(" @(&ET97)A=&]R.PT*#0H@(" @+R\@365R9V5D('=I M=&@@4F%N9V4@;W9E<FQO860N#0H@(" @+R]V;VED(&EN<V5R="@@:71E<F%T M;W(L(%0J("D-"B @(" O+WL-"B @(" O+WT-"@T*(" @('9O:60@:6YS97)T M*"!I=&5R871O<BP@5"8@*0T*(" @('L-"B @("!]#0H-"B @("!T96UP;&%T M93P@8VQA<W,@4F%N9V4@/@T*(" @('9O:60@:6YS97)T*"!I=&5R871O<B!I M="P@8V]N<W0@4F%N9V4F('(@*0T*(" @('L-"B @(" @(" @:6YS97)T7VEM M<&P\(&)O;W-T.CII<U]P;VEN=&5R/%)A;F=E/CHZ=F%L=64@/CHZ:6YS97)T M*"IT:&ES+"!I="P@<BD[#0H@(" @?0T*#0H@(" @:71E<F%T;W(@8F5G:6XH M*0T*(" @('L-"B @(" @(" @<F5T=7)N(&ET97)A=&]R*"D[#0H@(" @?0T* M?3L-"@T*<W1R=6-T($9O;PT*>PT*?3L-"@T*<W1R=6-T($)A<B Z($9O;PT* M>PT*?3L-"@T*=&5M<&QA=&4\(&-L87-S(%0L(&-L87-S(%4@/@T*=F]I9"!F M;V\H*0T*>PT*(" @(&YE=U]V96-T;W(\5#X@=CL-"B @("!V+FEN<V5R="@@ M=BYB96=I;B@I+"!N97<@52 I.R @(" -"B @("!V+FEN<V5R="@@=BYB96=I M;B@I+"!V("D[#0I]#0H-"FEN="!M86EN*"D-"GL-"@T*(" @(&9O;SQI;G0L M:6YT/B@I.R O+R!O:PT*(" @(&9O;SQ&;V\L1F]O/B@I.R O+R!O:PT*(" @
(&9O;SQ&;V\L0F%R/B@I.R O+R!D;V@-"@T*?0T* ` end
"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message news:cudpdk$t4c$1@sea.gmane.org... | Thorsten Ottosen wrote: | >> yes, the problem shows up when an implicit conversion from Derived* | >> to Base* is needed and when another templated overload exists. The | >> templated overload does not require any conversions and so is deemed | >> a better match. | >> | >> The attached code shows the problem. | >> | >> I guess the problem could be removed with disable_if<>. | | The attached version uses a similar idea, but should work on compilers without | SFINAE. yeah, good idea. Anyway, in the first release I don't plan to support super old compilers. We'll keep the names assign() and insert(). -Thorsten
participants (2)
-
Jonathan Turkanis -
Thorsten Ottosen