[Range] breaking update pending

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[Range] breaking update pending

Thorsten Ottosen
Dear All,

I have been trimming boost.range to incorporate the changes we have been
discussing some time ago.

These changes will break many uses of the library. Inside boost this
will affect

Boost.foreach
Boost.string algo
Boost.iostreams (*)

(*) I don't this will break

The list of major changes is the follwing:

1. ADL hooks renamed boost_range_begin -> range_begin,
                      boost_range_end -> range_end

2. ADL hook boost_range_size removed; boost::size(rng) now requires
    RandomAccessIterators to guarantee O(1) complexity.

3. range_result_iterator renamed range_iterator and range_iterator
renamed mutable_iterator. The correct way to spell const_iterator<T> is
now iterator<const T>.

4. intrinsic string support removed. instead a header as_literal.hpp is
previded with a small utility for use in string algorithms.


I expect that (3) and (4) is where the most work lies.

If nobody has anything to add, will add the new version to the cvs
within a few days.

-Thorsten

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Range] breaking update pending

Shunsuke Sogame
Thorsten Ottosen wrote:

> Dear All,
>
> I have been trimming boost.range to incorporate the changes we have been
> discussing some time ago.
>
> These changes will break many uses of the library. Inside boost this
> will affect
>
> Boost.foreach
> Boost.string algo
> Boost.iostreams (*)
>
> (*) I don't this will break
>
> The list of major changes is the follwing:
>
> 1. ADL hooks renamed boost_range_begin -> range_begin,
>                       boost_range_end -> range_end

Why was such short name accepted??
Even 'const_begin' that calls unqualified 'begin' breaks down Boost.MPL!!

> 2. ADL hook boost_range_size removed; boost::size(rng) now requires
>     RandomAccessIterators to guarantee O(1) complexity.
>
> 3. range_result_iterator renamed range_iterator and range_iterator
> renamed mutable_iterator. The correct way to spell const_iterator<T> is
> now iterator<const T>.

range_result_iterator is alive? If so, it's nice. :-)

> 4. intrinsic string support removed. instead a header as_literal.hpp is
> previded with a small utility for use in string algorithms.

FWIW, I experienced "Range adaptor syntax" could make it prettier.


Regards,
MB
p-stade.sourceforge.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Range] breaking update pending

David Abrahams
MB <[hidden email]> writes:

> Thorsten Ottosen wrote:
>> Dear All,
>>
>> I have been trimming boost.range to incorporate the changes we have been
>> discussing some time ago.
>>
>> These changes will break many uses of the library. Inside boost this
>> will affect
>>
>> Boost.foreach
>> Boost.string algo
>> Boost.iostreams (*)
>>
>> (*) I don't this will break
>>
>> The list of major changes is the follwing:
>>
>> 1. ADL hooks renamed boost_range_begin -> range_begin,
>>                       boost_range_end -> range_end
>
> Why was such short name accepted??
> Even 'const_begin' that calls unqualified 'begin' breaks down Boost.MPL!!

How so?  What happens?  Got a small reproducible case?

>> 2. ADL hook boost_range_size removed; boost::size(rng) now requires
>>     RandomAccessIterators to guarantee O(1) complexity.
>>
>> 3. range_result_iterator renamed range_iterator and range_iterator
>> renamed mutable_iterator. The correct way to spell const_iterator<T> is
>> now iterator<const T>.
>
> range_result_iterator is alive? If so, it's nice. :-)
>
>> 4. intrinsic string support removed. instead a header as_literal.hpp is
>> previded with a small utility for use in string algorithms.
>
> FWIW, I experienced "Range adaptor syntax" could make it prettier.

Thorsten, did you consider providing a backward compatibility layer
for the transition?

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Range] breaking update pending

Shunsuke Sogame
David Abrahams wrote:

> MB <[hidden email]> writes:
>
>
>>Thorsten Ottosen wrote:
>>
>>>Dear All,
>>>
>>>I have been trimming boost.range to incorporate the changes we have been
>>>discussing some time ago.
>>>
>>>These changes will break many uses of the library. Inside boost this
>>>will affect
>>>
>>>Boost.foreach
>>>Boost.string algo
>>>Boost.iostreams (*)
>>>
>>>(*) I don't this will break
>>>
>>>The list of major changes is the follwing:
>>>
>>>1. ADL hooks renamed boost_range_begin -> range_begin,
>>>                      boost_range_end -> range_end
>>
>>Why was such short name accepted??
>>Even 'const_begin' that calls unqualified 'begin' breaks down Boost.MPL!!
>
>
> How so?  What happens?  Got a small reproducible case?

See:
   http://lists.boost.org/boost-users/2006/01/16513.php

   void trouble()
   {
        typedef dummy< ::boost::mpl::vector< int > > vt ;
        typedef ::std::vector< const vt* > ct ;

        boost::const_begin( ct() ) ;
   }


(though I don't know whether or not this GCC behavior is conforming.)


Regards,
MB

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Range] breaking update pending

Aleksey Gurtovoy
MB writes:

> David Abrahams wrote:
>> MB <[hidden email]> writes:
>>>Even 'const_begin' that calls unqualified 'begin' breaks down Boost.MPL!!
>>
>>
>> How so?  What happens?  Got a small reproducible case?
>
> See:
>    http://lists.boost.org/boost-users/2006/01/16513.php
>
>    void trouble()
>    {
>         typedef dummy< ::boost::mpl::vector< int > > vt ;
>         typedef ::std::vector< const vt* > ct ;
>
>         boost::const_begin( ct() ) ;
>    }

This is a known issue, see
http://thread.gmane.org/gmane.comp.lib.boost.devel/115368.  I'll try
to fix this for 1.34.

>
> (though I don't know whether or not this GCC behavior is conforming.)

Unfortunately, until
http://www.open-std.org/jtc1/sc22/wg21/prot/14882fdis/n1729.html#218
is resolved favorably for us, it is.

--
Aleksey Gurtovoy
MetaCommunications Engineering
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Range] breaking update pending

Thorsten Ottosen
In reply to this post by David Abrahams
David Abrahams wrote:

 > MB <[hidden email]> writes:
 >
 >
 >> Thorsten Ottosen wrote:
 >>
 >>> Dear All,
 >>>
 >>> I have been trimming boost.range to incorporate the changes we have
been
 >>> discussing some time ago.
 >>>
 >>> These changes will break many uses of the library. Inside boost
this will affect
 >>>
 >>> Boost.foreach
 >>> Boost.string algo
 >>> Boost.iostreams (*)
 >>>
 >>> (*) I don't this will break
 >>>
 >>> The list of major changes is the follwing:
 >>>
 >>> 1. ADL hooks renamed boost_range_begin -> range_begin,
 >>>                      boost_range_end -> range_end
 >>
 >>
 >> Why was such short name accepted??
 >> Even 'const_begin' that calls unqualified 'begin' breaks down
Boost.MPL!!


This was a bug. In the new version there is no unqualified
call to begin(), end(), size() and empty().

 >
 > How so?  What happens?  Got a small reproducible case?
 >

GCC ADL looks up a class named "end" too. Old story.

 >>> 2. ADL hook boost_range_size removed; boost::size(rng) now requires
 >>>    RandomAccessIterators to guarantee O(1) complexity.
 >>>
 >>> 3. range_result_iterator renamed range_iterator and range_iterator
renamed mutable_iterator. The correct way to spell const_iterator<T> is
now iterator<const T>.
 >>
 >>
 >> range_result_iterator is alive? If so, it's nice. :-)


It's dead, sort of, or that was the intention. It's behavior is now
modelled by range_iterator.

 >>> 4. intrinsic string support removed. instead a header
as_literal.hpp is previded with a small utility for use in string
algorithms.
 >>
 >>
 >> FWIW, I experienced "Range adaptor syntax" could make it prettier.
 >
 >
 >
 > Thorsten, did you consider providing a backward compatibility layer
 > for the transition?


Yes, but I don't have a good way to do this. putting the old version in,
say, boost/range/v1 was rejected because of ODR problems.

Do you have any ideas?

-Thorsten


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Range] breaking update pending

Thorsten Ottosen
In reply to this post by Aleksey Gurtovoy
Aleksey Gurtovoy wrote:

 > MB writes:
 >
 >> David Abrahams wrote:
 >>
 >>> MB <[hidden email]> writes:
 >>>
 >>>> Even 'const_begin' that calls unqualified 'begin' breaks down
Boost.MPL!!
 >>>
 >>>
 >>>
 >>> How so?  What happens?  Got a small reproducible case?
 >>
 >>
 >> See:
 >>   http://lists.boost.org/boost-users/2006/01/16513.php
 >>
 >>   void trouble()
 >>   {
 >>        typedef dummy< ::boost::mpl::vector< int > > vt ;
 >>        typedef ::std::vector< const vt* > ct ;
 >>
 >>        boost::const_begin( ct() ) ;
 >>   }


Just to clarify, this was a bug in the current version of boost.range.

In the new version , no call to begin(), end(), size(), and empty()
is unqualified.


-Thorsten

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Range] breaking update pending

David Abrahams
In reply to this post by Thorsten Ottosen
Thorsten Ottosen <[hidden email]> writes:

> David Abrahams wrote:
>
>  > MB <[hidden email]> writes:
>  >
>  >
>  >> Thorsten Ottosen wrote:
>  >>
>  >>> Dear All,
>  >>>
>  >>> I have been trimming boost.range to incorporate the changes we have
> been
>  >>> discussing some time ago.
>  >>>
>  >>> These changes will break many uses of the library. Inside boost
> this will affect
>  >>>
>  >>> Boost.foreach
>  >>> Boost.string algo
>  >>> Boost.iostreams (*)
>  >>>
>  >>> (*) I don't this will break
>  >>>
>  >>> The list of major changes is the follwing:
>  >>>
>  >>> 1. ADL hooks renamed boost_range_begin -> range_begin,
>  >>>                      boost_range_end -> range_end
>  >>
>  >>
>  >> Why was such short name accepted??
>  >> Even 'const_begin' that calls unqualified 'begin' breaks down
> Boost.MPL!!
>
>
> This was a bug. In the new version there is no unqualified
> call to begin(), end(), size() and empty().
>
>  >
>  > How so?  What happens?  Got a small reproducible case?
>  >
>
> GCC ADL looks up a class named "end" too. Old story.

You need to read more carefully.  A change from boost_range_end to
range_end would not cause any interaction with the name "end."

>  > Thorsten, did you consider providing a backward compatibility layer
>  > for the transition?
>
>
> Yes, but I don't have a good way to do this. putting the old version in,
> say, boost/range/v1 was rejected because of ODR problems.
>
> Do you have any ideas?

I was thinking of a system that would (as much as possible) keep old
code working, without substituting different definitions.  For
example, you could keep boost_range_begin and dispatch to range_begin.
I'm not sure of the details, or how well it could work, but I thought
it was worth considering.  When thinking about it, keep in mind that
we can detect the presence of an overloaded function that is supposed
to be found via ADL.  I don't know if that helps, but it might.

Cheers,
Dave

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Range] breaking update pending

Thorsten Ottosen
David Abrahams wrote:
> Thorsten Ottosen <[hidden email]> writes:

>> >> Why was such short name accepted??
>> >> Even 'const_begin' that calls unqualified 'begin' breaks down
>>Boost.MPL!!
>>
>>
>>This was a bug. In the new version there is no unqualified
>>call to begin(), end(), size() and empty().
>>
>> >
>> > How so?  What happens?  Got a small reproducible case?
>> >
>>
>>GCC ADL looks up a class named "end" too. Old story.
>
>
> You need to read more carefully.  A change from boost_range_end to
> range_end would not cause any interaction with the name "end."

no, but const_begin() called begin() unqualified. similarly for const_end().

-Thorsten

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Range] breaking update pending

David Abrahams
Thorsten Ottosen <[hidden email]> writes:

> David Abrahams wrote:
>> Thorsten Ottosen <[hidden email]> writes:
>
>>> >> Why was such short name accepted??
>>> >> Even 'const_begin' that calls unqualified 'begin' breaks down
>>>Boost.MPL!!
>>>
>>>
>>>This was a bug. In the new version there is no unqualified
>>>call to begin(), end(), size() and empty().
>>>
>>> >
>>> > How so?  What happens?  Got a small reproducible case?
>>> >
>>>
>>>GCC ADL looks up a class named "end" too. Old story.
>>
>>
>> You need to read more carefully.  A change from boost_range_end to
>> range_end would not cause any interaction with the name "end."
>
> no, but const_begin() called begin() unqualified. similarly for const_end().

The claim was that a name change caused breakage.  Note that my
questions, "How so?...", etc. were posed to the OP of that claim, not
to your assertion that there were incorrect unqualified calls in the
library.  Your response to my question does not address it.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Range] breaking update pending

Shunsuke Sogame
In reply to this post by Thorsten Ottosen
Thorsten Ottosen wrote:

> David Abrahams wrote:
>
>  > MB <[hidden email]> writes:
>  >
>  >
>  >> Thorsten Ottosen wrote:
>  >>
>  >>> Dear All,
>  >>>
>  >>> I have been trimming boost.range to incorporate the changes we have
> been
>  >>> discussing some time ago.
>  >>>
>  >>> These changes will break many uses of the library. Inside boost
> this will affect
>  >>>
>  >>> Boost.foreach
>  >>> Boost.string algo
>  >>> Boost.iostreams (*)
>  >>>
>  >>> (*) I don't this will break
>  >>>
>  >>> The list of major changes is the follwing:
>  >>>
>  >>> 1. ADL hooks renamed boost_range_begin -> range_begin,
>  >>>                      boost_range_end -> range_end
>  >>
>  >>
>  >> Why was such short name accepted??
>  >> Even 'const_begin' that calls unqualified 'begin' breaks down
> Boost.MPL!!
>
>
> This was a bug. In the new version there is no unqualified
> call to begin(), end(), size() and empty().
>
>  >
>  > How so?  What happens?  Got a small reproducible case?
>  >
>
> GCC ADL looks up a class named "end" too. Old story.
>
>  >>> 2. ADL hook boost_range_size removed; boost::size(rng) now requires
>  >>>    RandomAccessIterators to guarantee O(1) complexity.
>  >>>
>  >>> 3. range_result_iterator renamed range_iterator and range_iterator
> renamed mutable_iterator. The correct way to spell const_iterator<T> is
> now iterator<const T>.
>  >>
>  >>
>  >> range_result_iterator is alive? If so, it's nice. :-)
>
>
> It's dead, sort of, or that was the intention. It's behavior is now
> modelled by range_iterator.

You mean all the customization way is deprecated?

>  >>> 4. intrinsic string support removed. instead a header
> as_literal.hpp is previded with a small utility for use in string
> algorithms.
>  >>
>  >>
>  >> FWIW, I experienced "Range adaptor syntax" could make it prettier.
>  >
>  >
>  >
>  > Thorsten, did you consider providing a backward compatibility layer
>  > for the transition?
>
>
> Yes, but I don't have a good way to do this. putting the old version in,
> say, boost/range/v1 was rejected because of ODR problems.
>
> Do you have any ideas?

Ideally, Boost.Range v2 is needed, which has all the range-style algorithms,
all the range adaptors, class-template-based customization using tag-dispatching,
supports also ADL customization, can play with Boost.IOStreams,
and throws away legacy compilers! :-)

   range::copy(file_rng|range::filtered(is_even()), out);
   result_of<range::begin_function(int[10])>::type first = range::begin(array);

I already find Boost.Sequence. :-)

Regards,
MB

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Range] breaking update pending

Thorsten Ottosen
MB wrote:
> Thorsten Ottosen wrote:

>> >> range_result_iterator is alive? If so, it's nice. :-)
>>
>>
>>It's dead, sort of, or that was the intention. It's behavior is now
>>modelled by range_iterator.
>
>
> You mean all the customization way is deprecated?

no, it has been renamed to range_iterator and the former range_iterator
is now called mutable_iterator.

> Ideally, Boost.Range v2 is needed, which has all the range-style algorithms,
> all the range adaptors, class-template-based customization using tag-dispatching,
> supports also ADL customization, can play with Boost.IOStreams,
> and throws away legacy compilers! :-)
>
>    range::copy(file_rng|range::filtered(is_even()), out);

Working on this an nearly done. Hopefully a short mini-review can be
made so to put it in this release. The above would be wriiten (I think)

namspace br = boost::ranges;

br::copy( a_rng | br::filtered( is_even() ), out );

-Thorsten

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Range] breaking update pending

Shunsuke Sogame
Thorsten Ottosen wrote:

> MB wrote:
>
>>Thorsten Ottosen wrote:
>
>
>>>>>range_result_iterator is alive? If so, it's nice. :-)
>>>
>>>
>>>It's dead, sort of, or that was the intention. It's behavior is now
>>>modelled by range_iterator.
>>
>>
>>You mean all the customization way is deprecated?
>
>
> no, it has been renamed to range_iterator and the former range_iterator
> is now called mutable_iterator.

But, range_iterator has already been specialized by
range implementators.

>>Ideally, Boost.Range v2 is needed, which has all the range-style algorithms,
>>all the range adaptors, class-template-based customization using tag-dispatching,
>>supports also ADL customization, can play with Boost.IOStreams,
>>and throws away legacy compilers! :-)
>>
>>   range::copy(file_rng|range::filtered(is_even()), out);
>
>
> Working on this an nearly done. Hopefully a short mini-review can be
> made so to put it in this release. The above would be wriiten (I think)
>
> namspace br = boost::ranges;
>
> br::copy( a_rng | br::filtered( is_even() ), out );

Nicely!
Range revolution has begun! :-)

I wonder why the current version that works enough
must be changed with pains, when you are making the new striking range library.


Regards,
MB

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Range] breaking update pending

Thorsten Ottosen
MB wrote:

 > Thorsten Ottosen wrote:


 >> no, it has been renamed to range_iterator and the former
range_iterator is now called mutable_iterator.
 >
 >
 >
 > But, range_iterator has already been specialized by
 > range implementators.


right, that is why it is a breaking update.

 >> Working on this an nearly done. Hopefully a short mini-review can be
 >> made so to put it in this release. The above would be wriiten (I think)
 >>
 >> namspace br = boost::ranges;
 >>
 >> br::copy( a_rng | br::filtered( is_even() ), out );
 >
 >
 >
 > Nicely!
 > Range revolution has begun! :-)
 >
 > I wonder why the current version that works enough
 > must be changed with pains, when you are making the new striking
range library.


well, it is always unfortunate when the design is not optimal in the
first version of a library, but I guess that is just life.

something along the follwing might work:

find . -name "*.cpp" | xargs sed -e --in-place
"s/range_iterator</mutable_iterator</"

find . -name "*.cpp" | xargs sed -e --in-place
"s/range_result_iterator</range_iterator</"

etc

-Thorsten

BTW: please use your real name when posting

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Range] breaking update pending

Shunsuke Sogame
Thorsten Ottosen wrote:

> MB wrote:
>
>  > Thorsten Ottosen wrote:
>
>
>  >> no, it has been renamed to range_iterator and the former
> range_iterator is now called mutable_iterator.
>  >
>  >
>  >
>  > But, range_iterator has already been specialized by
>  > range implementators.
>
>
> right, that is why it is a breaking update.

It is possible to hook 'range_iterator' from user specializations?

   template< class T >
   struct range_iterator<const T> : range_const_iterator<T> { };

Fortunately, Boost.Range documentation doesn't say
'range_iterator< const Foo::Pair<T> >' must be specialized.
User 'range_iterator' specializations still work.

 From the point of client view,
I have never called 'range_iterator',
while I called 'range_result_iterator' 159 times.


As for 'range_result_iterator', there is no reason why it should be removed.
If it were removed, I would add just:

   // legacy name of range_iterator
   template< class Range >
   struct range_result_iterator : range_iterator<Range> { };


As for 'boost_range_begin', the change is rather dangerous.
Please do google "range_end".


Thus, no problem breaks except for 'char*', doesn't it?


> BTW: please use your real name when posting
Formal rule?
If so, this should be the final post...


Regards,
MB

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Range] breaking update pending

Thorsten Ottosen
MB wrote:

> Thorsten Ottosen wrote:
>
>>MB wrote:
>>
>> > Thorsten Ottosen wrote:
>>
>>
>> >> no, it has been renamed to range_iterator and the former
>>range_iterator is now called mutable_iterator.
>> >
>> >
>> >
>> > But, range_iterator has already been specialized by
>> > range implementators.
>>
>>
>>right, that is why it is a breaking update.
>
>
> It is possible to hook 'range_iterator' from user specializations?
>
>    template< class T >
>    struct range_iterator<const T> : range_const_iterator<T> { };
>
> Fortunately, Boost.Range documentation doesn't say
> 'range_iterator< const Foo::Pair<T> >' must be specialized.
> User 'range_iterator' specializations still work.

I'm not sure what you're saying here. Could you explain?

>  From the point of client view,
> I have never called 'range_iterator',
> while I called 'range_result_iterator' 159 times.
>
>
> As for 'range_result_iterator', there is no reason why it should be removed.
> If it were removed, I would add just:
>
>    // legacy name of range_iterator
>    template< class Range >
>    struct range_result_iterator : range_iterator<Range> { };

right, this could be done to provide some form of backwards compatibility.

> As for 'boost_range_begin', the change is rather dangerous.
> Please do google "range_end".

I don't get a lot of hits that uses range_end as a function.

>
> Thus, no problem breaks except for 'char*', doesn't it?
>

well,

- char[N] returns the same as T[N]
- range_iterator is named range_mutable_iterator.

>>BTW: please use your real name when posting
>
> Formal rule?
> If so, this should be the final post...

I don't think so, but I like to know whom I'm speaking with.

-Thorsten

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Range] breaking update pending

Shunsuke Sogame
Thorsten Ottosen wrote:

>>It is possible to hook 'range_iterator' from user specializations?
>>
>>   template< class T >
>>   struct range_iterator<const T> : range_const_iterator<T> { };
>>
>>Fortunately, Boost.Range documentation doesn't say
>>'range_iterator< const Foo::Pair<T> >' must be specialized.
>>User 'range_iterator' specializations still work.
>
>
> I'm not sure what you're saying here. Could you explain?

Sorry, please forget this code. I was confused or drunken.
I had ever specialized 'range_iterator<const MyX>' to return "mutable" iterator,
before I removed it some time ago.

I see "range_iterator -> range_mutable_iterator" change
doesn't break any current user customizations.
Am I right?


>> From the point of client view,
>>I have never called 'range_iterator',
>>while I called 'range_result_iterator' 159 times.
>>
>>
>>As for 'range_result_iterator', there is no reason why it should be removed.
>>If it were removed, I would add just:
>>
>>   // legacy name of range_iterator
>>   template< class Range >
>>   struct range_result_iterator : range_iterator<Range> { };
>
>
> right, this could be done to provide some form of backwards compatibility.
>
>
>>As for 'boost_range_begin', the change is rather dangerous.
>>Please do google "range_end".
>
>
> I don't get a lot of hits that uses range_end as a function.

If 'range_end' is a function, it is rather lucky.
Once "int range_end;" is defined, I think there is no workaround.
I read the long discussion why 'boost_range_begin' was born.
Did I overlook another discussion about the birth of 'range_begin'?


>>Thus, no problem breaks except for 'char*', doesn't it?
>>
>
>
> well,
>
> - char[N] returns the same as T[N]
> - range_iterator is named range_mutable_iterator.
>
>
>>>BTW: please use your real name when posting
>>
>>Formal rule?
>>If so, this should be the final post...
>
>
> I don't think so, but I like to know whom I'm speaking with.

Nice to meet you and the world.


Regards,
Shunsuke Sogame

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Range] breaking update pending

Thorsten Ottosen
MB wrote:

> Thorsten Ottosen wrote:
>
>>>It is possible to hook 'range_iterator' from user specializations?
>>>
>>>  template< class T >
>>>  struct range_iterator<const T> : range_const_iterator<T> { };
>>>
>>>Fortunately, Boost.Range documentation doesn't say
>>>'range_iterator< const Foo::Pair<T> >' must be specialized.
>>>User 'range_iterator' specializations still work.
>>
>>
>>I'm not sure what you're saying here. Could you explain?
>
>
> Sorry, please forget this code. I was confused or drunken.
> I had ever specialized 'range_iterator<const MyX>' to return "mutable" iterator,
> before I removed it some time ago.
>
> I see "range_iterator -> range_mutable_iterator" change
> doesn't break any current user customizations.
> Am I right?

well, it could break any specialization of range_iterator.

I'll see if I can avoid it, but I won't promise that I can.


>>>As for 'boost_range_begin', the change is rather dangerous.
>>>Please do google "range_end".
>>
>>
>>I don't get a lot of hits that uses range_end as a function.
>
>
> If 'range_end' is a function, it is rather lucky.
> Once "int range_end;" is defined, I think there is no workaround.

right, if you have a namespace static variable called range_end, then
you can't define a function of the same name in that namespace. But what
are the chances of that? remember there is no problem with

{
   // some scope
   int range_end;
   boost::end(rng);
}

> I read the long discussion why 'boost_range_begin' was born.
> Did I overlook another discussion about the birth of 'range_begin'?

maybe, there was some discussion about the problems of tying
a concept to a library name. the range concept exists out-side of boost
and any type T conforms to it if it implements range_begin(T&) and
range_end(T&) etc.

>>>>BTW: please use your real name when posting
>>>
>>>Formal rule?
>>>If so, this should be the final post...
>>
>>
>>I don't think so, but I like to know whom I'm speaking with.
>
>
> Nice to meet you and the world.
>
>
> Regards,
> Shunsuke Sogame

Nice to meet you too, Shunsuke.

And welcome to boost :-)

best regards

Thorsten

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Range] breaking update pending

Shunsuke Sogame
Thorsten Ottosen wrote:

> MB wrote:
>
>>Thorsten Ottosen wrote:
>>
>>
>>>>It is possible to hook 'range_iterator' from user specializations?
>>>>
>>>> template< class T >
>>>> struct range_iterator<const T> : range_const_iterator<T> { };
>>>>
>>>>Fortunately, Boost.Range documentation doesn't say
>>>>'range_iterator< const Foo::Pair<T> >' must be specialized.
>>>>User 'range_iterator' specializations still work.
>>>
>>>
>>>I'm not sure what you're saying here. Could you explain?
>>
>>
>>Sorry, please forget this code. I was confused or drunken.
>>I had ever specialized 'range_iterator<const MyX>' to return "mutable" iterator,
>>before I removed it some time ago.
>>
>>I see "range_iterator -> range_mutable_iterator" change
>>doesn't break any current user customizations.
>>Am I right?
>
>
> well, it could break any specialization of range_iterator.
>
> I'll see if I can avoid it, but I won't promise that I can.
>
>
>
>>>>As for 'boost_range_begin', the change is rather dangerous.
>>>>Please do google "range_end".
>>>
>>>
>>>I don't get a lot of hits that uses range_end as a function.
>>
>>
>>If 'range_end' is a function, it is rather lucky.
>>Once "int range_end;" is defined, I think there is no workaround.
>
>
> right, if you have a namespace static variable called range_end, then
> you can't define a function of the same name in that namespace. But what
> are the chances of that? remember there is no problem with
>
> {
>    // some scope
>    int range_end;
>    boost::end(rng);
> }

I already define a function as a functor to support 'result_of':

   const range_end_function& range_end = ...;


>>I read the long discussion why 'boost_range_begin' was born.
>>Did I overlook another discussion about the birth of 'range_begin'?
>
>
> maybe, there was some discussion about the problems of tying
> a concept to a library name. the range concept exists out-side of boost
> and any type T conforms to it if it implements range_begin(T&) and
> range_end(T&) etc.

Where the range concept belongs? "Global"?

I'm maybe an worrier, struggling with ADL invasions.
But short names conflict.


Regards,
Shunsuke Sogame

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [Range] breaking update pending

Thorsten Ottosen
Shunsuke Sogame wrote:
> Thorsten Ottosen wrote:
>

>>>I read the long discussion why 'boost_range_begin' was born.
>>>Did I overlook another discussion about the birth of 'range_begin'?
>>
>>
>>maybe, there was some discussion about the problems of tying
>>a concept to a library name. the range concept exists out-side of boost
>>and any type T conforms to it if it implements range_begin(T&) and
>>range_end(T&) etc.
>
>
> Where the range concept belongs? "Global"?

yep, in the sense that customization points are not tied to
a particular library.

> I'm maybe an worrier, struggling with ADL invasions.
> But short names conflict.

true, that is why begin()/end() were abadened.

-Thorsten

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
12