[iostreams] Version of Iostreams compatible with 1.32 available
Hi All, A version of the Iostreams library designed to work with release 1.32 is now available: http://home.comcast.net/~jturkanis/iostreams/ This version does not incorporate all the changes decided on during the review, but most of the name changes have been applied. In particular, - The library is now contained entirely in the iostreams subdirectories of <boost> and <libs>. - Resources are now called Devices - The i/o mode Inout has been renamed Bidirectional - The concept Buffered has been renamed Multi-Character - Filters are now located in the directory boost/iostreams/filter - Devices are now located in the directory boost/iostreams/device The library has been tested on VC7.1, Intel 7.1-8.0 for Windows, Codewarrior 8.3 and GCC 3.2 (mingw). Unfortunately, I have noticed some regressions of GCC 3.3-4, but am working to correct them. I am confident that the library will eventually work on GCC 3.3+ and Borland 5.6.4. In addition, I may be able to provide limited support for VC6-7.0. I'm hoping to get a version into CVS soon. Also, several of the fixes that people sent me during the review have been removed because they caused regressions. They have not been forgotten -- they will be incorporated in to the final version in modified form. -- Jonathan Turkanis technews@kangaroologic.com
Hi Jonathan, some quick observations: * Some of your includes still refer to <boost/io/...> instead of <boost/iostreams/...> (most notably, the examples). Am I missing something? * In boost/iostreams/detail/buffer.hpp, you can take advantage of boost/detail/allocator_utilities.hpp to do your allocator rebinding for both compliant and defective compilers. So, instead of #ifndef BOOST_NO_MEMBER_TEMPLATE typedef typename Alloc::template rebind<Ch>::other allocator_type; #else typedef mpl::if_< is_same<typename Alloc::value_type, Ch>, Alloc, std::allocator<Ch> >::type allocator_type; #endif you can write: #include <boost/detail/allocator_utilities.hpp> ... typedef typename boost::detail::allocator::rebind_to<Alloc,Ch>::type allocator_type; (BTW, it is not BOOST_NO_MEMBER_TEMPLATE but BOOST_NO_MEMBER_TEMPLATES.) * Seems to me that with some moderate effort the library could be made to work more or less with MSVC++ 6.0. If you want me to try to help a little wrt to this, please tell me so and I'll send you more questions/stuff via private email. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo Jonathan Turkanis ha escrito:
Hi All,
A version of the Iostreams library designed to work with release 1.32 is now available:
http://home.comcast.net/~jturkanis/iostreams/
This version does not incorporate all the changes decided on during the review, but most of the name changes have been applied. In particular,
- The library is now contained entirely in the iostreams subdirectories of <boost> and <libs>. - Resources are now called Devices - The i/o mode Inout has been renamed Bidirectional - The concept Buffered has been renamed Multi-Character - Filters are now located in the directory boost/iostreams/filter - Devices are now located in the directory boost/iostreams/device
The library has been tested on VC7.1, Intel 7.1-8.0 for Windows, Codewarrior 8.3 and GCC 3.2 (mingw). Unfortunately, I have noticed some regressions of GCC 3.3-4, but am working to correct them.
I am confident that the library will eventually work on GCC 3.3+ and Borland 5.6.4. In addition, I may be able to provide limited support for VC6-7.0.
I'm hoping to get a version into CVS soon.
Also, several of the fixes that people sent me during the review have been removed because they caused regressions. They have not been forgotten -- they will be incorporated in to the final version in modified form.
-- Jonathan Turkanis technews@kangaroologic.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Joaquín Mª López Muñoz" <joaquin@tid.es> wrote in message news:41B953D2.D66C4731@tid.es... Hi Jonathan, some quick observations: * Some of your includes still refer to <boost/io/...> instead of <boost/iostreams/...> (most notably, the examples). Am I missing something? * In boost/iostreams/detail/buffer.hpp, you can take advantage of boost/detail/allocator_utilities.hpp to do your allocator rebinding for both compliant and defective compilers. So, instead of #ifndef BOOST_NO_MEMBER_TEMPLATE typedef typename Alloc::template rebind<Ch>::other allocator_type; #else typedef mpl::if_< is_same<typename Alloc::value_type, Ch>, Alloc, std::allocator<Ch> >::type allocator_type; #endif you can write: #include <boost/detail/allocator_utilities.hpp> ... typedef typename boost::detail::allocator::rebind_to<Alloc,Ch>::type allocator_type; (BTW, it is not BOOST_NO_MEMBER_TEMPLATE but BOOST_NO_MEMBER_TEMPLATES.) * Seems to me that with some moderate effort the library could be made to work more or less with MSVC++ 6.0. If you want me to try to help a little wrt to this, please tell me so and I'll send you more questions/stuff via private email. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo Jonathan Turkanis ha escrito:
Hi All,
A version of the Iostreams library designed to work with release 1.32 is now available:
http://home.comcast.net/~jturkanis/iostreams/
This version does not incorporate all the changes decided on during the review, but most of the name changes have been applied. In particular,
- The library is now contained entirely in the iostreams subdirectories of <boost> and <libs>. - Resources are now called Devices - The i/o mode Inout has been renamed Bidirectional - The concept Buffered has been renamed Multi-Character - Filters are now located in the directory boost/iostreams/filter - Devices are now located in the directory boost/iostreams/device
The library has been tested on VC7.1, Intel 7.1-8.0 for Windows, Codewarrior 8.3 and GCC 3.2 (mingw). Unfortunately, I have noticed some regressions of GCC 3.3-4, but am working to correct them.
I am confident that the library will eventually work on GCC 3.3+ and Borland 5.6.4. In addition, I may be able to provide limited support for VC6-7.0.
I'm hoping to get a version into CVS soon.
Also, several of the fixes that people sent me during the review have been removed because they caused regressions. They have not been forgotten -- they will be incorporated in to the final version in modified form.
-- Jonathan Turkanis technews@kangaroologic.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Joaquín Mª López Muñoz wrote:
Hi Jonathan, some quick observations:
* Some of your includes still refer to <boost/io/...> instead of <boost/iostreams/...> (most notably, the examples). Am I missing something?
Thanks! It's hard to believe I didn't catch all these. If you find any not in the examples, please point them out to me.
* In boost/iostreams/detail/buffer.hpp, you can take advantage of boost/detail/allocator_utilities.hpp to do your allocator rebinding for both compliant and defective compilers. So, instead of
#ifndef BOOST_NO_MEMBER_TEMPLATE typedef typename Alloc::template rebind<Ch>::other allocator_type; #else typedef mpl::if_< is_same<typename Alloc::value_type, Ch>, Alloc, std::allocator<Ch> >::type allocator_type; #endif
you can write:
#include <boost/detail/allocator_utilities.hpp>
...
typedef typename boost::detail::allocator::rebind_to<Alloc,Ch>::type allocator_type;
(BTW, it is not BOOST_NO_MEMBER_TEMPLATE but BOOST_NO_MEMBER_TEMPLATES.)
This typo must have crept in some time after I stopped testing on VC6
* Seems to me that with some moderate effort the library could be made to work more or less with MSVC++ 6.0. If you want me to try to help a little wrt to this, please tell me so and I'll send you more questions/stuff via private email.
I actually spent a lot of time making the library compile on VC6. It was only near the end of development, when I got rid of the object generator functions make_sink, make_source, etc. in favor of a single function adapt, that I ran into internal errors on VC6 that I couldn't fix. Unfortunately, I found not having to support VC6 somewhat libertaing and removed some of the workarounds when they seemed to get in the way. My current plan is to add a defect macro NO_SMART_ADAPTER_SUPPORT which applies to VC6.0 which will bypass the stuff that gave VC6.0 trouble. However, even when the whole library compiled under VC6.0, both it and to a lesser extent VC7.0 had runtime failures with global optimization enabled. I'm not optimistic about being able to fix that. Perhaps after I restore some of the VC6 workarounds and get the core of the library working, you can help me add support for the adapters. Thanks for offering to help!
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Jonathan
On Fri, 10 Dec 2004 11:00:36 -0700, Jonathan Turkanis wrote
* Seems to me that with some moderate effort the library could be made to work more or less with MSVC++ 6.0. If you want me to try to help a little wrt to this, please tell me so and I'll send you more questions/stuff via private email.
I actually spent a lot of time making the library compile on VC6. It was only near the end of development, when I got rid of the object generator functions make_sink, make_source, etc. in favor of a single function adapt, that I ran into internal errors on VC6 that I couldn't fix.
Unfortunately, I found not having to support VC6 somewhat libertaing and removed some of the workarounds when they seemed to get in the way.
My current plan is to add a defect macro NO_SMART_ADAPTER_SUPPORT which applies to VC6.0 which will bypass the stuff that gave VC6.0 trouble.
However, even when the whole library compiled under VC6.0, both it and to a lesser extent VC7.0 had runtime failures with global optimization enabled. I'm not optimistic about being able to fix that.
Perhaps after I restore some of the VC6 workarounds and get the core of the library working, you can help me add support for the adapters. Thanks for offering to help!
I really think we should stop wasting time on VC6 -- in particular, for new libraries. I'd rather see both of you spend time extending your libraries, writing new novel ones, or mentoring new library authors. I can't even begin to measure the amount of time I've spent on support for VC6 over the last 4 years -- I'm pretty certain more than all other compilers combined -- and I don't think I'm alone. If we stop supporting maybe it will coax the slow adopters into some upgrades as developers complain that they can't use the latest and greatest boost libraries without vc7.x. Anyway, I think it's time to just say no to VC6 support. Jeff
Jeff Garland wrote:
On Fri, 10 Dec 2004 11:00:36 -0700, Jonathan Turkanis wrote
Perhaps after I restore some of the VC6 workarounds and get the core of the library working, you can help me add support for the adapters. Thanks for offering to help!
I really think we should stop wasting time on VC6 -- in particular, for new libraries. I'd rather see both of you spend time extending your libraries, writing new novel ones, or mentoring new library authors. I can't even begin to measure the amount of time I've spent on support for VC6 over the last 4 years -- I'm pretty certain more than all other compilers combined -- and I don't think I'm alone. If we stop supporting maybe it will coax the slow adopters into some upgrades as developers complain that they can't use the latest and greatest boost libraries without vc7.x. Anyway, I think it's time to just say no to VC6 support.
I'm very sympathetic to this point of view. When I stopped trying to support VC6 it felt like a great weight had been lifted off my back ;-) For some of my recent work, supporting VC6 is not even a remote possibility. In fact, in some ways VC7.1 has started to play the role that VC6 used to play: the old, broken compiler that ICEs at the slightest provocation. But I also want Iostreams to be as useful as possible, and I know there are still a lot of people stuck using VC6. So it's tempting to try to get the core of the library working again on that platform. Jonathan
Joaquín Mª López Muñoz wrote:
Hi Jonathan, some quick observations:
* In boost/iostreams/detail/buffer.hpp, you can take advantage of boost/detail/allocator_utilities.hpp to do your allocator rebinding for both compliant and defective compilers. So, instead of
#ifndef BOOST_NO_MEMBER_TEMPLATE typedef typename Alloc::template rebind<Ch>::other allocator_type; #else typedef mpl::if_< is_same<typename Alloc::value_type, Ch>, Alloc, std::allocator<Ch> >::type allocator_type; #endif
you can write:
#include <boost/detail/allocator_utilities.hpp>
typedef typename boost::detail::allocator::rebind_to<Alloc,Ch>::type allocator_type;
Has this been tested on Borland 5.x? I get errors (see end) unless I make the following change at line 132 template<typename Type> struct result:Allocator::BOOST_NESTED_TEMPLATE rebind<Type> { }; ==> template<typename Type> struct result:Allocator::BOOST_NESTED_TEMPLATE rebind<Type> { typedef typename Allocator::BOOST_NESTED_TEMPLATE rebind<Type>::other other; }; Best Regards, Jonathan ----------------------------- Error E2402 C:\Documents and Settings\turkanis\Home\Libraries\boost-1.32.0\boost/detail/allocator_utilities.h pp 133: Illegal base class type: formal type 'Allocator::rebind<Type>' resolves to '_STL::allocator<char>::rebind<Type>' Error E2404 C:\Documents and Settings\turkanis\Home\Libraries\boost-1.32.0\boost/detail/allocator_utilities.h pp 144: Dependent type qualifier 'boost::detail::allocator::rebinder<_STL::allocator<char> >::result<char>' has no member type named 'other'
On 12/10/04 2:44 AM, "Joaquín Mª López Muñoz" <joaquin@tid.es> wrote:
Hi Jonathan, some quick observations:
* Some of your includes still refer to <boost/io/...> instead of <boost/iostreams/...> (most notably, the examples). Am I missing something? [TRUNCATE]
I looked at some code. Files are in the "boost/iostreams/..." directory, but the items are in the "boost::io::..." namespace. We're trying to keep the directory and namespace hierarchies in line so it's easy for users to find stuff. The policy started from the base header directory getting too many direct entries for easy searching. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker wrote:
On 12/10/04 2:44 AM, "Joaquín Mª López Muñoz" <joaquin@tid.es> wrote:
Hi Jonathan, some quick observations:
* Some of your includes still refer to <boost/io/...> instead of <boost/iostreams/...> (most notably, the examples). Am I missing something? [TRUNCATE]
I looked at some code. Files are in the "boost/iostreams/..." directory, but the items are in the "boost::io::..." namespace. We're trying to keep the directory and namespace hierarchies in line so it's easy for users to find stuff. The policy started from the base header directory getting too many direct entries for easy searching.
The main reason Jeff recommended that I switch to the "iostreams" directory, IIRC, was that it would be difficult to merge our documentation: either the state-savers would get lost as a small component of the iostreams library, or we would have to have an introductory page with links to both libraries. I would greatly prefer to use the namespace "boost::io" because: (i) it is much shorter than "boost::iostreams"; while it is possible to use an alias to shorten it, I'd hate to make users do this when there is a perfectly suitable short name available. (ii) there currently are not many declarations in the namespace "boost::io", so there is not much chance of collisions (iii) it is a more accurate discription of the library, since the core infrastructure is independent of the standard iostreams library and might be used without streams, e.g., for async i/o. I also don't think finding the iostreams library or its namespace will be a serious problem. Therefore, unless there is a very convincing reason to enforce the policy that namespaces match directories in this particular case, I'd like to use "boost::io". Best Regards, Jonathan
On 12/20/04 8:58 PM, "Jonathan Turkanis" <technews@kangaroologic.com> wrote:
Daryle Walker wrote:
On 12/10/04 2:44 AM, "Joaquín Mª López Muñoz" <joaquin@tid.es> wrote:
Hi Jonathan, some quick observations:
* Some of your includes still refer to <boost/io/...> instead of <boost/iostreams/...> (most notably, the examples). Am I missing something? [TRUNCATE]
I looked at some code. Files are in the "boost/iostreams/..." directory, but the items are in the "boost::io::..." namespace. We're trying to keep the directory and namespace hierarchies in line so it's easy for users to find stuff. The policy started from the base header directory getting too many direct entries for easy searching.
The main reason Jeff recommended that I switch to the "iostreams" directory, IIRC, was that it would be difficult to merge our documentation: either the state-savers would get lost as a small component of the iostreams library, or we would have to have an introductory page with links to both libraries.
Maybe the latter. (And don't forget that the introductory page would include the format library, which also shares "boost::io".) Eventually, the state-savers, the new iostreams, and the format libraries could all switch to Doxygen & BoostBook. Actually, the co-existence policy of libraries that share a closure is something we all have to consider. The basic class/function reference, done by Doxygen or the like, of all Boost code could eventually be unified. But what do we do with the explanation prose?
I would greatly prefer to use the namespace "boost::io" because:
(i) it is much shorter than "boost::iostreams"; while it is possible to use an alias to shorten it, I'd hate to make users do this when there is a perfectly suitable short name available. (ii) there currently are not many declarations in the namespace "boost::io", so there is not much chance of collisions
If someone in the future doesn't realize that this library doesn't follow the pattern, then they could accidentally add a collision.
(iii) it is a more accurate discription of the library, since the core infrastructure is independent of the standard iostreams library and might be used without streams, e.g., for async i/o.
I also don't think finding the iostreams library or its namespace will be a serious problem.
Therefore, unless there is a very convincing reason to enforce the policy that namespaces match directories in this particular case, I'd like to use "boost::io".
There was originally no problem with everyone putting their headers directly in the header directory, but it didn't scale as Boost grew. Having a dozen or so people follow your lead over the next few years could result in a new version of the scaling problem. (I'm trying to stop a potential big problem while it's only tiny.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker wrote:
On 12/20/04 8:58 PM, "Jonathan Turkanis" <technews@kangaroologic.com>
The main reason Jeff recommended that I switch to the "iostreams" directory, IIRC, was that it would be difficult to merge our documentation: either the state-savers would get lost as a small component of the iostreams library, or we would have to have an introductory page with links to both libraries.
Maybe the latter. (And don't forget that the introductory page would include the format library, which also shares "boost::io".) Eventually, the state-savers, the new iostreams, and the format libraries could all switch to Doxygen & BoostBook
Okay, the latter solution would be fine with me. How would you recommend the docs and tests be organized. One way would be to put the existing material for the iostreams library in the directory libs/io/iostreams. Also, we should probably get Jeff Garland's view on this. Jonathan
On Wed, 22 Dec 2004 11:17:24 -0700, Jonathan Turkanis wrote
Daryle Walker wrote:
On 12/20/04 8:58 PM, "Jonathan Turkanis" <technews@kangaroologic.com>
The main reason Jeff recommended that I switch to the "iostreams" directory, IIRC, was that it would be difficult to merge our documentation: either the state-savers would get lost as a small component of the iostreams library, or we would have to have an introductory page with links to both libraries.
Yes, combining the docs at this point would be cumbersome. It would be nice if the docs had links to the other 'related libraries' so that people see the options.
Maybe the latter. (And don't forget that the introductory page would include the format library, which also shares "boost::io".) Eventually, the state-savers, the new iostreams, and the format libraries could all switch to Doxygen & BoostBook
Okay, the latter solution would be fine with me. How would you recommend the docs and tests be organized. One way would be to put the existing material for the iostreams library in the directory libs/io/iostreams.
I sort of think that libs/iostreams would be less confusing because there is no dependency between the iostreams library and the original boost::io. But it really could be either way...
Also, we should probably get Jeff Garland's view on this.
As for the overall question of the directory structure matching the namespace, that would be nice, but it doesn't seem practical at this point. There are already many violations of this in boost. So I'm fine with the directory being iostreams and the namespace being io. HTH ;-) Jeff
[Sorry for the extensive quoting -- I couldn't find anything to snip] Jeff Garland wrote:
On Wed, 22 Dec 2004 11:17:24 -0700, Jonathan Turkanis wrote
Daryle Walker wrote:
On 12/20/04 8:58 PM, "Jonathan Turkanis" <technews@kangaroologic.com>
The main reason Jeff recommended that I switch to the "iostreams" directory, IIRC, was that it would be difficult to merge our documentation: either the state-savers would get lost as a small component of the iostreams library, or we would have to have an introductory page with links to both libraries.
Yes, combining the docs at this point would be cumbersome. It would be nice if the docs had links to the other 'related libraries' so that people see the options.
Maybe the latter. (And don't forget that the introductory page would include the format library, which also shares "boost::io".) Eventually, the state-savers, the new iostreams, and the format libraries could all switch to Doxygen & BoostBook
Okay, the latter solution would be fine with me. How would you recommend the docs and tests be organized. One way would be to put the existing material for the iostreams library in the directory libs/io/iostreams.
I sort of think that libs/iostreams would be less confusing because there is no dependency between the iostreams library and the original boost::io. But it really could be either way...
After I wrote the above I started to think what would be involved in moving back to boost/io -- and it's not appealing. In particular, it would make it harder to paste the library into the 1.32 distribution, and it would force the current users, who are sending me valuable bug reports, to modify their code yet again.
Also, we should probably get Jeff Garland's view on this.
As for the overall question of the directory structure matching the namespace, that would be nice, but it doesn't seem practical at this point. There are already many violations of this in boost. So I'm fine with the directory being iostreams and the namespace being io.
Okay, if there are no objections, this is what I'll do.
Jeff
Jonathan
Jonathan Turkanis wrote:
Okay, if there are no objections, this is what I'll do.
This didn't come out quite right -- I know that Daryle has objected. I guess I mean: given the fact that the namespace-directory convention has already been widely violated, if there are no further objections I'll keep the library in the iostreams directory but use the io namespace. Jonathan
Jonathan Turkanis wrote:
Jonathan Turkanis wrote:
Okay, if there are no objections, this is what I'll do.
This didn't come out quite right -- I know that Daryle has objected.
I guess I mean: given the fact that the namespace-directory convention has already been widely violated, if there are no further objections I'll keep the library in the iostreams directory but use the io namespace.
I didn't see the whole thread, but we ought to try to avoid violating the convention any more than it has been. As Boost grows, this becomes more important. What's wrong with a namespace boost::iostreams? You can always introduce an alias for backward compatibility. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Jonathan Turkanis wrote:
Jonathan Turkanis wrote:
Okay, if there are no objections, this is what I'll do.
This didn't come out quite right -- I know that Daryle has objected.
I guess I mean: given the fact that the namespace-directory convention has already been widely violated, if there are no further objections I'll keep the library in the iostreams directory but use the io namespace.
I didn't see the whole thread, but we ought to try to avoid violating the convention any more than it has been. As Boost grows, this becomes more important. What's wrong with a namespace boost::iostreams? You can always introduce an alias for backward compatibility.
Since you didn't see the whole thread, let me quote myself: Jonathan Turkanis wrote:
I would greatly prefer to use the namespace "boost::io" because:
(i) it is much shorter than "boost::iostreams"; while it is possible to use an alias to shorten it, I'd hate to make users do this when there is a perfectly suitable short name available. (ii) there currently are not many declarations in the namespace "boost::io", so there is not much chance of collisions (iii) it is a more accurate discription of the library, since the core infrastructure is independent of the standard iostreams library and might be used without streams, e.g., for async i/o.
(i) is particularly important, since the documentation will contain a lot of tutorial material in which the namespace qualification can't be omitted, e.g., template<typename Sink> void put(Sink& dest, int c) { if (c == '\n') col_no_ = 0; else { if (col_no_ >= line_length_) this->put(dest, '\n'); ++col_no_; } boost::io::put(dest, c); } The occurence of boost::io::put in the above example has to be qualified, since otherwise it will refer to the member function being defined. I worry that having to use a long namespace name or to introduce a namespace alias in a high percentage of the examples will make the documentation harder to follow, and the library harder to learn. If I have to choose, then, I would much rather use the namespace io and move the library back to boost/io than use the namespace iostreams. Jonathan
Jonathan Turkanis wrote:
David Abrahams wrote:
Jonathan Turkanis wrote:
Jonathan Turkanis wrote:
Okay, if there are no objections, this is what I'll do.
This didn't come out quite right -- I know that Daryle has objected.
I guess I mean: given the fact that the namespace-directory convention has already been widely violated, if there are no further objections I'll keep the library in the iostreams directory but use the io namespace.
I didn't see the whole thread, but we ought to try to avoid violating the convention any more than it has been. As Boost grows, this becomes more important. What's wrong with a namespace boost::iostreams? You can always introduce an alias for backward compatibility.
Since you didn't see the whole thread, let me quote myself:
Jonathan Turkanis wrote:
I would greatly prefer to use the namespace "boost::io" because:
(i) it is much shorter than "boost::iostreams"; while it is possible to use an alias to shorten it, I'd hate to make users do this when there is a perfectly suitable short name available. (ii) there currently are not many declarations in the namespace "boost::io", so there is not much chance of collisions (iii) it is a more accurate discription of the library, since the core infrastructure is independent of the standard iostreams library and might be used without streams, e.g., for async i/o.
(i) is particularly important, since the documentation will contain a lot of tutorial material in which the namespace qualification can't be omitted, e.g.,
template<typename Sink> void put(Sink& dest, int c) { if (c == '\n') col_no_ = 0; else { if (col_no_ >= line_length_) this->put(dest, '\n'); ++col_no_; } boost::io::put(dest, c); }
Pshaw. After a few pages C++ Template Metaprogramming has an example that begins with: namespace mpl = boost::mpl; // namespace alias which it then follows with a note that says "Many examples in this book will use ``mpl::`` to indicate ``boost::mpl::``, but will omit the alias that makes it legal C++."
The occurence of boost::io::put in the above example has to be qualified, since otherwise it will refer to the member function being defined. I worry that having to use a long namespace name or to introduce a namespace alias in a high percentage of the examples will make the documentation harder to follow, and the library harder to learn.
So use the technique described above. And if you really can't stand that, do as I suggested originally and introduce the alias in Boost: namespace boost { namespace iostreams{} namespace io = iostreams; }
If I have to choose, then, I would much rather use the namespace io and move the library back to boost/io than use the namespace iostreams.
You don't _have_ to choose, but then you could do better than the status quo. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Jonathan Turkanis wrote:
I would greatly prefer to use the namespace "boost::io" because:
(i) it is much shorter than "boost::iostreams"; while it is possible to use an alias to shorten it, I'd hate to make users do this when there is a perfectly suitable short name available.
(i) is particularly important, since the documentation will contain a lot of tutorial material in which the namespace qualification can't be omitted, e.g.,
template<typename Sink> void put(Sink& dest, int c) { if (c == '\n') col_no_ = 0; else { if (col_no_ >= line_length_) this->put(dest, '\n'); ++col_no_; } boost::io::put(dest, c); }
Pshaw.
Huzzah!
After a few pages C++ Template Metaprogramming has an example that begins with:
namespace mpl = boost::mpl; // namespace alias
which it then follows with a note that says
"Many examples in this book will use ``mpl::`` to indicate ``boost::mpl::``, but will omit the alias that makes it legal C++."
I know how I would explain the convention; I'm just afraid people won't notice it, and will copy and paste from the examples and find they don't work. It's a bit easier in a printed book, in which there's some expectation that the material will be read from the beginning, than in a heavily hyperlinked web document, where reader are known to skip immediately to somewhere in the middle.
The occurence of boost::io::put in the above example has to be qualified, since otherwise it will refer to the member function being defined. I worry that having to use a long namespace name or to introduce a namespace alias in a high percentage of the examples will make the documentation harder to follow, and the library harder to learn.
So use the technique described above. And if you really can't stand that, do as I suggested originally and introduce the alias in Boost:
namespace boost { namespace iostreams{} namespace io = iostreams; }
Sorry, I didn't read your first post carefully enough. I though you were saying that users should perform the aliasing.
If I have to choose, then, I would much rather use the namespace io and move the library back to boost/io than use the namespace iostreams.
You don't _have_ to choose, but then you could do better than the status quo.
Okay, I'll hold off adding iostreams to CVS while I think about it some more. Jonathan
Jonathan Turkanis wrote:
David Abrahams wrote:
Jonathan Turkanis wrote:
I would greatly prefer to use the namespace "boost::io" because:
(i) it is much shorter than "boost::iostreams"; while it is possible to use an alias to shorten it, I'd hate to make users do this when there is a perfectly suitable short name available.
(i) is particularly important, since the documentation will contain a lot of tutorial material in which the namespace qualification can't be omitted, e.g.,
template<typename Sink> void put(Sink& dest, int c) { if (c == '\n') col_no_ = 0; else { if (col_no_ >= line_length_) this->put(dest, '\n'); ++col_no_; } boost::io::put(dest, c); }
Pshaw.
Huzzah!
After a few pages C++ Template Metaprogramming has an example that begins with:
namespace mpl = boost::mpl; // namespace alias
which it then follows with a note that says
"Many examples in this book will use ``mpl::`` to indicate ``boost::mpl::``, but will omit the alias that makes it legal C++."
I know how I would explain the convention; I'm just afraid people won't notice it, and will copy and paste from the examples and find they don't work. It's a bit easier in a printed book, in which there's some expectation that the material will be read from the beginning, than in a heavily hyperlinked web document, where reader are known to skip immediately to somewhere in the middle.
Then use some automated processing to ensure that every one of your examples begins with the single line: namespace io = boost::iostreams; And then your examples will become much more readable: io::foo instead of boost::io::foo. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Jonathan Turkanis wrote:
I know how I would explain the convention; I'm just afraid people won't notice it, and will copy and paste from the examples and find they don't work. It's a bit easier in a printed book, in which there's some expectation that the material will be read from the beginning, than in a heavily hyperlinked web document, where reader are known to skip immediately to somewhere in the middle.
Then use some automated processing to ensure that every one of your examples begins with the single line:
namespace io = boost::iostreams;
And then your examples will become much more readable: io::foo instead of boost::io::foo.
This sounds reasonable. Jonathan
On Wed, 29 Dec 2004 11:54:42 -0700, Jonathan Turkanis wrote
David Abrahams wrote:
If I have to choose, then, I would much rather use the namespace io and move the library back to boost/io than use the namespace iostreams.
You don't _have_ to choose, but then you could do better than the status quo.
Okay, I'll hold off adding iostreams to CVS while I think about it some more.
Sorry, still catching up on holiday email. Did a decision get made on this yet? Because I'd really hate to see the last conclusion: 'holding off on adding iostreams'. Since 1.32 is slowly fading into the sunset we have several new libraries that should be in 1.33 -- and the best way to avoid the long release cycle is to add those libraries early and get the regression testing cranked up before everyone is begging for the release to be cut... So I'd like to see a decision and see the library added soon. Besides, it will make it easier for me to use :-) Jeff ps: My analysis says the libraries accepted but not added list is as follows: Pointer Containers Container traits Iostreams Circular Buffer Named Params
Jeff Garland wrote:
ps: My analysis says the libraries accepted but not added list is as follows:
Pointer Containers Container traits Iostreams Circular Buffer Named Params
Where is our review wizard? He should be maintaining a web page with this sort of information on it. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On Mon, 10 Jan 2005 07:31:00 -0500, David Abrahams wrote
Jeff Garland wrote:
ps: My analysis says the libraries accepted but not added list is as follows:
Pointer Containers Container traits Iostreams Circular Buffer Named Params
Where is our review wizard? He should be maintaining a web page with this sort of information on it.
I've been helping Tom with it -- so the web is up to date -- my list came straight from here: http://www.boost.org/more/formal_review_schedule.html Jeff
Jeff Garland wrote:
ps: My analysis says the libraries accepted but not added list is as follows:
Pointer Containers Container traits Iostreams Circular Buffer Named Params
Where is our review wizard? He should be maintaining a web page with this sort of information on it.
I've been helping Tom with it -- so the web is up to date -- my list came straight from here:
That page also (incorrectly) lists 'MinMax' by Herve Bronimann and 'Numeric Conversions' by Fernando Cacciola as not added yet. Matt
On Tue, 11 Jan 2005 07:00:50 +1000, Matthew Vogt wrote
Jeff Garland wrote:
ps: My analysis says the libraries accepted but not added list is as follows:
Pointer Containers Container traits Iostreams Circular Buffer Named Params
Where is our review wizard? He should be maintaining a web page with this sort of information on it.
I've been helping Tom with it -- so the web is up to date -- my list came straight from here:
That page also (incorrectly) lists 'MinMax' by Herve Bronimann and 'Numeric Conversions' by Fernando Cacciola as not added yet.
Hmmm, I think minmax might have been added -- I'll double check that. In any case, you're just piling onto my point ;-) Jeff
On Mon, 10 Jan 2005 17:24:19 -0700, Jeff Garland wrote
That page also (incorrectly) lists 'MinMax' by Herve Bronimann and 'Numeric Conversions' by Fernando Cacciola as not added yet.
Hmmm, I think minmax might have been added -- I'll double check that. In any case, you're just piling onto my point ;-)
Both minmax and numeric conversions were added in 1.32...I'll update the review page -- so my original list was right :-) Jeff
At 09:51 PM 1/9/2005, Jeff Garland wrote:
ps: My analysis says the libraries accepted but not added list is as follows:
Pointer Containers Container traits Iostreams Circular Buffer Named Params
Hum... That's quite a list. We need to get these added and tested or 1.33 will take forever to get out the door. --Beman
Beman Dawes wrote:
At 09:51 PM 1/9/2005, Jeff Garland wrote:
...
Circular Buffer
Someone on IRC reported that this library can't be used with gcc 3.4.x (nor with gcc 4). It seems there hasn't been any progress on Circular Buffer since March 2004. Is this library already bit-rotting?
Hum... That's quite a list. We need to get these added and tested or 1.33 will take forever to get out the door.
At least, we should know whether the respective maintainers want them to be part of 1.33. I guess it would be a good idea if a submitter would post a schedule for the integration into the Boost CVS after a library has been accepted. I see questions like "when will this library be available" or "will this library be part of the next release" arise quite often. Regards, m
"Martin Wille" wrote:
Circular Buffer
Someone on IRC reported that this library can't be used with gcc 3.4.x (nor with gcc 4).
It seems there hasn't been any progress on Circular Buffer since March 2004.
Is this library already bit-rotting?
I hope not. If anything I can take its maintenance and put it in 1.33. /Pavel
Jeff Garland wrote:
ps: My analysis says the libraries accepted but not added list is as follows:
Pointer Containers Container traits
This is now called Boost.Range and is part of the current distribution.
Iostreams Circular Buffer Named Params
Jonathan
Jeff Garland wrote:
On Wed, 29 Dec 2004 11:54:42 -0700, Jonathan Turkanis wrote
David Abrahams wrote:
If I have to choose, then, I would much rather use the namespace io and move the library back to boost/io than use the namespace iostreams.
You don't _have_ to choose, but then you could do better than the status quo.
Okay, I'll hold off adding iostreams to CVS while I think about it some more.
Sorry, still catching up on holiday email. Did a decision get made on this yet? Because I'd really hate to see the last conclusion: 'holding off on adding iostreams'.
What I meant was I'd think about it some more before adding the library... I've now thought about it, and decided to use directory and namespace iostreams. So I will added it shortly. (I don't think there will be many problems porting iostreams, since I've already tested it on most of the supported platforms) Jonathan
Jonathan Turkanis wrote:
The occurence of boost::io::put in the above example has to be qualified, since otherwise it will refer to the member function being defined.
What I have to say has nothing to do with namespaces or directory placement, but... Given that in the documentation you speak of user-defined overloads of boost::io::read et al, it might be worthwhile to point out that two-phase lookup will not see these user overloads. If you want to have an overload customization point in a template, you have to use an unqualified call. And choose the identifiers wisely. :-)
Peter Dimov wrote:
Jonathan Turkanis wrote:
The occurence of boost::io::put in the above example has to be qualified, since otherwise it will refer to the member function being defined.
What I have to say has nothing to do with namespaces or directory placement, but...
Given that in the documentation you speak of user-defined overloads of boost::io::read et al, it might be worthwhile to point out that two-phase lookup will not see these user overloads. If you want to have an overload customization point in a template, you have to use an unqualified call. And choose the identifiers wisely. :-)
Of course, overloading isn't always the best approach (it introduces nasty ADL and complicated resolution rules), so consider using a static member of a class template that can be specialized, instead. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Peter Dimov wrote:
Jonathan Turkanis wrote:
The occurence of boost::io::put in the above example has to be qualified, since otherwise it will refer to the member function being defined.
What I have to say has nothing to do with namespaces or directory placement, but...
Given that in the documentation you speak of user-defined overloads of boost::io::read et al, it might be worthwhile to point out that two-phase lookup will not see these user overloads. If you want to have an overload customization point in a template, you have to use an unqualified call. And choose the identifiers wisely. :-)
Of course, overloading isn't always the best approach (it introduces nasty ADL and complicated resolution rules), so consider using a static member of a class template that can be specialized, instead.
Actually, I'm already implementing the read and write operations this way, and considered using this as a point of customization, but decided it would complicate the code too much. I think I'll just eliminate this point of customization altogether. Jonathan
Peter Dimov wrote:
Jonathan Turkanis wrote:
The occurence of boost::io::put in the above example has to be qualified, since otherwise it will refer to the member function being defined.
What I have to say has nothing to do with namespaces or directory placement, but...
Given that in the documentation you speak of user-defined overloads of boost::io::read et al, it might be worthwhile to point out that two-phase lookup will not see these user overloads. If you want to have an overload customization point in a template, you have to use an unqualified call. And choose the identifiers wisely. :-)
Yikes! I knew there were limitations to customization by overloading, but I didn't think I had stumbled over them yet. I objviously can't use unqualified calls here, or change the names. I arleady implement read, et al. by simulated tag-dispatch: template<typename T> inline std::streamsize read(T& t, BOOST_IOSTREAMS_CHAR_TYPE(T)* s, std::streamsize n) { typedef typename detail::dispatch< T, istream_tag, streambuf_tag, input >::type tag; return detail::read_impl<tag>::read(detail::unwrap(t), s, n); } I'd really hate to make read_impl and dispatch public, or to add yet another level of indirection. :( So maybe my best option is to excise those innocent-sounding passages you refer to, and require users to write wrappers if they want to integrate existing components into the framework. Thanks for pointing this out! Jonathan
participants (10)
-
Beman Dawes -
Daryle Walker -
David Abrahams -
Jeff Garland -
Joaquín Mª López Muñoz -
Jonathan Turkanis -
Martin Wille -
Matthew Vogt -
Pavel Vozenilek -
Peter Dimov