Re: [boost] Re: Formal review of "OutputFormatters"library beginstoday

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