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! };
that's what I was actually aiming at ;)
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
Nope, in this case, the problem does not exist. It's because you have this correspondence: 1 stream - 1 underslying character type - 1 object that can keep delimeters As oposed to: 1 stream - N delimeter_types - N objects keeping these delimeters.
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?
whoa. I have no idea. But I do think that std::string should work ;) Or am I dreaming ;) ? Best, John -- John Torjo -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4.0 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)