From: Reece Dunn (msclrhd_at_[hidden])
Date: 2003-12-08 17:00:24
Jonathan Turkanis wrote:
>I've looked at your library in detail now, except for the State Outputters.
>1. Surprisingly, partial template specialization is not necessary. See
>http://groups.yahoo.com/group/boost/files/outfmt_no_pts.zip for a version
>with no partial spec. A good deal of the library now works on VC6. As a
>effect, output deduction now works fully on borland 5.6.4. (I don't know
>about 5.5.1.) I've also tested it on Intel 7.1.
It also works on borland 5.5.1 :). I was thinking that it would be possible
to rewrite the deduction code using Boost.MPL, but didn't know that much
about it. Great work!
>The headers type_deducer.hpp and output_deducer.hpp had to be mostly
>rewritten; otherwise, I made some small changes to format_traits and
>pair_traits. A detailed list of changes is included with the zip.
I have had a look at the changes you have made. They have been included into
I have also modified the way hash containers are detected, improving the
detection method: it should now work for any SGI/dinkumware supported
compilers. I haven't looked at the slist container yet, but I agree that it
should be supported.
I have also added support for compilers that have older I/O stream libraries
without std::basic_ostream support. This means that GCC 2.95.3-5 is now
(partially) working. There seems to be a problem in
<boost/io/detail/output_deducer.hpp>, and the hash container stuff is not
working for some reason in <boost/io/detail/type_traits.hpp>.
>Because boost::remove_bounds requires partial spec, array deduction does
>work properly on VC6. There are apparently workarounds for common array
>types in boost-sandbox\boost\string_algo\detail, which you might wan't to
I will do :).
>2. My gut feeling tells me that the library can be simplified a bit. I'm
>particularly worried about the large number of object generators. Perhaps a
>more extensive tutorial would clear up some of my doubts. With your
>permission, I'd like to hack on the code a bit to see if I can make it a
>little simpler, without losing functionality.
Feel free. My reasoning as to having the three variants was thus:
 The base generator should supply default formatting type (char *) and
 Custom formatting types are supported as a function template parameter.
boost::io::formatlistex< wchar_t * >( l );
Since you can't define a default value, this has to be a seperate generator.
 Custom outputters are supported as a specialist generator.
boost::io::formatobout( o, ... );
These have different names because of problems with locating the correct
Each of these variants is required for each outputter class to allow maximum
>First, please let me know what you think of my changes.
My updated code is at:
Reece H Dunn
On the move? Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk