Hi, Any progress on these tickets? Would be nice to have a solution. size() return type should be size_type, not difference_type: https://svn.boost.org/trac/boost/ticket/5971 data() for iterator_range: https://svn.boost.org/trac/boost/ticket/5930 Greetings, -- Olaf
Den 01-12-2011 14:02, Olaf van der Spek skrev:
Hi,
Any progress on these tickets? Would be nice to have a solution.
size() return type should be size_type, not difference_type: https://svn.boost.org/trac/boost/ticket/5971
data() for iterator_range: https://svn.boost.org/trac/boost/ticket/5930
If Neil agrees on them and their resolution, I can implement them. -Thorsten
On Thu, Dec 1, 2011 at 6:45 PM, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Den 01-12-2011 14:02, Olaf van der Spek skrev:
Hi,
Any progress on these tickets? Would be nice to have a solution.
size() return type should be size_type, not difference_type: https://svn.boost.org/trac/boost/ticket/5971
data() for iterator_range: https://svn.boost.org/trac/boost/ticket/5930
If Neil agrees on them and their resolution, I can implement them.
Neil? -- Olaf
On Tue, Dec 6, 2011 at 11:26 AM, Olaf van der Spek <ml@vdspek.org> wrote:
On Thu, Dec 1, 2011 at 6:45 PM, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Den 01-12-2011 14:02, Olaf van der Spek skrev:
Hi,
Any progress on these tickets? Would be nice to have a solution.
size() return type should be size_type, not difference_type: https://svn.boost.org/trac/boost/ticket/5971
data() for iterator_range: https://svn.boost.org/trac/boost/ticket/5930
If Neil agrees on them and their resolution, I can implement them.
Neil?
Please accept my apologies for the delay in responding. I've been in read-only mode for a while about these. I think that having the result be unsigned does make sense and the most compelling argument, for me, is that a standard container is also a model of a one of the Range Concepts. I'm completely happy for Thorsten to make this change. I would be able to do it in the next couple of weeks once I have dug myself out of the mountain of work I have managed to accumulate! Thorsten will probably be able to make these changes sooner than I, I suspect. I am not happy with the inclusion of data() being a member function that conditionally becomes a part of the iterator_range interface in a subset of conditions that we detect as being contiguous. I don't feel this improves the approximation with standard containers in the same manner that returning an unsigned type from size does. The standard containers either do or don't provide data() regardless of the template arguments use in the instantiation. Looking more formally at the problem I regard any property of the underlying types that adds or subtracts functions as something that should be modelled as a proper Concept. I have an implementation that formalizes contiguous ranges and higher-dimensional ranges that I have been acquiring real-world experience with. My intent is to put this into Boost.Range once I am happy with the interface and the Concepts.
-- Olaf
Thanks for bringing this topic up. Regards, Neil Groves
[off-topic]
I have an implementation that formalizes contiguous ranges and higher-dimensional ranges that I have been acquiring real-world experience with. My intent is to put this into Boost.Range once I am happy with the interface and the Concepts.
This sounds interesting. Is it available somewhere? Thanks, Nate
On Wed, Dec 7, 2011 at 9:47 PM, Neil Groves <neil@grovescomputing.com> wrote:
Please accept my apologies for the delay in responding. I've been in read-only mode for a while about these. I think that having the result be unsigned does make sense and the most compelling argument, for me, is that a standard container is also a model of a one of the Range Concepts. I'm completely happy for Thorsten to make this change. I would be able to do it in the next couple of weeks once I have dug myself out of the mountain of work I have managed to accumulate! Thorsten will probably be able to make these changes sooner than I, I suspect.
I've requested an iterator_size trait: https://svn.boost.org/trac/boost/ticket/6240 Maybe that could be used once implemented.
I am not happy with the inclusion of data() being a member function that conditionally becomes a part of the iterator_range interface in a subset of conditions that we detect as being contiguous. I don't feel this improves the approximation with standard containers in the same manner that returning an unsigned type from size does. The standard containers either do or don't provide data() regardless of the template arguments use in the instantiation. Looking more formally at the problem I regard any property of the underlying types that adds or subtracts functions as something that should be modelled as a proper Concept. I have an implementation that formalizes contiguous ranges and higher-dimensional ranges that I have been acquiring real-world experience with. My intent is to put this into Boost.Range once I am happy with the interface and the Concepts.
Something like contiguous_range or ptr_range? It'd also be nice if you could easily construct a ptr range from array, string and vector. Any rough ETA? -- Olaf
On Thu, Dec 1, 2011 at 6:45 PM, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Den 01-12-2011 14:02, Olaf van der Spek skrev:
Hi,
Any progress on these tickets? Would be nice to have a solution.
size() return type should be size_type, not difference_type: https://svn.boost.org/trac/boost/ticket/5971
data() for iterator_range: https://svn.boost.org/trac/boost/ticket/5930
If Neil agrees on them and their resolution, I can implement them.
Great. Any updates? Olaf
On Thu, Dec 22, 2011 at 11:27 PM, Olaf van der Spek <ml@vdspek.org> wrote:
On Thu, Dec 1, 2011 at 6:45 PM, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Den 01-12-2011 14:02, Olaf van der Spek skrev:
Hi,
Any progress on these tickets? Would be nice to have a solution.
size() return type should be size_type, not difference_type: https://svn.boost.org/trac/boost/ticket/5971
data() for iterator_range: https://svn.boost.org/trac/boost/ticket/5930
If Neil agrees on them and their resolution, I can implement them.
Great. Any updates?
Thorsten? -- Olaf
On Thu, Jan 12, 2012 at 10:38 AM, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
If Neil agrees on them and their resolution, I can implement them.
Great. Any updates?
Thorsten?
Please be patient.
I am. :p Reason I ask is 1.49 branch closing in a few days. Olaf
On Fri, Jan 13, 2012 at 8:27 PM, Olaf van der Spek <ml@vdspek.org> wrote:
On Thu, Jan 12, 2012 at 10:38 AM, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
If Neil agrees on them and their resolution, I can implement them.
Great. Any updates?
Thorsten?
Please be patient.
I am. :p Reason I ask is 1.49 branch closing in a few days.
How patient should one be? Will 1.49 be released without a fix? -- Olaf
Den 31-01-2012 15:18, Olaf van der Spek skrev:
On Fri, Jan 13, 2012 at 8:27 PM, Olaf van der Spek<ml@vdspek.org> wrote:
On Thu, Jan 12, 2012 at 10:38 AM, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
If Neil agrees on them and their resolution, I can implement them.
Great. Any updates?
Thorsten?
Please be patient.
I am. :p Reason I ask is 1.49 branch closing in a few days.
How patient should one be? Will 1.49 be released without a fix?
yeah, its a breaking change. -Thorsten
On Thu, Feb 2, 2012 at 11:42 AM, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Please be patient.
I am. :p Reason I ask is 1.49 branch closing in a few days.
How patient should one be? Will 1.49 be released without a fix?
yeah, its a breaking change.
It's a fixing change for me. :p But what's your point? I don't get why it wasn't possible to get the fix into 1.49. -- Olaf
Den 02-02-2012 13:30, Olaf van der Spek skrev:
On Thu, Feb 2, 2012 at 11:42 AM, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Please be patient.
I am. :p Reason I ask is 1.49 branch closing in a few days.
How patient should one be? Will 1.49 be released without a fix?
yeah, its a breaking change.
It's a fixing change for me. :p
But what's your point?
Its too late to do such a change that can potentially make comping code not compile. -Thorsten
On Thu, Feb 2, 2012 at 1:35 PM, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Den 02-02-2012 13:30, Olaf van der Spek skrev:
On Thu, Feb 2, 2012 at 11:42 AM, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Please be patient.
I am. :p Reason I ask is 1.49 branch closing in a few days.
How patient should one be? Will 1.49 be released without a fix?
yeah, its a breaking change.
It's a fixing change for me. :p
But what's your point?
Its too late to do such a change that can potentially make comping code not compile.
Would now be a good time to make this change? -- Olaf
Would now be a good time to make this change? -- Olaf
Yes, I am making the change at this very moment. I'm looking at fixing the defects that have been reported and doing this change today and possibly early into the week. It has taken too long. I aim to be more frequently checking trac from now on. Regards, Neil Groves
participants (4)
-
Nathan Ridge -
Neil Groves -
Olaf van der Spek -
Thorsten Ottosen