[boost] (no subject)

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2003-03-30 06:17:53

Paul A Bristow wrote:

>This is quite neat, and works for me using MSVC 7.0 but:

Thanks. Comments always welcome.

>1 The layout is screwed up by the mail attachment process and requires some
>editing to avoid compile errors.

I have zipped the file. This should prevent the layout being modified by the 
mail program. I chose not to modify the format as this would destroy the 
layout rules I use to make the code, in my opinion, easier to read and use.

>2  The filename formatlist.hpp might be better?

I agree. The change has been made in the supporting file.

>3  Requires language extensions enabled.
>[snip]
>for the line
>std::cout << "list = " << stl::formatlist( v ) << '\n';

This is because stl::formatlist has the signature:

namespace stl
{
   template< typename ForwardIterator >
   inline formatlist_t< ForwardIterator > formatlist
   (
      ForwardIterator first,
      ForwardIterator last
   );
}

returning a non-reference type. This is needed because of the way it works, 
but the problem lies in the output operator:

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

>I suspect this can be cured to make it more Standard and more portable?

The solution is to make the above:

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
);

>4  I haven't tried with the all important 3 and  more dimensions like 
>matrixes.

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.

>5  Many more examples and documentation desirable, of course.  My slightly
>longer test file attached. (Last example might suit input to a spreadsheet 
>using
>tab as a separator?)

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.

>and finally a nit -  Separator is wrongly spelled.

This has been corrected. Thanks.

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.

[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.

[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)?

[4] I am intending on changing the stl namespace to something more 
appropriate. Any suggestions are welcome.

[5] I'm thinking of removing the spacing options from my formatter in favor 
of the string approach used by io_format. This would be used in combination 
of templatizing the string parameter as in item [1].

-rhd-
mailto:msclrhd_at_[hidden]

_________________________________________________________________