Boost libraries for 'TR2'
Hi, just out of curiosity, which Boost libraries could we expect to be proposed for the TR2 (or whatever the new C++ run for new libraries will be called)? Who is working on a concrete proposal? Which libraries would you like to be proposed? I would like myself to see between others: Accumulators, Any, Asio, DynamicBitset, Filesystem, Format, Fusion, Interprocess, Intrusive, Mpl, Optional, PointerContainer, ProgramOptions, Proto, Range, Signals, Thread (shared locks), Units and Variant. Best, Vicente
On Wed, Nov 16, 2011 at 5:30 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
Hi,
just out of curiosity, which Boost libraries could we expect to be proposed for the TR2 (or whatever the new C++ run for new libraries will be called)?
I know at least Filesystem and Dynamic Bitset are on the table for TR2.
I would like myself to see between others: Accumulators, Any, Asio, DynamicBitset, Filesystem, Format, Fusion, Interprocess, Intrusive, Mpl, Optional, PointerContainer, ProgramOptions, Proto, Range, Signals, Thread (shared locks), Units and Variant.
I don't know if Pointer Container has a point in a C++11 world, now that we can std::vector<std::unique_ptr<T>>. -- Cory Nelson http://int64.org
On Wed, Nov 16, 2011 at 6:30 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
just out of curiosity, which Boost libraries could we expect to be proposed for the TR2 (or whatever the new C++ run for new libraries will be called)?
The C++ committee, like Boost, is an all volunteer organization. That means that absolutely nothing happens unless a volunteer steps forward to do the work. So there is no expectation that any Boost libraries will go in TR2 unless volunteers appear. For complex libraries that typically means the library's developer, but for smaller libraries that could be just about anyone.
Who is working on a concrete proposal?
I'm actively working on Filesystem, and Chris Kohlhoff has said he will work on Asio, but those are the only two I'm aware of.
Which libraries would you like to be proposed?
The lack of Boost iterator_facade drives me nuts; I'd love to see someone take that on for TR2. Alisdair Meredith, the LWG chair, would like to see a proposal for Any, Optional, and Variant, IIRC. He thinks they make a nice set taken together. --Beman
Le 17/11/11 13:51, Beman Dawes a écrit :
On Wed, Nov 16, 2011 at 6:30 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
just out of curiosity, which Boost libraries could we expect to be proposed for the TR2 (or whatever the new C++ run for new libraries will be called)? The C++ committee, like Boost, is an all volunteer organization. That means that absolutely nothing happens unless a volunteer steps forward to do the work. So there is no expectation that any Boost libraries will go in TR2 unless volunteers appear. For complex libraries that typically means the library's developer, but for smaller libraries that could be just about anyone. Yes. It is like that that I understood it works. I was requesting for authors that are thinking in making concrete proposals. Who is working on a concrete proposal? I'm actively working on Filesystem, and Chris Kohlhoff has said he will work on Asio, but those are the only two I'm aware of. I remember that there were proposal for Signal and Slots, LexicalCast and Shared memory. Will the authors continue theirs proposals?
Which libraries would you like to be proposed? The lack of Boost iterator_facade drives me nuts; I'd love to see someone take that on for TR2.
I agree this will be a simple and good addition.
Alisdair Meredith, the LWG chair, would like to see a proposal for Any, Optional, and Variant, IIRC. He thinks they make a nice set taken together.
Great, Vicente
"Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr> wrote in message news:4EC44785.5040401@wanadoo.fr...
Hi,
just out of curiosity, which Boost libraries could we expect to be proposed for the TR2 (or whatever the new C++ run for new libraries will be called)?
Who is working on a concrete proposal? Which libraries would you like to be proposed?
I would like myself to see between others: Accumulators, Any, Asio, DynamicBitset, Filesystem, Format, Fusion, Interprocess, Intrusive, Mpl, Optional, PointerContainer, ProgramOptions, Proto, Range, Signals, Thread (shared locks), Units and Variant.
Just out of curiosity - suppose someone had a library whose implementation depended heavily upon some other libraries like mpl, boost/iterators and boost/config. How could such a library get included in the standard if the other pre-requisite libraries aren't in the standard. I realise that the standard specifies only the interface. Taking the fusion library as just an example, it's not really practical to implement such a thing without mpl, config, pre-processor, and likely others. When I see the list above, I'm wondering if the concept of standard library isn't getting out of hand. Or maybe the standandard library needs to be divided into more than one tier- low level facilities like smart pointer and "application like" facilities like asio. More to the point, if something like fusion is added to the standard and the interface is defined - is someone actually going to re-implement it? That would seem unbelievable to me. Robert Ramey
Best, Vicente
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 11/18/2011 2:09 PM, Robert Ramey wrote:
"Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr> wrote in message news:4EC44785.5040401@wanadoo.fr...
Hi,
just out of curiosity, which Boost libraries could we expect to be proposed for the TR2 (or whatever the new C++ run for new libraries will be called)?
Who is working on a concrete proposal? Which libraries would you like to be proposed?
I would like myself to see between others: Accumulators, Any, Asio, DynamicBitset, Filesystem, Format, Fusion, Interprocess, Intrusive, Mpl, Optional, PointerContainer, ProgramOptions, Proto, Range, Signals, Thread (shared locks), Units and Variant.
Just out of curiosity - suppose someone had a library whose implementation depended heavily upon some other libraries like mpl, boost/iterators and boost/config. How could such a library get included in the standard if the other pre-requisite libraries aren't in the standard.
I realise that the standard specifies only the interface. Taking the fusion library as just an example, it's not really practical to implement such a thing without mpl, config, pre-processor, and likely others.
When I see the list above, I'm wondering if the concept of standard library isn't getting out of hand. Or maybe the standandard library needs to be divided into more than one tier- low level facilities like smart pointer and "application like" facilities like asio.
More to the point, if something like fusion is added to the standard and the interface is defined - is someone actually going to re-implement it? That would seem unbelievable to me.
FWIW, Fusion can be implemented without its current dependencies especially in the C++11 world. I've been contemplating such an exercise. Such a no-dependency library would rock in terms of compile time. Complexity shouldn't hurt either. IMO, the needed infrastructure was largely in part due to limitations of the language and difficulty in implementing certain constructs (e.g. result_of and type sequences to name two). I believe C++11 can simplify a lot of the current code. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
2011/11/17 Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>:
Hi,
just out of curiosity, which Boost libraries could we expect to be proposed for the TR2 (or whatever the new C++ run for new libraries will be called)?
Lexical_cast is proposed for TR2. (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1973.html)
Who is working on a concrete proposal? Which libraries would you like to be proposed?
It has been proposed by Kevlin Henney and Beman Dawes. I`d love to see Optional, Variant, Fusion, MPL, ProgramOptions, Interprocess, Spirit and Asio in TR2. However Spirit and Asio are very big and there is still some work going on, so I don`t think they will be in TR2. Best regards, Antony Polukhin
2011/11/17 Vicente J. Botet Escriba<vicente.botet@wanadoo.fr>:
Hi,
just out of curiosity, which Boost libraries could we expect to be proposed for the TR2 (or whatever the new C++ run for new libraries will be called)? Lexical_cast is proposed for TR2. (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1973.html) Yes, I know these links. My question is if the author will continue with
Le 22/11/11 17:25, Antony Polukhin a écrit : their current proposals or others should take the relay, but maybe this is not the correct forum.
Who is working on a concrete proposal? Which libraries would you like to be proposed? It has been proposed by Kevlin Henney and Beman Dawes.
I`d love to see Optional, Variant, Fusion, MPL, ProgramOptions, Interprocess, Spirit and Asio in TR2. However Spirit and Asio are very big and there is still some work going on, so I don`t think they will be in TR2.
In case you were not aware, there were already one proposal for ASIO: Networking Library Proposal for TR2 (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2054.pdf) Best, Vicente
Joel de Guzman wrote:
On 11/18/2011 2:09 PM, Robert Ramey wrote:
More to the point, if something like fusion is added to the standard and the interface is defined - is someone actually going to re-implement it? That would seem unbelievable to me.
FWIW, Fusion can be implemented without its current dependencies especially in the C++11 world. I've been contemplating such an exercise. Such a no-dependency library would rock in terms of compile time. Complexity shouldn't hurt either. IMO, the needed infrastructure was largely in part due to limitations of the language and difficulty in implementing certain constructs (e.g. result_of and type sequences to name two). I believe C++11 can simplify a lot of the current code.
I didn't mean to say it wasn't possilble to re-implement it. But who would want to do it? I'm currently enthralled with fusion. And you know I'm a fan of spirite. Frankly I'd prefer to see you working on the "next great thing" - whatever that might be than re-implementing fusion. But that's all really aside from my main concern. I'm really thinking of something quite different. My understanding is that the the C++ commitee defines the requirements that a C++ compiler must fulfill to be considered "conforming". On the face of it I would interprete this to mean that a compiler is "conforming" if it can parse text written in accordance with the standard and produce an executable which will produce the expected results. But some time ago, it seems that "conforming compiler" morphed into "conforming C++ developement system" where by a compiler isn't considered "conforming" unless it's delivered along with an implementation of the standard library. This raises a number of questions to me: a) if some company were to produce C++ compiler does he also have to produce a standard library implementation? If he does - that would be a huge barrier to entry for anyone wanting to make a new compiler. b) if somes delivers a compiler with out a standard library is this compiler considerd "non-conforming". c) can someone just attach a copy of boost and/or stllib and still call his compiler "conforming to the C++ standard"? d) doesn't adding libraries to the standard make it more difficult and expensive to produce and sell a "conforming" C++ compiler. Is this a good thing. Wouldn't adding hard to implement libraries like fusion make this problem (if it is a problem) worse? e) I question the priorities of the standards committee. I see lambdas as interesting, but really I can't imagine any of the customers I deal with every using them. (get other customers? - right). and this has to add complexity the the process of making a new C++ compiler. And a lot of commitee effort is spent on this. Meanwhile somethings create problems like issues raised by run time linking - (ODR violations, visibility, etc.) seem to get less attention - even though I would think they would be easier to address. Of course this is just me speaking as a lowly application developer. I see competition for C++ not as coming from Haskell (though this has some good ideas) but rather from Java and VisualBasic. C++ is harder to learn than I think it should be - and it keeps getting hard rather than easier. I would be extremely curious to know what compiler (real and potential) have to say about all this. Thanks for reading my rant. Robert Ramey
1. I am a relatively new member of the C++ Committee. 2. These opinions are my own; I am NOT speaking for the Committee. 3. If the moderators deem this topic unacceptable for this list, I will respect it. On 22 November 2011 11:02, Robert Ramey <ramey@rrsd.com> wrote:
But that's all really aside from my main concern. I'm really thinking of something quite different. My understanding is that the the C++ commitee defines the requirements that a C++ compiler must fulfill to be considered "conforming".
"Hosted" implementations require all the libraries; "freestanding" implementations require a very small subset of them (you'll need a copy of the standard to see which ones, as the list was changed since n3242 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf>, the last publicly available draft). More details on the differences between hosted and freestanding can be found in the standard.
d) doesn't adding libraries to the standard make it more difficult and expensive to produce and sell a "conforming" C++ compiler. Is this a good thing. Wouldn't adding hard to implement libraries like fusion make this problem (if it is a problem) worse?
That's the tradeoff, isn't it, finding the balance between being useful for users (so they buy/use the product) and doable for implementers.
e) I question the priorities of the standards committee. I see lambdas as interesting, but really I can't imagine any of the customers I deal with every using them. (get other customers? - right). and this has to add complexity the the process of making a new C++ compiler.
As a user, I very much welcome lambda support, both syntactically and performance compared with Boost.Lambda. This is not to put down Boost.Lambda; there is only so much one can do in a library. And there are currently things the various Boost lambda libraries can do which the C++ lambdas cannot (such as polymorphic lambdas).
And a lot of commitee effort is spent on this. Meanwhile somethings create problems like issues raised by run time linking - (ODR violations, visibility, etc.) seem to get less attention - even though I would think they would be easier to address.
Do you have a proposal? The C++ Committee, like Boost, is an all-volunteer organization. Members work on what they feel is important and what they are passionate about. How does one get "Boost" to do something? Same strategies apply to getting the Committee to do something.
Of course this is just me speaking as a lowly application developer.
If you want a louder voice, come to a Committee meeting.
I see competition for C++ not as coming from Haskell (though this has some good ideas) but rather from Java and VisualBasic.
Java has a large library available, which would be an argument for increasing the size of the C++ Standard Library. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
On Tue, Nov 22, 2011 at 12:02 PM, Robert Ramey <ramey@rrsd.com> wrote: ...>
But that's all really aside from my main concern. I'm really thinking of something quite different. My understanding is that the the C++ commitee defines the requirements that a C++ compiler must fulfill to be considered "conforming". On the face of it I would interprete this to mean that a compiler is "conforming" if it can parse text written in accordance with the standard and produce an executable which will produce the expected results.
The standard actually "states only requirements on C++ implementations". It talks throughout the standard about "conforming implementations". The term "conforming compiler" never appears in normative text, and only appears once in a non-normative footnote.
But some time ago, it seems that "conforming compiler" morphed into "conforming C++ developement system" where by a compiler isn't considered "conforming" unless it's delivered along with an implementation of the standard library.
That's not correct. Since at least 1993 when I joined the committee, the focus has always been on "conforming implementations" rather than conforming compilers. The library has always been part of that. And before C++, the C standard also talked about conforming implementations rather than compilers, and the C library was also part of that definition of conforming.
This raises a number of questions to me:
a) if some company were to produce C++ compiler does he also have to produce a standard library implementation? If he does - that would be a huge barrier to entry for anyone wanting to make a new compiler.
Both C and C++ standards avoid any discussion of where a conforming implementation gets its various bits and pieces. That's considered beyond the scope of the standard.
b) if somes delivers a compiler with out a standard library is this compiler considerd "non-conforming".
The implementation is never conforming if it doesn't conform to the library clauses. Likewise, a library is never considered conforming unless the whole implementation is conforming.
c) can someone just attach a copy of boost and/or stllib and still call his compiler "conforming to the C++ standard"?
Boost isn't conforming for any number of reasons, starting with the namespace:-) And while the marketing departments of some compiler suppliers claim all sort of outrageous things, don't believe them any more that you might believe the marketing folks at your local used car dealer:-) Seriously, some compiler suppliers do offer choices of several standard libraries. That's simply beyond the scope of the standard, so the standard folks don't care.
d) doesn't adding libraries to the standard make it more difficult and expensive to produce and sell a "conforming" C++ compiler.
Yes, for a "conforming implementation".
Is this a good thing. Wouldn't adding hard to implement libraries like fusion make this problem (if it is a problem) worse?
Library suppliers participate in the committee's LWG, and will let the committee know if they think cost of supplying a particular component creates a problem. That's what happened with the TR1 math special functions, so they did not go in C++11, but instead were given their own TR.
e) I question the priorities of the standards committee. I see lambdas as interesting, but really I can't imagine any of the customers I deal with every using them. (get other customers? - right). and this has to add complexity the the process of making a new C++ compiler. And a lot of commitee effort is spent on this. Meanwhile somethings create problems like issues raised by run time linking - (ODR violations, visibility, etc.) seem to get less attention - even though I would think they would be easier to address. Of course this is just me speaking as a lowly application developer.
The standards committee is just like Boost - a volunteer effort. So if no one volunteers for something, it doesn't happen. Conversely, if a really difficult area draws a lot of volunteers, it happens even while some simple things languish for lack of volunteers. --Beman
Le 22/11/11 18:02, Robert Ramey a écrit :
I see competition for C++ not as coming from Haskell (though this has some good ideas) but rather from Java and VisualBasic. C++ is harder to learn than I think it should be - and it keeps getting hard rather than easier.
Hi, I guess that the idea of all the people participating on the C++ standard was to make the language easy to use while preserving the possibility to be as efficient as possible. Which new c++11 features do you think make the language harder to learn? Best, Vicente
participants (7)
-
Antony Polukhin -
Beman Dawes -
Cory Nelson -
Joel de Guzman -
Nevin Liber -
Robert Ramey -
Vicente J. Botet Escriba