John Torjo wrote:

...

That is basically what I do already: wrappedfmt() is associated with openclose_formatter; pairfmt() is associated with formatter (using default_nary_traits) containerfmt() is associated with formatter (using default_sequence_traits) etc.

Yes, and that is great! But you hold them in the formatob object.

I have this relationship: formatob isa FormatObject isa formatter usesa DefaultTraits FormatObject hasa FormatObject

What I'm saying is that (overridable) defaults for each of the above can also be kept in the stream object itself.

I understand what you are saying, I am just looking at how to implement it.

...

so you can theoretically use any string type to store the default delimeter values. How do we do the equivalent with ios_base::pword/iword?

That's your job - to come up with a technique for this ;)

:)

Basically, the library's underlying concept doesn't have to change. This is just an extra goodie you can provide.

Sure.

...

openclose_formatter/formatter set their delimeter values to the values provided by the default traits object passed to them. You can then override these defaults by calling format(). How do you tell that the default has been overrided?

It's certainly possible. Internally, in the delim object, you can keep the data like this:

template<class value_type> struct val_keeper { value_type val; bool has_been_set; //getter and setter - I assume you get the point };

This might be easier if instead of formatter holding DelimeterType objects for each delimeter, have it store an io::delimeter< CharT > object and have that responsible for access, thus: template< typename CharT > class delimeter { private: const CharT * value; bool is_set; public: const CharT * get() const{ return( is_set ? value : ios_base::pword -> value()); } void set( const CharT * v ){ value = v; is_set = true; } delimeter(): value( "" ), is_set( false ){} }; and template< typename CharT > class formatter { public: delimeter< CharT > separator; // separator is now a property! };

...

The main questions are: [1] how do you store different DelimeterTypes in this mechanism?

Which brings us to ;) : I think one type of delimeter is enough (I assume you wholeheartidly disagree with this).

I don't wholeheartedly disagree... I am open to persuasion ;)

This type should be the std::basic_string<underlying_char_type>().

This would still mean that you have one per underlying_char_type, so the same problem exists although it is now in a smaller problem domain. My main reason against using std::basic_string as the storage type is performance (excessive copying of the delimeter values). Also, what about managed strings in C++/CLI? Don't they require a String^ type, or am I missing something? Regards, Reece _________________________________________________________________ Get ready for school! Find articles, homework help and more in the Back to School Guide! http://special.msn.com/network/04backtoschool.armx