Report from Berlin C++ Standards Committee meeting
The C++ Standards Committee met last week in Berlin, Germany. Of interest to Boosters: * All of TR1 except special functions has been voted into C++0x, the next standard. Special functions were supported by the Library Working Group (LWG), including vendors such as Dinkumware, but they didn't fly in full committee. Compiler vendors indicate great worry about support costs. This vote isn't necessarily the end of the story since support for special functions was strong, although not quite enough to achieve the consensus needed. (The committee will only go ahead if there is consensus - a simple majority isn't good enough.) * Boost Filesystem was voted into TR2. * Boost Lexical Cast has been tentatively accepted by the LWG for TR2. * Boost Any has been tentatively accepted by the LWG for TR2. * A Boost Date-Time query was presented at the last meeting, and LWG members again in Berlin indicated interest in seeing a full proposal for TR2. * A Boost Networking [asio] query was presented, and the LWG has indicated their interest in a full proposal for TR2. The developer of a competing proposal has graciously thrown his support behind the Boost proposal, and may propose some additional higher level functionality. * Boost Threads has been reaffirmed as the LWG's choice as the basis for a TR2 threading library. Pete Becker's www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1907.html is the most recent version of the proposal. It will be refined and modified as work progresses. Howard Hinnant plans to propose unifying the lock classes into scoped_lock/shared_lock and possibly one other class. Pete will propose a function to access the underlying operating system handles to allow access to non-portable functionality. I've committed to review error handling to ensure handling of operating system errors is consistent between all TR2 libraries. * It looks more and more likely that Concepts will go into C++0x. If Concepts do go into the core language, the LWG has indicated their intent to percolate Concepts throughout the Standard Library. (Concepts were being held up by two competing proposals, but those two proposals are in process of being coalesced into a single proposal by Bjarne Stroustrup and Doug Gregor.) The next committee meetings are: October, 2006, Portland, Oregon. See www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1946.htm Spring, 2007, Oxford, England. Fall, 2007, Kona, Hawaii This coming October is the deadline for TR2 proposals. See www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html --Beman
Beman Dawes wrote:
The C++ Standards Committee met last week in Berlin, Germany. Of interest to Boosters:
Thx for the update -- interesting as usual. Looks like the committee was busy!
* A Boost Date-Time query was presented at the last meeting, and LWG members again in Berlin indicated interest in seeing a full proposal for TR2.
The complete date-time proposal will be available for Portland and I expect to be at the meeting as well.
* A Boost Networking [asio] query was presented, and the LWG has indicated their interest in a full proposal for TR2. The developer of a competing proposal has graciously thrown his support behind the Boost proposal, and may propose some additional higher level functionality.
I have some interest and concerns about the asio as a pure networking proposal -- it's really an io library proposal with networking. As such, there are some issues not currently addressed by the library that I can see the committee being worried about. In any case, I can see Chris needing a helping hand to get this done in time -- presuming that he is still able to pursue this deadline. Can you point us to the competing proposal/developer? We should probably organize a group of interested folks to help this along given the scope and importance of the job.
This coming October is the deadline for TR2 proposals. See www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html
I'd still really like to see a database binding library make it into TR2. Not having this is killing C++ against Java for application developers. We've had some periodic fits and starts, but it seems clear we won't have a Boost library by then. I'd still like to see someone with some time step up and take this on. It's been done about 10 times so I think a proposal could be gleaned from the best of the current bindings... Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote in message news:443983B2.1080604@crystalclearsoftware.com...
Beman Dawes wrote:
The C++ Standards Committee met last week in Berlin, Germany. Of interest to Boosters:
Thx for the update -- interesting as usual. Looks like the committee was busy!
* A Boost Date-Time query was presented at the last meeting, and LWG members again in Berlin indicated interest in seeing a full proposal for TR2.
The complete date-time proposal will be available for Portland and I expect to be at the meeting as well.
Excellent!
* A Boost Networking [asio] query was presented, and the LWG has indicated their interest in a full proposal for TR2. The developer of a competing proposal has graciously thrown his support behind the Boost proposal, and may propose some additional higher level functionality.
I have some interest and concerns about the asio as a pure networking proposal -- it's really an io library proposal with networking. As such, there are some issues not currently addressed by the library that I can see the committee being worried about. In any case, I can see Chris needing a helping hand to get this done in time -- presuming that he is still able to pursue this deadline.
N1974 Boost Network Library Query from Chris will appear in the post-meeting mailing, which will be available in two or three weeks. Chris was aware of the October deadline at the time he wrote his query.
Can you point us to the competing proposal/developer?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1925.pdf
... I'd still really like to see a database binding library make it into TR2. Not having this is killing C++ against Java for application developers. We've had some periodic fits and starts, but it seems clear we won't have a Boost library by then. I'd still like to see someone with some time step up and take this on. It's been done about 10 times so I think a proposal could be gleaned from the best of the current bindings...
My guess is the LWG and the committee would welcome such a proposal. Note that the October meeting deadline is for a proposal that includes proposed wording for the TR. The wording does not have to be 100% complete - as long as it is pretty good it would be sufficient to meet the October deadline. The LWG would almost certainly require a reference implementation, and some actual use in real-world applications, but that doesn't have to have happened by October as long as the proposal in generally based on existing practice. If a reference implementation was available on Boost and starting to get real-world use by spring 2007, that should be good enough if the library looks good otherwise. --Beman
Hi Jeff, --- Jeff Garland <jeff@crystalclearsoftware.com> wrote:
I have some interest and concerns about the asio as a pure networking proposal -- it's really an io library proposal with networking.
While I certainly intend it to be a comprehensive io library eventually, at the moment it only does networking :)
As such, there are some issues not currently addressed by the library that I can see the committee being worried about.
I presume you are at least partially referring to iostreams integration? Wrt iostreams support we should probably kick off some discussion asap on exactly what form that should take. I'll start a new thread for it.
In any case, I can see Chris needing a helping hand to get this done in time -- presuming that he is still able to pursue this deadline.
That's the plan.
We should probably organize a group of interested folks to help this along given the scope and importance of the job.
This is how I see things proceeding: - I need to get the next version with the breaking interface changes from the review out the door. - A brief discussion on what features are in or out of a proposal (although I have a fair idea of this already), based on the new version. - I knock together a rough draft proposal. - With interested parties, the proposal goes through a process of iterative modification and review. I am putting as much as possible of my spare time (such as it is) towards getting this next version out. I'm wary of putting a date on it, but there are only a couple of major changes left on my to-do list. Cheers, Chris
On 4/10/06, Christopher Kohlhoff <chris@kohlhoff.com> wrote: [snipped]
While I certainly intend it to be a comprehensive io library eventually, at the moment it only does networking :)
[snipped -- see below]
In any case, I can see Chris needing a helping hand to get this done in time -- presuming that he is still able to pursue this deadline.
That's the plan.
I could help with asynchronous IO support for Windows and Linux for asio if it is needed. But some things must be defined in the interface for file io. [snipped]
Cheers, Chris
best regards, -- Felipe Magno de Almeida
Hi Felipe, --- Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
I could help with asynchronous IO support for Windows and Linux for asio if it is needed. But some things must be defined in the interface for file io.
I don't plan to include anything other than networking in the proposal. However I do want to ensure, as far as possible, that the interface is compatible with a file I/O extension. Since you're working on an implementation your input will be valuable. Of course, if you have the time, maybe you'd like to write an async file I/O proposal too :) Cheers, Chris
On 4/26/06, Christopher Kohlhoff <chris@kohlhoff.com> wrote:
Hi Felipe,
--- Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
I could help with asynchronous IO support for Windows and Linux for asio if it is needed. But some things must be defined in the interface for file io.
I don't plan to include anything other than networking in the proposal. However I do want to ensure, as far as possible, that the interface is compatible with a file I/O extension. Since you're working on an implementation your input will be valuable.
Ok, soon I'll restart working on this.
Of course, if you have the time, maybe you'd like to write an async file I/O proposal too :)
Heh. If I have time I would really love to do so. Let's see how it goes..
Cheers, Chris
Thanks, -- Felipe Magno de Almeida
On Apr 10, 2006, at 9:24 AM, Christopher Kohlhoff wrote:
As such, there are some issues not currently addressed by the library that I can see the committee being worried about.
I presume you are at least partially referring to iostreams integration? Wrt iostreams support we should probably kick off some discussion asap on exactly what form that should take. I'll start a new thread for it.
That would be wonderful. I believe that iostreams integration is absolutely critical for acceptance into TR2. If an implementation of "wget" requires more than a single slide or if it isn't blindly obvious to even a networking ignoramus like myself, I think we'll have failed. Doug
Douglas Gregor wrote:
That would be wonderful. I believe that iostreams integration is absolutely critical for acceptance into TR2. If an implementation of "wget" requires more than a single slide or if it isn't blindly obvious to even a networking ignoramus like myself, I think we'll ^^^^^^^^^ LOL -- I think we should take someone with about 50 less IQ points than you as the test -- then there would be an outside hope that a typical developer might get it ;-)
Jeff
Christopher Kohlhoff wrote:
While I certainly intend it to be a comprehensive io library eventually, at the moment it only does networking :)
Yes -- so ultimately there is a question about focus in the proposal -- networking or io.
As such, there are some issues not currently addressed by the library that I can see the committee being worried about.
I presume you are at least partially referring to iostreams integration? Wrt iostreams support we should probably kick off some discussion asap on exactly what form that should take. I'll start a new thread for it.
Yes that's it -- I'll answer that thread in a bit.
In any case, I can see Chris needing a helping hand to get this done in time -- presuming that he is still able to pursue this deadline.
That's the plan.
Glad to hear it :-)
We should probably organize a group of interested folks to help this along given the scope and importance of the job.
This is how I see things proceeding:
- I need to get the next version with the breaking interface changes from the review out the door.
- A brief discussion on what features are in or out of a proposal (although I have a fair idea of this already), based on the new version.
- I knock together a rough draft proposal.
- With interested parties, the proposal goes through a process of iterative modification and review.
I am putting as much as possible of my spare time (such as it is) towards getting this next version out. I'm wary of putting a date on it, but there are only a couple of major changes left on my to-do list.
Sounds good. I am worried that even with the iostream integration the proposal won't have Doug's one-line wget implementation, but we'll see. Jeff
On 4/11/06, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
Sounds good. I am worried that even with the iostream integration the proposal won't have Doug's one-line wget implementation, but we'll see.
Shouldn't that be expected as it's a networking library and not a HTTP library?
On Apr 11, 2006, at 5:01 AM, Olaf van der Spek wrote:
On 4/11/06, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
Sounds good. I am worried that even with the iostream integration the proposal won't have Doug's one-line wget implementation, but we'll see.
Shouldn't that be expected as it's a networking library and not a HTTP library?
I'm not asking for an HTTP library. I'm asking for it to be utterly trivial to 1) Establish a connection to a remote site 2) Write some data over that connection 3) Read some data from that connection 4) Terminate the connection And I'd like those 4 bullets to take about 4 lines of code. It doesn't need perfect error handling, it doesn't need to handle redirects, it just needs to do the obvious thing in an obvious way. Doug
Jeff Garland <jeff@crystalclearsoftware.com> writes:
Sounds good. I am worried that even with the iostream integration the proposal won't have Doug's one-line wget implementation, but we'll see.
Fortunately, Doug wrote "one slide," not "one line." -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Jeff Garland <jeff@crystalclearsoftware.com> writes:
Sounds good. I am worried that even with the iostream integration the proposal won't have Doug's one-line wget implementation, but we'll see.
Fortunately, Doug wrote "one slide," not "one line."
std::ifstream is( "http://www.example.com/file.zip" ); std::ofstream os( "file.zip" ); os << is.rdbuf(); No proposal required, in principle.
On Tue, 11 Apr 2006 13:33:38 +0300, Peter Dimov wrote
David Abrahams wrote:
Jeff Garland <jeff@crystalclearsoftware.com> writes:
Sounds good. I am worried that even with the iostream integration the proposal won't have Doug's one-line wget implementation, but we'll see.
Fortunately, Doug wrote "one slide," not "one line."
std::ifstream is( "http://www.example.com/file.zip" ); std::ofstream os( "file.zip" ); os << is.rdbuf();
Point taken -- of course you need some sort of socket stream or OS support to acheive this (for fun I tried this on my Linux box -- didn't work). I'm mostly interesting in how to get basic_streambuf as a buffer for asio to enable this sort of higher layer construction. Jeff
Peter Dimov wrote:
std::ifstream is( "http://www.example.com/file.zip" ); std::ofstream os( "file.zip" ); os << is.rdbuf();
No proposal required, in principle.
Are you aware of (a) ambiguity and (b) potential security hole? (a)
mkdir http: mkdir http:/www.example.com touch http:/www.example.com/file.zip file http://www.example.com/file.zip http://www.example.com/file.zip: empty
(b) If you replace the first line with something more generic, for example with: std::ifstream is( argv[1] ); it becomes unclear that the code might send requests to the net. This can be resolved by additional checks appied to argv[1] or, better yet, with a second agrument to ifstream's ctor that specfify a domain/protofol (local, net, http, ftp and so on). -- Alexander Nasonov Project Manager http://www.akmosoft.com
Alexander Nasonov wrote:
Peter Dimov wrote:
std::ifstream is( "http://www.example.com/file.zip" ); std::ofstream os( "file.zip" ); os << is.rdbuf();
No proposal required, in principle.
Are you aware of (a) ambiguity and (b) potential security hole?
Yes, I am aware of both. It's a tradeoff.
(a)
mkdir http: mkdir http:/www.example.com touch http:/www.example.com/file.zip file http://www.example.com/file.zip http://www.example.com/file.zip: empty
(b) If you replace the first line with something more generic, for example with: std::ifstream is( argv[1] );
it becomes unclear that the code might send requests to the net.
The code can already send requests to the net; an example is \\www.example.com\share\file under Windows. In most cases, allowing existing code to seamlessly read from remote files over HTTP or FTP is a feature. PHP, for example, does that in its fopen, and most graphical shells also maintain this illusion. Anyway, I just wanted to illustrate the fact that standard library implementors already have the ability to add HTTP/FTP functionality; unfortunately, none have done so. C++ is a somewhat conservative language. :-) The obvious alternative is, of course, std::tr2::iurlstream is( "http://www.example.com/file.zip" ); which does require a proposal, albeit a relatively simple one. ASIO need not be involved in any way, and the implementation under Windows can use WinInet, for example.
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
Jeff Garland <jeff@crystalclearsoftware.com> writes:
Sounds good. I am worried that even with the iostream integration the proposal won't have Doug's one-line wget implementation, but we'll see.
Fortunately, Doug wrote "one slide," not "one line."
std::ifstream is( "http://www.example.com/file.zip" ); std::ofstream os( "file.zip" ); os << is.rdbuf();
No proposal required, in principle.
Except that any code involving an identifier spelled "rdbuf" fails the "do the obvious thing in an obvious way" test. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Hi Jeff, Sorry for late reply - I decided I needed to put all available time into completing a draft version of asio, so I haven't been reading the list lately. --- Jeff Garland <jeff@crystalclearsoftware.com> wrote:
Christopher Kohlhoff wrote:
While I certainly intend it to be a comprehensive io library eventually, at the moment it only does networking :)
Yes -- so ultimately there is a question about focus in the proposal -- networking or io.
Just networking. I don't plan to include any major features that aren't already in the library (except for iostreams support). Cheers, Chris
On 4/26/06, Christopher Kohlhoff <chris@kohlhoff.com> wrote:
Yes -- so ultimately there is a question about focus in the proposal -- networking or io.
Just networking. I don't plan to include any major features that aren't already in the library (except for iostreams support).
You mean for the proposal or also for the long term? In the long term a unified async IO library is needed I think.
Hi Olaf, --- Olaf van der Spek <olafvdspek@gmail.com> wrote:
You mean for the proposal or also for the long term?
Just for the proposal.
In the long term a unified async IO library is needed I think.
Yep, over time I'd like to see the library include support for many different types of I/O (like pipes, files, console, etc). Cheers, Chris
On 2006-04-09, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
Beman Dawes wrote:
This coming October is the deadline for TR2 proposals. See www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1810.html
I'd still really like to see a database binding library make it into TR2. Not having this is killing C++ against Java for application developers. We've had some periodic fits and starts, but it seems clear we won't have a Boost library by then. I'd still like to see someone with some time step up and take this on. It's been done about 10 times so I think a proposal could be gleaned from the best of the current bindings...
Just a quick note that the SOCI database library has been progressing nicely. The current release supports Oracle and Postgresql, and we have just recieved contributions of backends for SQLite and MySQL. The next release (later this month) should thus contain support for these 4 databases. http://soci.sourceforge.net/ Of course we welcome further contributions, e.g. SQLServer/Sybase etc. ;-) We are not yet at the point where we are ready to submit to boost, but we are moving in that direction. Steve
On Fri, 14 Apr 2006 07:28:59 +0000 (UTC), Steve Hutton wrote
Just a quick note that the SOCI database library has been progressing nicely. The current release supports Oracle and Postgresql, and we have just recieved contributions of backends for SQLite and MySQL. The next release (later this month) should thus contain support for these 4 databases.
Of course we welcome further contributions, e.g. SQLServer/Sybase etc. ;-)
We are not yet at the point where we are ready to submit to boost, but we are moving in that direction.
Hi Steve - Thanks very much for the update. I had looked at SOCI awhile back (was there a CUJ article?), but it's progressed very nicely since then. To me it looks like it is on exactly the right course: clean C++ user interface, extensibility for user types, ability to build 'drivers' for individual databases. What exactly are you planning on adding before the Boost submission? Error handling is the only thing that springs to mind looking at the docs -- I'm sure there's a way, but I didn't see an example. I'd really like to encourage you'all to think about making a submission to the committee. As Beman said, it doesn't need to be perfect. The only way to make it happen is to have a plan and get organized over the next few months to write up the proposal before the Oct meeting. Even if you aren't able to come to Portland to present the proposal one of us that is there can help with that aspect. Jeff
Hi,
Just a quick note that the SOCI database library has been progressing nicely.
We are not yet at the point where we are ready to submit to boost, but we are moving in that direction.
Hi Steve -
Thanks very much for the update. I had looked at SOCI awhile back (was there a CUJ article?), but it's progressed very nicely since then.
There was an article published in DDJ. And indeed, SOCI has progressed a lot since then. :) The main line of progress was to refactor the library in a way that extracts the database-specific code in the form of "plugin" with the obvious goal of allowing many such plugins (we call them backends). Indeed, we have 4 backends and it looks like some significant database servers are already targeted (Oracle, PostgreSQL, MySQL, SQLite).
To me it looks like it is on exactly the right course: clean C++ user interface, extensibility for user types, ability to build 'drivers' for individual databases.
Yes, these are the driving forces.
What exactly are you planning on adding before the Boost submission?
At least one backend allowing to target what is traditionally considered to be a Microsoft part of the world. ODBC backend would be most generic, but we will of course also welcome contributions that can talk to particular servers in their native way, which is currently the case for all existing backends (jaw-dropping performance gains were reported by our users after switching from ODBC-related solutions to SOCI with Oracle).
Error handling is the only thing that springs to mind looking at the docs
Yes, that's one of the things that can be more elaborated. Currently, there's a single exception type (additionally specialized for Oracle) for reporting all errors.
I'd really like to encourage you'all to think about making a submission to the committee.
Thank you very much for this encouragement. As already said - we are looking for contributors with ODBC competences. Before having the ODBC backend it will be difficult to get wider acceptance than some of the competing libraries already have.
As Beman said, it doesn't need to be perfect.
SOCI is not perfect. It's only the best. ;-)
The only way to make it happen is to have a plan and get organized over the next few months to write up the proposal before the Oct meeting. Even if you aren't able to come to Portland to present the proposal one of us that is there can help with that aspect.
Thanks again. :) --- Maciej Sobczak http://www.msobczak.com/
"Maciej Sobczak" <prog@msobczak.com> wrote in message news:443FD653.80702@msobczak.com...
Hi,
What exactly are you planning on adding before the Boost submission?
At least one backend allowing to target what is traditionally considered to be a Microsoft part of the world. ODBC backend would be most generic...
Looking at the soci.h header, it also seems the code needs to be boostified. And to find a name that is not tied to a particular vendor. How about Boost.Database? While it is fun to dream about an eventual submission to the standards committee, the first step is to get the library ready for a Boost formal review. The review spotlights areas needing additional work, and the wide scrutiny and exposure of Boost libraries gives the LWG confidence that a potential library is actually useful. --Beman
On Fri, 14 Apr 2006 16:56:30 -0400, Beman Dawes wrote
"Maciej Sobczak" <prog@msobczak.com> wrote in message news:443FD653.80702@msobczak.com...
Hi,
What exactly are you planning on adding before the Boost submission?
At least one backend allowing to target what is traditionally considered to be a Microsoft part of the world. ODBC backend would be most generic...
Looking at the soci.h header, it also seems the code needs to be boostified. And to find a name that is not tied to a particular vendor. How about Boost.Database?
While it is fun to dream about an eventual submission to the standards committee, the first step is to get the library ready for a Boost formal review. The review spotlights areas needing additional work, and the wide scrutiny and exposure of Boost libraries gives the LWG confidence that a potential library is actually useful.
I agree, although time is woefully short to make all these steps happen. Basically the Boost submission would need to be ready in a couple months if there is to be any hope of a proposal for Oct -- which really means Sept... Jeff
On 2006-04-14, Beman Dawes <bdawes@acm.org> wrote:
"Maciej Sobczak" <prog@msobczak.com> wrote in message news:443FD653.80702@msobczak.com...
Hi,
What exactly are you planning on adding before the Boost submission?
At least one backend allowing to target what is traditionally considered to be a Microsoft part of the world. ODBC backend would be most generic...
Looking at the soci.h header, it also seems the code needs to be boostified. And to find a name that is not tied to a particular vendor. How about Boost.Database?
Personally I was thinking Boost.Sql, partially to leave room for other libraries which take a less sql centric approach.
While it is fun to dream about an eventual submission to the standards committee, the first step is to get the library ready for a Boost formal review. The review spotlights areas needing additional work, and the wide scrutiny and exposure of Boost libraries gives the LWG confidence that a potential library is actually useful.
Yes, one step at a time :-) Steve
"Steve Hutton" <shutton@featurecomplete.com> wrote in message news:e1q9j4$t3b$1@sea.gmane.org...
On 2006-04-14, Beman Dawes <bdawes@acm.org> wrote:
"Maciej Sobczak" <prog@msobczak.com> wrote in message news:443FD653.80702@msobczak.com...
Hi,
What exactly are you planning on adding before the Boost submission?
At least one backend allowing to target what is traditionally considered to be a Microsoft part of the world. ODBC backend would be most generic...
Looking at the soci.h header, it also seems the code needs to be boostified. And to find a name that is not tied to a particular vendor. How about Boost.Database?
Personally I was thinking Boost.Sql, partially to leave room for other libraries which take a less sql centric approach.
Boost.SQL. I like it! (The uppercase wasn't a concious decision - it just came out that way. Maybe my fingers were trying to tell me something:-) --Beman
On Sun, 16 Apr 2006 22:18:39 -0400, Beman Dawes wrote
"Steve Hutton" <shutton@featurecomplete.com> wrote in message news:e1q9j4$t3b$1@sea.gmane.org...
On 2006-04-14, Beman Dawes <bdawes@acm.org> wrote:
"Maciej Sobczak" <prog@msobczak.com> wrote in message news:443FD653.80702@msobczak.com...
Hi,
What exactly are you planning on adding before the Boost submission?
At least one backend allowing to target what is traditionally considered to be a Microsoft part of the world. ODBC backend would be most generic...
Looking at the soci.h header, it also seems the code needs to be boostified. And to find a name that is not tied to a particular vendor. How about Boost.Database?
Personally I was thinking Boost.Sql, partially to leave room for other libraries which take a less sql centric approach.
Boost.SQL. I like it! (The uppercase wasn't a concious decision - it just came out that way. Maybe my fingers were trying to tell me something:-)
Hmm, I wonder -- seems to me that SOCI goes well beyond just SQL...but I'll keep an open mind for now. Just to confuse things there is already Boost.Database in the sandbox which is in at least some of the same territory... Jeff
On Fri, 14 Apr 2006 19:05:23 +0200, Maciej Sobczak wrote
What exactly are you planning on adding before the Boost submission?
At least one backend allowing to target what is traditionally considered to be a Microsoft part of the world. ODBC backend would be most generic, but we will of course also welcome contributions that can talk to particular servers in their native way, which is currently the case for all existing backends (jaw-dropping performance gains were reported by our users after switching from ODBC-related solutions to SOCI with Oracle).
As much as I agree ODBC would be nice, I think the fact that there are 4 bindings (pending reading the code) basically demonstrates that there is an appropriate abstraction layer to allow different databases to plug in.
Error handling is the only thing that springs to mind looking at the docs
Yes, that's one of the things that can be more elaborated. Currently, there's a single exception type (additionally specialized for Oracle) for reporting all errors.
So this is where a critical question about goals needs to be answered. Presumably the goal is to allow portability across the operating system dimension and NOT in the database dimension? That is, if I write code to target Oracle it will work on Windows, Linux, etc -- everywhere the db vendor provides a driver. However, there will be no guarantee that if I switch to Sybase my code written for Oracle will still work. For example, the errors from Sybase might be different from Oracle. Obviously if you use an ODBC driver you would have the same errors no matter the backend data store. Is this the vision?
I'd really like to encourage you'all to think about making a submission to the committee.
Thank you very much for this encouragement. As already said - we are looking for contributors with ODBC competences. Before having the ODBC backend it will be difficult to get wider acceptance than some of the competing libraries already have.
If we are going to get this in the standard we don't have time to wait for widespread acceptence. I think at a minimum we would need to get it to a Boost review...
The only way to make it happen is to have a plan and get organized over the next few months to write up the proposal before the Oct meeting. Even if you aren't able to come to Portland to present the proposal one of us that is there can help with that aspect.
Thanks again. :)
Well, I wouldn't thank me yet ;-) What I'm not so subtley trying to do is talk you and everyone else that has an interest in seeing a standard way to access database in C++ to cancel their weekend parties, stay up a couple hours later a night, etc to pitch in an make this happen. There's really only about 4 months left -- it's really a very short time... Jeff
On 2006-04-15, Jeff Garland <jeff@crystalclearsoftware.com> wrote:
On Fri, 14 Apr 2006 19:05:23 +0200, Maciej Sobczak wrote
As much as I agree ODBC would be nice, I think the fact that there are 4 bindings (pending reading the code) basically demonstrates that there is an appropriate abstraction layer to allow different databases to plug in.
Yes, I agree it shows the basic design is viable in terms of supporting multiple databases. We are however planning to do some internal refactoring and restructuring in the next 2 weeks before the next release.
Error handling is the only thing that springs to mind looking at the docs
Yes, that's one of the things that can be more elaborated. Currently, there's a single exception type (additionally specialized for Oracle) for reporting all errors.
So this is where a critical question about goals needs to be answered. Presumably the goal is to allow portability across the operating system dimension and NOT in the database dimension?
Not exactly. You should be able to write code which is portable accross databases with SOCI, if you are careful to not use vendor-specific extensions. Which of course is a big if, but it applies equally to most datbase libraries.
That is, if I write code to target Oracle it will work on Windows, Linux, etc -- everywhere the db vendor provides a driver. However, there will be no guarantee that if I switch to Sybase my code written for Oracle will still work. For example, the errors from Sybase might be different from Oracle. Obviously if you use an ODBC driver you would have the same errors no matter the backend data store. Is this the vision?
We haven't really addressed this too much in SOCI yet, but I think there should be SOCI exception types for basic classes of errors, plus the native error codes, probably available via database-specific exception subclasses. This would give the user the chance to write db agnostic code, or db specific code, as needed.
I'd really like to encourage you'all to think about making a submission to the committee.
Thank you very much for this encouragement. As already said - we are looking for contributors with ODBC competences. Before having the ODBC backend it will be difficult to get wider acceptance than some of the competing libraries already have.
If we are going to get this in the standard we don't have time to wait for widespread acceptence. I think at a minimum we would need to get it to a Boost review...
Ok, makes sense.
The only way to make it happen is to have a plan and get organized over the next few months to write up the proposal before the Oct meeting. Even if you aren't able to come to Portland to present the proposal one of us that is there can help with that aspect.
Thanks again. :)
Well, I wouldn't thank me yet ;-) What I'm not so subtley trying to do is talk you and everyone else that has an interest in seeing a standard way to access database in C++ to cancel their weekend parties, stay up a couple hours later a night, etc to pitch in an make this happen. There's really only about 4 months left -- it's really a very short time...
I believe Maciej is going on holiday now...shortly after he returns (25th of April) we will release SOCI 2.1. At that point I think we can gather feedback to put together a TODO list needed for a boost submission and get into the review queue. Steve
On Fri, Apr 14, 2006 at 05:48:20PM -0700, Jeff Garland wrote:
As much as I agree ODBC would be nice, I think the fact that there are 4 bindings (pending reading the code) basically demonstrates that there is an appropriate abstraction layer to allow different databases to plug in.
I'm a little late to this thread, but I wouldn't underestimate the value of including ODBC. ODBC is almost insanely flexible (and insane too) :-) There are ODBC drivers from flat files to Oracle, and that's a lot of territory. - Chris
Just a quick note that the SOCI database library has been progressing nicely. The current release supports Oracle and Postgresql, and we have just recieved contributions of backends for SQLite and MySQL. The next release (later this month) should thus contain support for these 4 databases.
I just had a look and as others have said this is looking good. The design criteria all seem reasonable. I'd suggest getting into the boost review queue sooner rather than later. The biggest thing that concerned me was having to define the size of a vector to limit the amount of data that is read, e.g. std::vector<int> valsOut(100); sql << "select val from numbers", into(valsOut); What if I simply want to get all data, in one batch. Or, more likely, if I forget to specify a size does it give an error or simply return no data: std::vector<int> valsOut; sql << "select val from numbers", into(valsOut); Also if, in the first example, more than 100 records were available, is there a flag set somewhere to tell me that I didn't get all the data? Or does the vector size of 100 add a "LIMIT 100" to the SQL query so there is no way to tell? Darren
On 2006-04-14, Darren Cook <darren@dcook.org> wrote:
Just a quick note that the SOCI database library has been progressing nicely. The current release supports Oracle and Postgresql, and we have just recieved contributions of backends for SQLite and MySQL. The next release (later this month) should thus contain support for these 4 databases.
I just had a look and as others have said this is looking good. The design criteria all seem reasonable. I'd suggest getting into the boost review queue sooner rather than later.
Thanks! We should have the 2.1 release out around the end of the month, and after that I think we can create a TODO list for boostification and get into the review queue.
The biggest thing that concerned me was having to define the size of a vector to limit the amount of data that is read, e.g.
std::vector<int> valsOut(100); sql << "select val from numbers", into(valsOut);
The idea is that you want to tune the batch size for best performance. I'm open to considering other ways of specifying the batch size...
What if I simply want to get all data, in one batch. Or, more likely, if I forget to specify a size does it give an error or simply return no data: std::vector<int> valsOut; sql << "select val from numbers", into(valsOut);
This will throw an exception.
Also if, in the first example, more than 100 records were available, is there a flag set somewhere to tell me that I didn't get all the data? Or does the vector size of 100 add a "LIMIT 100" to the SQL query so there is no way to tell?
The idea is that to select all rows, you fetch within a loop. The vector gets resized to contain the number of rows returned. const int BATCH_SIZE = 30; std::vector<int> valsOut(BATCH_SIZE); Statement st = (sql.prepare << "select value from numbers", into(valsOut)); st.execute(); while (st.fetch()) { std::vector<int>::iterator pos; for(; pos != valsOut.end(); ++pos) { cout << *pos << '\n'; } } http://soci.sourceforge.net/doc/statements.html Steve
Jeff Garland wrote:
I'd still really like to see a database binding library make it into TR2. Not having this is killing C++ against Java for application developers. We've had some periodic fits and starts, but it seems clear we won't have a Boost library by then. I'd still like to see someone with some time step up and take this on. It's been done about 10 times so I think a proposal could be gleaned from the best of the current bindings...
All this database talks made me a bit puzzled. What's exactly the standard committee can do about database interface? I mean, does specifying a standard interface for database means that I can write code that uses this interface and then I'll find my self reading data from a database? Which database? The database compiler vendors will suddenly have to provide with their compiler to satisfy the standard requirements? Probably not... Compiler vendors won't start writing databases (except Microsoft, of course :-) ). This means that this standard interface would be directed to database vendors rather than compiler vendors. Is this the plan? That database vendors will start supplying C++ header files and lib files with a "C++ Compliant" stamp? Just thinking out loud... Yuval
On Sun, 16 Apr 2006 00:38:57 +0300, Yuval Ronen wrote
Jeff Garland wrote:
I'd still really like to see a database binding library make it into TR2. Not having this is killing C++ against Java for application developers. We've had some periodic fits and starts, but it seems clear we won't have a Boost library by then. I'd still like to see someone with some time step up and take this on. It's been done about 10 times so I think a proposal could be gleaned from the best of the current bindings...
All this database talks made me a bit puzzled. What's exactly the standard committee can do about database interface? I mean, does specifying a standard interface for database means that I can write code that uses this interface and then I'll find my self reading data from a database?
Yes.
Which database?
Any relational database.
The database compiler vendors will suddenly have to provide with their compiler to satisfy the standard requirements? Probably not... Compiler vendors won't start writing databases (except Microsoft, of course :-) ). This means that this standard interface would be directed to database vendors rather than compiler vendors. Is this the plan? That database vendors will start supplying C++ header files and lib files with a "C++ Compliant" stamp?
You raise a good point. Virtually all database vendors supply an ODBC interface -- so I would expect that this would be the primary basic 'driver interface' supplied by companies building standard libraries. However, I would expect the architecture to allow for database or standard library vendors to provide high performance native bindings for particular databases. Jeff
Jeff Garland wrote:
The database compiler vendors will suddenly have to provide with their compiler to satisfy the standard requirements? Probably not... Compiler vendors won't start writing databases (except Microsoft, of course :-) ). This means that this standard interface would be directed to database vendors rather than compiler vendors. Is this the plan? That database vendors will start supplying C++ header files and lib files with a "C++ Compliant" stamp?
You raise a good point. Virtually all database vendors supply an ODBC interface -- so I would expect that this would be the primary basic 'driver interface' supplied by companies building standard libraries. However, I would expect the architecture to allow for database or standard library vendors to provide high performance native bindings for particular databases.
So we're standardizing ODBC? The committee would require compiler/std-lib vendors to supply a C++ wrapper for ODBC (without forbidding supplying additional wrappers with same interface for other databases)?
On Sun, 16 Apr 2006 08:28:39 +0300, Yuval Ronen wrote
Jeff Garland wrote:
The database compiler vendors will suddenly have to provide with their compiler to satisfy the standard requirements? Probably not... Compiler vendors won't start writing databases (except Microsoft, of course :-) ). This means that this standard interface would be directed to database vendors rather than compiler vendors. Is this the plan? That database vendors will start supplying C++ header files and lib files with a "C++ Compliant" stamp?
You raise a good point. Virtually all database vendors supply an ODBC interface -- so I would expect that this would be the primary basic 'driver interface' supplied by companies building standard libraries. However, I would expect the architecture to allow for database or standard library vendors to provide high performance native bindings for particular databases.
So we're standardizing ODBC?
No -- the committe doesn't standardize Posix, but it is now getting leveraged by implementations of several libraries.
The committee would require compiler/std-lib vendors to supply a C++ wrapper for ODBC (without forbidding supplying additional wrappers with same interface for other databases)?
Actually I don't think the proposal needs to require ODBC at all. I was just saying that a typical approach for library developers to get coverage across many databases would be to use a common interface supported by many databases in the implementation. But if they or a database company wants to provide a really optimized version for a particular db, the design should allow it. In any case, this would be going into a TR -- so it's optional for the vendors anyway. Jeff
Jeff Garland wrote:
On Sun, 16 Apr 2006 08:28:39 +0300, Yuval Ronen wrote
So we're standardizing ODBC?
No -- the committe doesn't standardize Posix, but it is now getting leveraged by implementations of several libraries.
The committee would require compiler/std-lib vendors to supply a C++ wrapper for ODBC (without forbidding supplying additional wrappers with same interface for other databases)?
Actually I don't think the proposal needs to require ODBC at all. I was just saying that a typical approach for library developers to get coverage across many databases would be to use a common interface supported by many databases in the implementation. But if they or a database company wants to provide a really optimized version for a particular db, the design should allow it.
In any case, this would be going into a TR -- so it's optional for the vendors anyway.
What I'm trying to understand is what will be *required* by compiler/std-lib vendors, if they want to call themselves standard C++. One possible answer is to say "nothing is required". Everything is optional. Note that saying that it's TR so it's optional anyway doesn't quite cut it in the long run. I'm talking about acceptance to the stantard itself some day. So saying "nothing is required" means there's no plan to *ever* require it, even when the TR is merged into the stantard. However, if the plan is to require this interface some day as part of the stantard library, something that a std-lib vendor can't omit if it wants to be compliant, then I don't know what can be required that is implementable by std-lib vendors.
On Sun, 16 Apr 2006 14:25:25 +0200, Yuval Ronen wrote
Jeff Garland wrote:
What I'm trying to understand is what will be *required* by compiler/std-lib vendors, if they want to call themselves standard C++. One possible answer is to say "nothing is required". Everything is optional.
I'm personally ok with the "nothing is required" approach because I really think that if the committee adopts a good interface everything will flow from that. For example, no standard library vendor is going to deliver a database library that can't work at least one database. And the database vendor won't want to be left out of working with standard C++ implementations, so they will want to deliver high performance versions. There will be Boost versions that work with all the common databases, etc. So even if the details of how the vendors do this is left unspecified I think from a developer/user perspective the need would be met because the vendors have several possible approaches to work it out. All that said, I suppose it's possible that some companies won't see it that way. There's a couple companies I can think of that could decide to only support the databases they make -- thus encouraging use of only their database products. If I were a customer of such a company and wanted to use a different database with C++ I'd be upset and complain, switch vendors, or use and open source standard library that doesn't have the restriction.
Note that saying that it's TR so it's optional anyway doesn't quite cut it in the long run. I'm talking about acceptance to the stantard itself some day. So saying "nothing is required" means there's no plan to *ever* require it, even when the TR is merged into the stantard.
Yep, but as the TR gets into practice there is time to learn and make final adjustments before it is adopted into the standard. So the TR version doesn't set everything into stone.
However, if the plan is to require this interface some day as part of the stantard library, something that a std-lib vendor can't omit if it wants to be compliant, then I don't know what can be required that is implementable by std-lib vendors.
Nor do I, although I suspect that this issue is very similar to what Beman has been pushing with respect to the C++ standard pointing to other existing standards (eg: posix) so the standard committee doesn't try to specify everything. While the database standards aren't quite as clean as Posix, I'd think that 'common standards' like ODBC and 20+ years of development and usage would be enough... Jeff
* Boost Threads has been reaffirmed as the LWG's choice as the basis for a TR2 threading library. Pete Becker's www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1907.html is the most recent version of the proposal. It will be refined and modified as work progresses. Howard Hinnant plans to propose unifying the lock classes into scoped_lock/shared_lock and possibly one other class. Pete will propose a function to access the underlying operating system handles to allow access to non-portable functionality. I've committed to review error handling to ensure handling of operating system errors is consistent between all TR2 libraries.
Along with lock unification I would also propose mutex unification: mutex, try_mutex, timed_mutex, recursive_mutex, recursive_try_mutex, recursive_timed_mutex can be simplified into mutex and recursive_mutex including try and timed functions. Current UNIX and Windows platforms offer efficient implementations of all functions with native mutexes so I see no need to have so many mutexes. Maybe this is an issue to comment in comp.std.c++ but since it's based on boost, I think we should think about it. I think all desired modifications can be proposed in the current Boost Thread rework effort and aren't too intrusive. For thread launching I prefer Kevlin Henney's proposal approach. Has the committee rejected this approach? Regards, Ion
Ion Gaztañaga wrote:
I think all desired modifications can be proposed in the current Boost Thread rework effort and aren't too intrusive. For thread launching I prefer Kevlin Henney's proposal approach. Has the committee rejected this approach?
You are not alone. The problem is that Kevlin is a very busy man, and has not yet produced a full working proposal. Likewise, I am not aware of a freely available reference implementation, whereas there are at least 3 known separate implementations of the Boost threads interface. The approach has not been rejected, but is unlikely to make it in time for TR2. Likewise, the thread library itself is most likely destined for TR2 rather than C++0x, although I believe the evolution group would prefer us to be more aggressive on this. TR2 is shaping up nicely as a library offering system-services though, with FileSystem accepted, and threads and networking strongly under consideration. Beeman's approach to error reporting for system-specific errors could be broken out of FileSystem and become the underpinning mechanism shared across all TR2 system-level libraries. -- AlisdairM
I think all desired modifications can be proposed in the current Boost Thread rework effort and aren't too intrusive. For thread launching I prefer Kevlin Henney's proposal approach. Has the committee rejected this approach?
You are not alone. The problem is that Kevlin is a very busy man, and has not yet produced a full working proposal. Likewise, I am not aware of a freely available reference implementation, whereas there are at least 3 known separate implementations of the Boost threads interface.
There is a partial implementation (threader, joiner and lockable) I wrote some months ago: http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=Concurrent%20Programming See thread_ex.2005-08-31.zip. It's constructed above Boost.Thread. I didn't know then Boost.Thread's had unlock() function so I had to make ugly things to access Boost.Thread's mutex private functions. But the thread launcher is implemented with Boost.Thread and shared_ptr.
The approach has not been rejected, but is unlikely to make it in time for TR2. Likewise, the thread library itself is most likely destined for TR2 rather than C++0x, although I believe the evolution group would prefer us to be more aggressive on this.
We can implement thread launching interface above Boost.Thread, as in the wrapper I wrote. Using that wrapper to launch threads and condensing 6 mutex types into 2 it's possible for TR2. We can let read write mutex (or shared_mutex, if you prefer that name) for C++0x along with a message queue. I will look to Pete's paper to propose changes to Boost mailing list (including Howard Hinnant's lock reduction).
TR2 is shaping up nicely as a library offering system-services though, with FileSystem accepted, and threads and networking strongly under consideration. Beeman's approach to error reporting for system-specific errors could be broken out of FileSystem and become the underpinning mechanism shared across all TR2 system-level libraries.
I'm trying to follow also that error reporting system with Boost.Interprocess, and I must say that I find that approach good in general. Regards, Ion
"Ion Gaztañaga" <igaztanaga@gmail.com> wrote in message news:443ABF78.8040305@gmail.com...
I think all desired modifications can be proposed in the current Boost Thread rework effort and aren't too intrusive. For thread launching I prefer Kevlin Henney's proposal approach. Has the committee rejected this approach?
You are not alone. The problem is that Kevlin is a very busy man, and has not yet produced a full working proposal. Likewise, I am not aware of a freely available reference implementation, whereas there are at least 3 known separate implementations of the Boost threads interface.
There is a partial implementation (threader, joiner and lockable) I wrote some months ago:
http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=Concurrent%20Programming
See thread_ex.2005-08-31.zip. It's constructed above Boost.Thread. I didn't know then Boost.Thread's had unlock() function so I had to make ugly things to access Boost.Thread's mutex private functions. But the thread launcher is implemented with Boost.Thread and shared_ptr.
The approach has not been rejected, but is unlikely to make it in time for TR2. Likewise, the thread library itself is most likely destined for TR2 rather than C++0x, although I believe the evolution group would prefer us to be more aggressive on this.
We can implement thread launching interface above Boost.Thread, as in the wrapper I wrote. Using that wrapper to launch threads and condensing 6 mutex types into 2 it's possible for TR2. We can let read write mutex (or shared_mutex, if you prefer that name) for C++0x along with a message queue. I will look to Pete's paper to propose changes to Boost mailing list (including Howard Hinnant's lock reduction).
I'd personally like you and the other Boost threading experts to keep working on a thread launching interface above Boost.Threads, and if it seems to be working out well, propose it for TR2. (That's my personal opinion - I have no idea what the rest of the LWG thinks.) There is still enough time for this if people get going. There has to be a proposal with proposed wording for TR2 by October, but it can have some rough edges. If the LWG likes it, you will have another six months to polish it and gain more use experience. --Beman
I'd personally like you and the other Boost threading experts to keep working on a thread launching interface above Boost.Threads, and if it seems to be working out well, propose it for TR2. (That's my personal opinion - I have no idea what the rest of the LWG thinks.) There is still enough time for this if people get going. There has to be a proposal with proposed wording for TR2 by October, but it can have some rough edges. If the LWG likes it, you will have another six months to polish it and gain more use experience.
Ok, I have no problem to implement Kevlin's paper's thread launching interface above Boost.Threads without implementing the rest of his proposal, and do some documentation and tests. This issue is independent from mutex reduction suggestion so I plan to only implement thread-launching for now. Regards, Ion
"Ion Gaztañaga" <igaztanaga@gmail.com> wrote in message news:443E3246.8010104@gmail.com...
I'd personally like you and the other Boost threading experts to keep working on a thread launching interface above Boost.Threads, and if it seems to be working out well, propose it for TR2. (That's my personal opinion - I have no idea what the rest of the LWG thinks.) There is still enough time for this if people get going. There has to be a proposal with proposed wording for TR2 by October, but it can have some rough edges. If the LWG likes it, you will have another six months to polish it and gain more use experience.
Ok, I have no problem to implement Kevlin's paper's thread launching interface above Boost.Threads without implementing the rest of his proposal, and do some documentation and tests. This issue is independent from mutex reduction suggestion so I plan to only implement thread-launching for now.
Good. If I can be of any help, let me know. --Beman
"Beman Dawes" <bdawes@acm.org> writes:
* Boost Lexical Cast has been tentatively accepted by the LWG for TR2.
Was there any discussion of the to_string(x) and string_to<T>(x) alternative? I only ask because I remember the issue coming up somewhere before, and I have never seen a use for lexical_cast that didn't have a string on one end. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:m2wtdxc76z.fsf@boonen.local...
"Beman Dawes" <bdawes@acm.org> writes:
* Boost Lexical Cast has been tentatively accepted by the LWG for TR2.
Was there any discussion of the to_string(x) and string_to<T>(x) alternative?
I only ask because I remember the issue coming up somewhere before, and I have never seen a use for lexical_cast that didn't have a string on one end.
Yes, there was discussion of alternatives and complementary functions. The LWG discussed both lexical_cast and "Simple Numeric Access" http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1803.html at the same time, and is currently proceeding with both proposals as a package of conversion functionality. If others think there is a better way, they need to get working on specific proposals. The LWG does not seem inclined to hold conversion proposals currently on the table in the hopes something better will appear. --Beman
David Abrahams <dave <at> boost-consulting.com> writes:
Was there any discussion of the to_string(x) and string_to<T>(x) alternative?
I am using an interface which works like this to_string(T x); to_string(T x, const locale& l); // The following function always use the classic locale // this allows easy specializations for trivial cases like int to_string_classic(T x); from_string(SequenceT s); from_string(SequenceT s, const locale& l); from_string_classic(SequenceT s); from_string(SequenceT s, T def); // default value = no throw from_string(SequenceT s, const locale& l, T def); // format is applied to stream before value is extracted // e.g. double x = from_string(str, noskipws); // int x = from_string(str, hex); from_string(SequenceT s, FormatT format); ... On top of this I have also implemented the following: 1. tuple streaming without separators which means I can do: to_string(make_tuple(hex, setw(10), right, 123)); 2. a class that holds the stream to avoid creating it or specifying locale and formats every time. string_conversion conv(mylocale, hex); for (int ii = 0; ii < 10; ++ii) str += conv.to_string(ii);
Beman Dawes wrote:
The C++ Standards Committee met last week in Berlin, Germany. Of interest to Boosters:
Thank you for the extensive report. I have one question that will help me (and possibly others) prioritize things better for October.
* All of TR1 except special functions has been voted into C++0x, the next standard.
What is the general procedure for evolving TR1 (now 0x) components further, and in particular, what is the fate of N1851, "Improving Usability and Performance of TR1 Smart Pointers", especially the allocator support section? In other words, should we spend significant time on improving (for example) shared_ptr, or should we focus on new, TR2 things, now that std::shared_ptr is almost set in stone?
On Apr 11, 2006, at 10:43 AM, Peter Dimov wrote:
What is the general procedure for evolving TR1 (now 0x) components further, and in particular, what is the fate of N1851, "Improving Usability and Performance of TR1 Smart Pointers", especially the allocator support section?
In other words, should we spend significant time on improving (for example) shared_ptr, or should we focus on new, TR2 things, now that std::shared_ptr is almost set in stone?
N1851 was not discussed in Berlin (lack of time). The status as summarized in N1954: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1954.html stands as it was in Mont Tremblant. "Set in stone" is probably not the right characterization. The C++0X working draft is just that, a draft. We anticipate that it will continue to change. Defect reports will be applied to it. Language changes that may be introduced could have a large impact on the library portions of the draft (e.g. bind could radically change if lambda functions are introduced into the language). In part, getting items into the working draft is to solve a logistical problem. We need a document that we can read, edit and improve. We can't as easily create a perfect document when large parts of it (that we know we want in principal) are scattered throughout various papers. We know we want shared_ptr or something very much like it. It may mutate before standardization. But we feel its current specification is sufficient for the working draft. -Howard
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:005701c65d76$40d9d6a0$6407a8c0@pdimov2...
Beman Dawes wrote:
The C++ Standards Committee met last week in Berlin, Germany. Of interest to Boosters:
Thank you for the extensive report.
I have one question that will help me (and possibly others) prioritize things better for October.
* All of TR1 except special functions has been voted into C++0x, the next standard.
What is the general procedure for evolving TR1 (now 0x) components further, and in particular, what is the fate of N1851, "Improving Usability and Performance of TR1 Smart Pointers", especially the allocator support section?
In addition to Howard's reply, keep in mind that part of the purpose of a TR is to gain experience with a component so that it can be further improved before being standardized. Thus everyone expects and welcomes further improvements TR1 components as they move into the Standard Library.. Mechanically, if it is a small improvement, write it up as a library issue, and send it to either comp.std.c++ or directly to Howard. If it is larger, write a paper, get a document number from Clark Nelson, and send it to him to be included in the next committee mailing.
In other words, should we spend significant time on improving (for example) shared_ptr, or should we focus on new, TR2 things, now that std::shared_ptr is almost set in stone?
Try to strike a balance between doing both. The October deadline for TR2 proposals does not require every i to be dotted and t to be crossed. If a proposal is in pretty good shape, and the LWG likes it, you will have a year or more to submit revisions polishing any weak areas or fixing minor problems. Also note that names of Boosters such as Peter Dimov, John Maddock, or other long time contributors carry a lot of weight with the LWG. --Beman
On Sun, Apr 09, 2006 at 03:48:53PM -0400, Beman Dawes <bdawes@acm.org> wrote:
* Boost Filesystem was voted into TR2.
* Boost Lexical Cast has been tentatively accepted by the LWG for TR2.
* Boost Any has been tentatively accepted by the LWG for TR2.
* A Boost Date-Time query was presented at the last meeting, and LWG members again in Berlin indicated interest in seeing a full proposal for TR2.
* A Boost Networking [asio] query was presented, and the LWG has indicated their interest in a full proposal for TR2. The developer of a competing proposal has graciously thrown his support behind the Boost proposal, and may propose some additional higher level functionality.
Whats the purpose of TR2? I mean, it is supposed to be released after c++0x. So the extensions presented there will be part of the next standard, like c++1x? So again nearly 10 years later? Or will there be more frequent c++ standard releases? Regards Andreas Pokorny
On Apr 15, 2006, at 5:02 PM, Andreas Pokorny wrote:
On Sun, Apr 09, 2006 at 03:48:53PM -0400, Beman Dawes <bdawes@acm.org> wrote:
* Boost Filesystem was voted into TR2.
* Boost Lexical Cast has been tentatively accepted by the LWG for TR2.
* Boost Any has been tentatively accepted by the LWG for TR2.
* A Boost Date-Time query was presented at the last meeting, and LWG members again in Berlin indicated interest in seeing a full proposal for TR2.
* A Boost Networking [asio] query was presented, and the LWG has indicated their interest in a full proposal for TR2. The developer of a competing proposal has graciously thrown his support behind the Boost proposal, and may propose some additional higher level functionality.
Whats the purpose of TR2? I mean, it is supposed to be released after c++0x. So the extensions presented there will be part of the next standard, like c++1x? So again nearly 10 years later? Or will there be more frequent c++ standard releases?
At this point it is unknown which will release first, TR2 or C++0X. Regardless, the purpose of TR2 is to continue in a tradition of having a continual supply of libraries which have been vetted for possible future standardization. -Howard
participants (19)
-
Alexander Nasonov -
AlisdairM -
Andreas Pokorny -
Beman Dawes -
Chris Frey -
Christopher Kohlhoff -
Darren Cook -
David Abrahams -
Douglas Gregor -
Felipe Magno de Almeida -
Howard Hinnant -
Ion Gaztañaga -
Jeff Garland -
Maciej Sobczak -
Martin Adrian -
Olaf van der Spek -
Peter Dimov -
Steve Hutton -
Yuval Ronen