> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Reece Dunn > Sent: Sunday, March 30, 2003 12:18 PM > To: [EMAIL PROTECTED] > 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 +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost