Boost logo

Boost :

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2004-09-13 07:09:53

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


>>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
         const CharT * value;
         bool is_set;
         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 ){}


   template< typename CharT >
   class formatter
         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


Get ready for school! Find articles, homework help and more in the Back to
School Guide!

Boost list run by bdawes at, gregod at, cpdaniel at, john at