I've just uploaded to the new sandbox-vault a first cut of a Boost.TR1 library, currently it only handles chapter 2 of the TR - so basically only shared_ptr is usable at present, but now that I've got the basic framework sorted I should be able to wiz through the rest of the TR in fairly short order. The zip is at: http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&directory=tr1 And the docs are online at: http://freespace.virgin.net/boost.regex/tr1/tr1.html At this stage I'm just trying to get some feedback on: 1) Is this worth doing? 2) Are there any problems with the implementation method used (using declarations to import boost code into std::tr1) that I haven't spotted? Anyone have any "over-my-dead-body" moments? 3) How should this be tested? At present I'm using cutdown concept-checks only (on the basis that the Boost code is tested by each libraries test suite already). 4) Anything else I've missed. Thanks in advance for any feedback you may have, John Maddock.
On Fri, 21 Jan 2005 16:42:52 -0000, John Maddock wrote
I've just uploaded to the new sandbox-vault a first cut of a Boost.TR1 library, currently it only handles chapter 2 of the TR -
Since no one is answering, I'll take a shot...
so basically only shared_ptr is usable at present, but now that I've got the basic framework sorted I should be able to wiz through the rest of the TR in fairly short order.
The zip is at:
http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&directory=tr1
And the docs are online at: http://freespace.virgin.net/boost.regex/tr1/tr1.html
I browsed these -- they look good.
At this stage I'm just trying to get some feedback on:
1) Is this worth doing?
Seems like it will be worthwhile if 1) it is done ahead of vendor tr1 packages 2) it is better in some way then vendor packages I would imagine in the future people will prefer to use the tr1 bundled with their std library of choice unless one of the conditions above hold true. Also, it won't be a complete tr1 without the hash stuff, so that will need to be noted (I'm assuming that wouldn't get into boost in time). Interestingly, there might be an argument for a boost distribution with the tr1 libraries removed from the boost package since they would be 'obsolete' -- argument being to avoid confusion for developers on project xyz we want to remove these.
...snip questions...
Thanks in advance for any feedback you may have,
It wasn't much, but maybe it will kickstart some other people to take a look ;-) Jeff
At 07:21 PM 1/23/2005, Jeff Garland wrote:
On Fri, 21 Jan 2005 16:42:52 -0000, John Maddock wrote
I've just uploaded to the new sandbox-vault a first cut of a Boost.TR1 library, currently it only handles chapter 2 of the TR -
Since no one is answering, I'll take a shot...
so basically only shared_ptr is usable at present, but now that I've got the basic framework sorted I should be able to wiz through the rest of the TR in fairly short order.
The zip is at:
http://boost-sandbox.sourceforge.net/vault/index.php?&direction=0&order=&dir ectory=tr1
And the docs are online at: http://freespace.virgin.net/boost.regex/tr1/tr1.html
I browsed these -- they look good.
At this stage I'm just trying to get some feedback on:
1) Is this worth doing?
Seems like it will be worthwhile if 1) it is done ahead of vendor tr1 packages 2) it is better in some way then vendor packages
I would imagine in the future people will prefer to use the tr1 bundled with their std library of choice unless one of the conditions above hold true. Also, it won't be a complete tr1 without the hash stuff, so that will need to be noted (I'm assuming that wouldn't get into boost in time). Interestingly, there might be an argument for a boost distribution with the tr1 libraries removed from the boost package since they would be 'obsolete' -- argument being to avoid confusion for developers on project xyz we want to remove these.
My prediction is that it will be four to six years before all the compilers boost users care about ship with the full tr1 in the box. So during that time period it will be a real service to users if we provide major portions of the TR. John's approach looks like a good way to do that, although so far I've only read the docs but not actually tried it in practice. --Beman
On Sun, 23 Jan 2005 20:14:57 -0500, Beman Dawes wrote
My prediction is that it will be four to six years before all the compilers boost users care about ship with the full tr1 in the box.
Wow, I sure hope you're wrong. That's an awful long time considering that they have open implementations to use as a starting point.
So during that time period it will be a real service to users if we provide major portions of the TR.
Agreed.
John's approach looks like a good way to do that, although so far I've only read the docs but not actually tried it in practice.
One thing I just realized that isn't covered in John's docs is how libraries that depend on the tr1 libs need to cope with this change. I'm thinking of libs that depend on shared_ptr (serialization, date-time in 1.33) or function (signals, thread), etc. Seems like these will need to be modified follow the user configuration of the appropriate headers -- at least where for interfaces. It might be ok if the dependency is an implementation detail, but probably would be best if all could be switched over. Jeff
My prediction is that it will be four to six years before all the compilers boost users care about ship with the full tr1 in the box.
Wow, I sure hope you're wrong. That's an awful long time considering that they have open implementations to use as a starting point.
Maybe, the impression I'm getting is that commercial TR1 implementations will be available soon, but that they won't ship with compilers until they become part of the official standard. I guess time will tell.
So during that time period it will be a real service to users if we provide major portions of the TR.
Agreed.
John's approach looks like a good way to do that, although so far I've only read the docs but not actually tried it in practice.
One thing I just realized that isn't covered in John's docs is how libraries that depend on the tr1 libs need to cope with this change. I'm thinking of libs that depend on shared_ptr (serialization, date-time in 1.33) or function (signals, thread), etc. Seems like these will need to be modified follow the user configuration of the appropriate headers -- at least where for interfaces. It might be ok if the dependency is an implementation detail, but probably would be best if all could be switched over.
Well they have two choices: 1) Do nothing, and carry on using the Boost versions. 2) Use the TR1 forwarding headers, and switch to the std::tr1 versions. Probably (1) is a safer bet until we see what kind of quality we get from early TR1 implementations. John.
On Mon, 24 Jan 2005 10:55:03 -0000, John Maddock wrote
My prediction is that it will be four to six years before all the compilers boost users care about ship with the full tr1 in the box.
Wow, I sure hope you're wrong. That's an awful long time considering that they have open implementations to use as a starting point.
Maybe, the impression I'm getting is that commercial TR1 implementations will be available soon, but that they won't ship with compilers until they become part of the official standard. ^^^^^
Ok, I thought they were already 'official', but not required. So when does it become 'official'?
I guess time will tell.
For sure.
Well they have two choices:
1) Do nothing, and carry on using the Boost versions. 2) Use the TR1 forwarding headers, and switch to the std::tr1 versions.
Probably (1) is a safer bet until we see what kind of quality we get from early TR1 implementations.
But there is also this option -- is there not? 3) Use the config macros to pick the same tr1 implementation as the user Jeff
At 06:39 AM 1/24/2005, Jeff Garland wrote:
On Mon, 24 Jan 2005 10:55:03 -0000, John Maddock wrote
My prediction is that it will be four to six years before all the compilers boost users care about ship with the full tr1 in the box.
Wow, I sure hope you're wrong. That's an awful long time considering
that
they have open implementations to use as a starting point.
Maybe, the impression I'm getting is that commercial TR1 implementations will be available soon, but that they won't ship with compilers until they become part of the official standard. ^^^^^
Ok, I thought they were already 'official', but not required. So when does it become 'official'?
It has to be voted on by ISO member countries, at least once, if not twice. Those are full votes of all ISO members, not just those that participate on the C++ committee. While to some extent these votes are just formal stamps of approval, there is always a chance that some country will throw a wrench in the works. Even if nothing unexpected occurs, my guess is the process will take a couple of years. International standards, even if just a Technical Report, are important enough that no one wants to rush and make a mistake in the approval process. While the availability of open source implementations, particularly the test suites, helps library suppliers to some extent, most of them will still implement from scratch. And some parts of the TR like the special functions don't have open source implementations available. Then with some compiler vendors there seems to be a really lengthy delay between the time the library suppliers like Dinkumware make code available, and when that code actually ships with a production compiler. Thus my "four to six years" guesstimate. --Beman
participants (3)
-
Beman Dawes -
Jeff Garland -
John Maddock