Reece Dunn wrote:
John Torjo wrote:
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.
<light-bulb = on>! ;)
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 ;) ?
C++/CLI implements it's String objects as wchar_t * strings. In VC7.x you do
Haven't used CLI, but doesn't it also have std::string? (just asking)
You would need to convert to an ASCII string if outputting on std::cout.
For C++/CLI, I guess you could simply output to std::wcout 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)