Terje Slettebų wrote:
I've some concerns, though:
1. Are "default" breaces/separators possible? I'd rather not use
io_format every time I had to output a vector.
Good point. As it is now, it just defaults to empty strings for the
separators. Any idea how to specify such a default? If it's specified in the
header, it may be hard to select one that is sensible for all people.
I've no problems with hardcoding. But if you want, you might user static
members of the same class which provides pword() index via another static
method. And there should be default default.
2. Is that good idea to set brace style on vector<int> and vector<double>
separately? It would increase pword() array, and not sure if this will
benefit us much. Are nested containers the primary motivation?
Another good point. I guess there isn't any point in separate formats for
different element types, no.
The way it works now is that it instantiates an
basic_composite_format<CharType, TypeToOutput> (name changed from
basic_io_format), containing a static function with a static xalloc() index,
for each type to be output. Thus, it's parameterised on a type, not a
partially specified type.
Yes, I've see that too.
I'll look into this, as well. Partial specialisation, inheriting from a
less-parameterised base comes to mind.
Hmm... I bet you'd need template template parameters for that.
template<class charT, template <class T> class container>
class basic_composite_format {
};
Alas, this is not very allocator-friendly :-(
There are also some other issues: The current version assumes basic_string
for the delimiters. I've found it hard to let it take an arbitrary string
type, as the format-object (which the manipulator, basic_composite_format,
doubles as) stores a format parameterised on type to output and character
type. The latter is so that if multiple streams with different character
types are used, they should not use the same format-object..
Is assuming basic_string really a problem?
By the way, just for fun. Adding the following output operator for arrays,
to the header I gave in the previous posting:
int main()
{
char board[3][3]=
{
{'O','X','O'},
{'X','X','O'},
{'O','O','X'}
};
std::cout << io_format<char (&)[3]>("\n|","|\n","|")
<< io_format<char (&)[3][3]>("-------","-------","-------")
<< board << '\n';
}
we get:
-------
|O|X|O|
-------
|X|X|O|
-------
|O|O|X|
-------
"Shall we play a game?" :)
Sure thing :-)
The names and interface is just chosen tentatively, and I'm open to
suggestions for better names. I changed the "*io_format" names to
"*composite_format", as it reflects better what it does, and reduces the
chance for name collision. I didn't want to call it container_format, or
something like that, as it's not restricted to containers, but may output
any composite object, given suitably defined output operators (such as
std::vector, std::pair, arrays, etc.)
I like the names.
Thanks for the feedback.
You're welcome. After all, it's me who's bored to use custom code ;-)
I've uploaded the new version here
(http://groups.yahoo.com/group/boost/files/composite_stream_operators/).
There are two more points:
1. Could you put this to the sandbox, too. Yahoogroups is less convenient.
2. I think that we better have separate headers for stl containers, like
suggested in my original email (<boost/io/vector.hpp>, etc). That's
because I'd like to output maps, but would not like to include <map> when
I need to output a vector.
What do you think?
- Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost