Standard library Technical Report 2 proposals for Boost libraries
The C++ committee hasn't decided whether to do a TR2 or to move directly on to the next standard. Either way, there will be a call for library proposals, but the details will be up in the air at least until the next meeting, which will be in Kona, Hawaii, in February. For the moment, the term "TR2" is being used as a surrogate for moving the standard library forward regardless of exact details. In discussions, library working group (LWG) members have made it clear they want a filesystem library based on Boost.Filesystem, and a networking library based on Boost Asio. Individual members of the committee have voiced interest in other Boost libraries, large and small. If you are a Boost developer (or user), and there is a Boost library you would like to see proposed for TR2, now is a good time to start thinking about writing a preliminary proposal to the committee. The point of such a proposal is to gauge interest before putting in a lot of work on a full-blown proposal only to find the LWG isn't interested. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html for the original TR2 call for proposals. While the details will change, it is still a reasonable introduction to what is required. A preliminary proposal would just say "To be supplied" for the "Proposed Text for the Standard" section. It is very helpful to do at least the initial presentation of such a proposal in person. That said, John Maddock and Peter Dimov had many proposals accepted for TR1 without ever attending a standards committee meeting. If you don't plan to present a proposal in person, the best bet is to ask someone who is familiar with the library to present it. Feel free to contact me publicly or privately with questions about proposals or information about attending committee meetings, --Beman
On Mon, Nov 14, 2011 at 8:14 PM, Beman Dawes <bdawes@acm.org> wrote:
See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html for the original TR2 call for proposals. While the details will change, it is still a reasonable introduction to what is required. A preliminary proposal would just say "To be supplied" for the "Proposed Text for the Standard" section.
What's the best way to request something simple, like the addition of size_type to iterator_traits? -- Olaf
On Fri, Dec 2, 2011 at 9:45 AM, Olaf van der Spek <ml@vdspek.org> wrote:
On Mon, Nov 14, 2011 at 8:14 PM, Beman Dawes <bdawes@acm.org> wrote:
See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html for the original TR2 call for proposals. While the details will change, it is still a reasonable introduction to what is required. A preliminary proposal would just say "To be supplied" for the "Proposed Text for the Standard" section.
What's the best way to request something simple,
Committee members sometimes just open issues for really simple new feature requests, but that tends to work well only for those who attend meetings and/or are frequent contributors. A paper is probably best, even if it is very short. Papers just plain carry more weight, and are read by a wider audience.
like the addition of size_type to iterator_traits?
Out of curiosity, size_type of what? Also, iterator_traits is viewed as an anachronism by some influential committee members, both because of the lumping of multiple traits into a single class and because of the problems using the current iterator_traits with SFINAE. So you might want to consider a set of replacement traits that follows modern practice. Proposing something like that for Boost would be a good start. Incidentally, I've got a boostification of an is_iterator trait contributed by Howard Hinnant which would be a nice addition to a generic set of iterator traits. --Beman
On Mon, Dec 5, 2011 at 7:00 PM, Beman Dawes <bdawes@acm.org> wrote:
On Fri, Dec 2, 2011 at 9:45 AM, Olaf van der Spek <ml@vdspek.org> wrote:
On Mon, Nov 14, 2011 at 8:14 PM, Beman Dawes <bdawes@acm.org> wrote:
See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html for the original TR2 call for proposals. While the details will change, it is still a reasonable introduction to what is required. A preliminary proposal would just say "To be supplied" for the "Proposed Text for the Standard" section.
What's the best way to request something simple,
Committee members sometimes just open issues for really simple new feature requests, but that tends to work well only for those who attend meetings and/or are frequent contributors.
A paper is probably best, even if it is very short. Papers just plain carry more weight, and are read by a wider audience.
like the addition of size_type to iterator_traits?
Out of curiosity, size_type of what?
It's to solve the iterator_range::size() issue. So the size type for a range denoted by two iterators.
Also, iterator_traits is viewed as an anachronism by some influential committee members, both because of the lumping of multiple traits into a single class and because of the problems using the current iterator_traits with SFINAE. So you might want to consider a set of replacement traits that follows modern practice. Proposing something like that for Boost would be a good start.
I've never used iterator_traits myself and am not aware of these problems. Got any pointers? :p -- Olaf
On 6 December 2011 11:25, Olaf van der Spek <ml@vdspek.org> wrote:
On Mon, Dec 5, 2011 at 7:00 PM, Beman Dawes <bdawes@acm.org> wrote:
Also, iterator_traits is viewed as an anachronism by some influential committee members, both because of the lumping of multiple traits into a single class and because of the problems using the current iterator_traits with SFINAE. So you might want to consider a set of replacement traits that follows modern practice. Proposing something like that for Boost would be a good start.
I've never used iterator_traits myself and am not aware of these problems. Got any pointers? :p
These are considered better: http://www.boost.org/libs/iterator/doc/iterator_traits.html Separate traits which follow a common convention have proved to be useful in template meta-programming, especially when used with MPL. I'm not sure how C++11 changes things though.
On Wed, Dec 7, 2011 at 8:16 PM, Daniel James <dnljms@gmail.com> wrote:
On 6 December 2011 11:25, Olaf van der Spek <ml@vdspek.org> wrote:
On Mon, Dec 5, 2011 at 7:00 PM, Beman Dawes <bdawes@acm.org> wrote:
Also, iterator_traits is viewed as an anachronism by some influential committee members, both because of the lumping of multiple traits into a single class and because of the problems using the current iterator_traits with SFINAE. So you might want to consider a set of replacement traits that follows modern practice. Proposing something like that for Boost would be a good start.
I've never used iterator_traits myself and am not aware of these problems. Got any pointers? :p
These are considered better:
http://www.boost.org/libs/iterator/doc/iterator_traits.html
Separate traits which follow a common convention have proved to be useful in template meta-programming, especially when used with MPL. I'm not sure how C++11 changes things though.
Ticket created: https://svn.boost.org/trac/boost/ticket/6240 Are there any plans to propose Boost Iterator for TR2? -- Olaf
On Thu, Dec 8, 2011 at 11:44 AM, Olaf van der Spek <ml@vdspek.org> wrote:
On Wed, Dec 7, 2011 at 8:16 PM, Daniel James <dnljms@gmail.com> wrote:
On 6 December 2011 11:25, Olaf van der Spek <ml@vdspek.org> wrote:
On Mon, Dec 5, 2011 at 7:00 PM, Beman Dawes <bdawes@acm.org> wrote:
Also, iterator_traits is viewed as an anachronism by some influential committee members, both because of the lumping of multiple traits into a single class and because of the problems using the current iterator_traits with SFINAE. So you might want to consider a set of replacement traits that follows modern practice. Proposing something like that for Boost would be a good start.
I've never used iterator_traits myself and am not aware of these problems. Got any pointers? :p
These are considered better:
http://www.boost.org/libs/iterator/doc/iterator_traits.html
Separate traits which follow a common convention have proved to be useful in template meta-programming, especially when used with MPL. I'm not sure how C++11 changes things though.
Ticket created: https://svn.boost.org/trac/boost/ticket/6240
Are there any plans to propose Boost Iterator for TR2?
Dave? -- Olaf
on Thu Dec 15 2011, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Dec 8, 2011 at 11:44 AM, Olaf van der Spek <ml@vdspek.org> wrote:
Are there any plans to propose Boost Iterator for TR2?
Dave?
I have no plans, and it really wouldn't be appropriate in its current form. It needs a thorough going-over and probably a few design changes before it would be ready for another attempt at standardization. The standards proposals were determined to be not fully-baked enough when we submitted them the last time. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Dec 15, 2011 at 1:28 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Thu Dec 15 2011, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Dec 8, 2011 at 11:44 AM, Olaf van der Spek <ml@vdspek.org> wrote:
Are there any plans to propose Boost Iterator for TR2?
Dave?
I have no plans, and it really wouldn't be appropriate in its current form. It needs a thorough going-over and probably a few design changes before it would be ready for another attempt at standardization. The standards proposals were determined to be not fully-baked enough when we submitted them the last time.
What about https://svn.boost.org/trac/boost/ticket/6240? -- Olaf
on Thu Dec 15 2011, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Dec 15, 2011 at 1:28 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Thu Dec 15 2011, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Dec 8, 2011 at 11:44 AM, Olaf van der Spek <ml@vdspek.org> wrote:
Are there any plans to propose Boost Iterator for TR2?
Dave?
I have no plans, and it really wouldn't be appropriate in its current form. It needs a thorough going-over and probably a few design changes before it would be ready for another attempt at standardization. The standards proposals were determined to be not fully-baked enough when we submitted them the last time.
What about it? I don't see its relevance to TR2 -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Dec 15, 2011 at 1:48 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Thu Dec 15 2011, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Dec 15, 2011 at 1:28 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Thu Dec 15 2011, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Dec 8, 2011 at 11:44 AM, Olaf van der Spek <ml@vdspek.org> wrote:
Are there any plans to propose Boost Iterator for TR2?
Dave?
I have no plans, and it really wouldn't be appropriate in its current form. It needs a thorough going-over and probably a few design changes before it would be ready for another attempt at standardization. The standards proposals were determined to be not fully-baked enough when we submitted them the last time.
What about it? I don't see its relevance to TR2
The original idea was to request size_type to be added to iterator_traits. It'd properly solve the iterator_range::size() return type issue. Beman and Daniel said iterator_traits is considered less than ideal and suggested boost/iterator/iterator_traits instead. Hence my request to you. -- Olaf
on Thu Dec 15 2011, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Dec 15, 2011 at 1:48 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Thu Dec 15 2011, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Dec 15, 2011 at 1:28 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Thu Dec 15 2011, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Dec 8, 2011 at 11:44 AM, Olaf van der Spek <ml@vdspek.org> wrote:
Are there any plans to propose Boost Iterator for TR2?
Dave?
I have no plans, and it really wouldn't be appropriate in its current form. It needs a thorough going-over and probably a few design changes before it would be ready for another attempt at standardization. The standards proposals were determined to be not fully-baked enough when we submitted them the last time.
What about it? I don't see its relevance to TR2
The original idea was to request size_type to be added to iterator_traits. It'd properly solve the iterator_range::size() return type issue. Beman and Daniel said iterator_traits is considered less than ideal and suggested boost/iterator/iterator_traits instead. Hence my request to you.
Ah. Well, we should really reconsider the relevance of iterator_traits in light of the existence of decltype. I would like to take another whack at the iterators library but probably won't have time until after the Kona meeting. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Dave Abrahams wrote:
Well, we should really reconsider the relevance of iterator_traits in light of the existence of decltype. I would like to take another whack at the iterators library but probably won't have time until after the Kona meeting.
Any chance that the "Iterator Access Concepts" can be improved/extended? At <http://www.boost.org/doc/libs/1_48_0/libs/iterator/doc/iterator_concepts.html>, the following concepts are defined: Readable Iterator Writable Iterator Swappable Iterator Lvalue Iterator Would it make sense to complement the "Swappable Iterator" concept by a "Movable Iterator" concept? My current problem is that "std::inplace_merge" for gcc > 4.4 no longer works for iterators returning proxy objects: <http://lists.boost.org/MailArchives/ublas/2011/12/5123.php>. While it wouldn't be difficult to fix the code, it's unclear to me how the underlying concept should look like: Thomas Klimpel wrote:
The attached patch modifies "std::inplace_merge" appropriately...
The issues boils down to the fact that for "Forward Iterators", the return value of "*a" must be convertible to "T&" (see for example <http://stdcxx.apache.org/doc/stdlibref/iterators.html>). But a temporary value cannot bind against a non-const reference, so these requirements can only be satisfied if the return value of "*a" actually has the type "T&" (please correct me if I'm wrong). But this makes it impossible to use proxy_objects with iterators, and hence makes many actual usages of iterators (like this one here) impossible, or at least not standard conform (again, please correct me if I'm wrong).
MSVC probably has less problems with proxy objects, because it can bind temporary values against non-const references. I wonder about the required properties of "iterator_traits<_ForwardIterator>::reference" that would capture the most typical use cases of proxy objects. In the case above, "iterator_traits<_ForwardIterator>::value_type" and "iterator_traits<_ForwardIterator>::reference" are identical, and refer to a proxy class with a "non-trivial" destructor. I have the impression that there are certain "hard to formalize" expectations with respect to the lifetime of the proxy object, but I may be wrong. Did somebody (like Herb Sutter) already came up with an explanation why "smart references" are impossible in C++03? Then I could stop trying to figure which requirements/concepts they would have to satisfy... Regards, Thomas
on Thu Dec 15 2011, Thomas Klimpel <Thomas.Klimpel-AT-synopsys.com> wrote:
Dave Abrahams wrote:
Well, we should really reconsider the relevance of iterator_traits in light of the existence of decltype. I would like to take another whack at the iterators library but probably won't have time until after the Kona meeting.
Any chance that the "Iterator Access Concepts" can be improved/extended? At <http://www.boost.org/doc/libs/1_48_0/libs/iterator/doc/iterator_concepts.html>, the following concepts are defined: Readable Iterator Writable Iterator Swappable Iterator Lvalue Iterator
Would it make sense to complement the "Swappable Iterator" concept by a "Movable Iterator" concept?
No! As I was saying in another message, these concepts are wrong and too granular. Note that I'm *not* arguing against any new system of concepts supporting movability. I'm just saying that the whole thing needs to be reconsidered. Read http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2758.pdf which probably has the latest work in this area.
Did somebody (like Herb Sutter) already came up with an explanation why "smart references" are impossible in C++03? Then I could stop trying to figure which requirements/concepts they would have to satisfy...
Well... there's always the lack of an operator.(); that's everyone's favorite reason. IMO operator.() doesn't really solve the problem: template <class T> void f(T,T); iterator_traits<I>::value_type v; f(v, *it); // no matching overload if *it is a proxy -- Dave Abrahams BoostPro Computing http://www.boostpro.com
on Thu Dec 15 2011, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Dec 15, 2011 at 1:48 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Thu Dec 15 2011, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Dec 15, 2011 at 1:28 PM, Dave Abrahams <dave@boostpro.com> wrote:
on Thu Dec 15 2011, Olaf van der Spek <ml-AT-vdspek.org> wrote:
On Thu, Dec 8, 2011 at 11:44 AM, Olaf van der Spek <ml@vdspek.org> wrote:
Are there any plans to propose Boost Iterator for TR2?
Dave?
I have no plans, and it really wouldn't be appropriate in its current form. It needs a thorough going-over and probably a few design changes before it would be ready for another attempt at standardization. The standards proposals were determined to be not fully-baked enough when we submitted them the last time.
What about it? I don't see its relevance to TR2
The original idea was to request size_type to be added to iterator_traits. It'd properly solve the iterator_range::size() return type issue. Beman and Daniel said iterator_traits is considered less than ideal and suggested boost/iterator/iterator_traits instead. Hence my request to you.
Huh. Well boost/iterator/iterator_traits is only more ideal when you have a less-than-ideal compiler or standard library. Otherwise it just dispatches to std::iterator_traits. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Dec 15, 2011 at 4:28 AM, Dave Abrahams <dave@boostpro.com> wrote:
On Thu, Dec 8, 2011 at 11:44 AM, Olaf van der Spek <ml@vdspek.org> wrote:
Are there any plans to propose Boost Iterator for TR2?
I have no plans, and it really wouldn't be appropriate in its current form. It needs a thorough going-over and probably a few design changes before it would be ready for another attempt at standardization. The standards proposals were determined to be not fully-baked enough when we submitted them the last time.
I wonder, Dave, when you get a chance, if you can elaborate on this. - Jeff
on Fri Dec 16 2011, "Jeffrey Lee Hellrung, Jr." <jeffrey.hellrung-AT-gmail.com> wrote:
On Thu, Dec 15, 2011 at 4:28 AM, Dave Abrahams <dave@boostpro.com> wrote:
On Thu, Dec 8, 2011 at 11:44 AM, Olaf van der Spek <ml@vdspek.org> wrote:
Are there any plans to propose Boost Iterator for TR2?
I have no plans, and it really wouldn't be appropriate in its current form. It needs a thorough going-over and probably a few design changes before it would be ready for another attempt at standardization. The standards proposals were determined to be not fully-baked enough when we submitted them the last time.
I wonder, Dave, when you get a chance, if you can elaborate on this.
There are a number of issues I can think of just off the top of my head. The rest are probably evident from looking at Trac tickets: * The concepts are wrong, in an abstract sense. They're too granular and not based on the needs of real algorithms. C++11 either got or was about-to-get-before-concepts-were-pulled new iterator concepts that should be used * There's an adaptability hook that Robert Ramey has wanted for years and I think it should be implemented * C++11 features should be exploited in any new design, especially if it's going to be proposed for TR2 * I think maybe we don't yet understand how to specify a component as flexible and default-heavy as iterator_facade at a level of rigor that's appropriate for the standard. It may be that the defaults should be computed much more simply than they are. HTH, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
If you are a Boost developer (or user), and there is a Boost library you would like to see proposed for TR2, now is a good time to start thinking about writing a preliminary proposal to the committee.
Hi Beman, I think the addition of the operator traits to the type trait library are typically good for proposal. However I wonder if it would need ALL operator traits to be implemented (today, only 37 are implemented). Your thoughts? Frédéric
2011/12/2 Frédéric Bron <frederic.bron@m4x.org>:
I think the addition of the operator traits to the type trait library are typically good for proposal. However I wonder if it would need ALL operator traits to be implemented (today, only 37 are implemented). Your thoughts?
An existing implementation, particularly one that is available for inspection, increases confidence that a proposal is well thought out and implementable. That said, type traits are often simple enough that there isn't any question of implement-ability. But the question may come up as to why some haven't been implemented? Do they require compiler support, for example? You might sound out LWG members who are interested in type traits for their opinions. Contact me privately for the names and email address of several who might be interested. --Beman
participants (7)
-
Beman Dawes -
Daniel James -
Dave Abrahams -
Frédéric Bron -
Jeffrey Lee Hellrung, Jr. -
Olaf van der Spek -
Thomas Klimpel