RE: [boost] (no subject)

From: Paul A. Bristow (boost_at_[hidden])
Date: 2003-03-31 12:30:12

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]]On Behalf Of Reece Dunn
> Sent: Sunday, March 30, 2003 12:18 PM
> To: boost_at_[hidden]
> Subject: [boost] (no subject)

Thanks for repackaging the code inside zip, and for mor examples, and
making it work 'strictly' MXVC 7.0 Level 4 & NO language extensions with

> template< typename CharT, class TraitsT, typename ForwardIterator >
> inline std::basic_ostream< CharT, TraitsT > & operator<<
> (
>    std::basic_ostream< CharT, TraitsT >  & os,
>    formatlist_t< ForwardIterator > const & fi
> );

> I shall look at adding support for 2D or nD output, however, this was not in
> the initial design plans. As the name formatlist suggests, this was intended
> for list outputting (1D) only.

For array and matrix, you might of course like to see the Boost contributions in
array and UBLAS.  But handling at least 2D and 3D C arrays is still acommon
requirement.

> I was gauging interest before I worked on more complicated examples. As for
> documentation, I was looking at getting the design stabilized first,
> otherwise there may be problems synchronizing the documentation with the
> code.
>
> I have produced a more complicated set of examples that demonstrate the
> applicability of my formatlist manipulator.
>
> I have a few ideas on where I would like to take this:

> [1] I would like to parametize the seperator and open/close list types to a
> template type. This will allow the character type used by my current
> implementation, as well as a character array, std::string and possibly other
> types like wide characters.
Some people are turned on by wide characters.

> [2] I have recently had a look at the "I/O operationd for STL containers"
> thread. Is there a way we can merge these two threads, or should they be
> kept seperate? There are similarities and differences to both approaches.

> Both are an attempt to solve a similar problem from different angles.
>
> The io_format approach is very nice - I like the way it hooks into the I/O
> stream state mechanism to make the usage for a type intuative; it does,
> however have a complex setup for each type on each output stream that uses
> that type. Also, what are the run-time overheads for the use of the xalloc
> mechanism, especially if a lot of different containers need to be outputted?
>
> My approach does not handle std::pair or nD object output, nor does it
> support seperators or list brackets that are wide characters or strings
> (although I am looking at generalizing this). The point of my version was to
> allow the output of a list specified between two iterators with a
> specialization for containers to save writing:
>    std::formatlist( c.begin(), c.end())
> every time you needed to output the entire container. I also wanted an
> implementation that has a small run-time overhead.

I also note the complexity of the xalloc with some concern.
The simplicity of formatlist is appealing.

> [3] Would it be possible to combine both approaches into a single library,
> where the user can choose which version to use: state objects (io_format);
> or manipulators (formatlist)?

Sounds interesting.

> [4] I am intending on changing the stl namespace to something more
> appropriate. Any suggestions are welcome.
Doubt that you should worry at present - boost\io\ may be suitable?

Your new examples show how easy it is to use.

Paul

Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB  UK
[phone]   Mobile [phone]
Mobile mailto:pabristow_at_[hidden]
mailto:pbristow_at_[hidden]