"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

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

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

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

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

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

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.

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

Since you didn't see the whole thread, let me quote myself: Jonathan Turkanis wrote: 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

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

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

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

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

That page also (incorrectly) lists 'MinMax' by Herve Bronimann and 'Numeric Conversions' by Fernando Cacciola as not added yet. Matt

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

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

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

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. :-)

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