[boost] I/O Formatting Manipulators (update)

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2003-05-11 15:46:09

Guillaume Melquiond wrote:

> > This is a patch to the library, until I can get CVS working. It adds 
>several
> > new features:

>Since this library seems to offer an interesting way to deal with interval
>display, I wanted to give a try. Unfortunately, the zip file does not
>contain all the needed files (format_objects/basic_output.hpp for
>example). So I took a quick look to the archives of the mailing-list but I
>only found that you were unfortunately unable to access the sandbox cvs.
>Could you please post a link to a more complete version of the library?

The most recent source code can be found at:
   http://lists.boost.org/MailArchives/boost/msg46761.php

The update for this can be found here:
   http://lists.boost.org/MailArchives/boost/msg47297.php

>I was unable to use your library, but I still looked at the code. And I
>have a little advice: do not include "boost/numeric/interval.hpp" but
>rather include "boost/numeric/interval/interval.hpp". Since you don't use
>any functionality of the library, "interval/interval.hpp" is enough. It
>may greatly reduce compilation time, and in this way the Interval library
>won't bust your library if the compiler/architecture of the user is not
>supported.

Thanks for the advice.

-----

John Torjo wrote:

>I think it's possible to determine, in function boost::io::formatlist, if a
>container is associative or not. Therefore, it would simplify writing
>maps/multimaps/sets/etc. to streams.
>I could dig further to see if it's possible.

Although you have provided code that uses allocator_type to determine if a 
container is associative or not, so you don't need a compiler with partial 
specialization (neat!) there is a much larger issue:

In order to use that code, you need to be able to map the Outputter template 
argument to the correct output functor class, and this is harder than it 
first appears. In order to accommodate this intended functionality, the 
library would need to be redesigned to supply the output type as a parameter 
to the class and partial specialization would be required as well. This is 
needed so you can then use it to deduce the Outputter type:

[Example:

// not exact:

template< typename T >
class outputter_traits
{
   typedef basic_outputter outputter_type;
};

template< typename T, size_t N >
class outputter_traits< T[ N ] >
{
   typedef array_n_outputter< T, N > outputter_type;
};

// etc.

template<
   template class Pair< typename T1, typename T2 >,
   class Outputter1 = outputter_traits< T1 >::outputter_type,
   class Outputter2 = outputter_traits< T2 >::outputter_type >
class pair_output{ ... };

template<
   class Container,
   class Outputter = outputter_traits< typename Container::value_type 
 >::outputter_type
class container_output{ ... };

// etc.

--end]

It would then be possible for the compiler to deduce the correct outputter. 
I would need to think about this more to get a working version, and I don't 
know if it is possible for compilers without partial specialization. All in 
all, I think it would be too complex to implement successfully.

Regards,
Reece

_________________________________________________________________
Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile