Yeah, I'm getting that point. To be honest I seldom use std::string and
only had this in my code to consume other code that needed it. It works OK
possibility of clashing at some time. Doesn't seem to now though.
In article news:<5BDD1B48-AC73-43A7-B350-93B39EC6ED88@microsoft.com>,
Tom Serface wrote:
In addition to what keet answered you may want to do definitions for
tstrings to account for Unicode vs. ANSI with something like:
#include <string>
#include <sstream>
namespace std {
#if defined _UNICODE || defined UNICODE
typedef wstring tstring;
typedef wstringstream tstringstream;
#else
typedef string tstring;
typedef stringstream tstringstream;
#endif
}
Then you can use tstring rather than string in a way similar to
using the _T and TCHAR paradigm for other strings and chars.
Bad idea, it's undefined behaviour to extend namespace std.
Specifically, 17.4.3.1 of ISO/IEC 14882 (1998) says:
It is undefined for a C++ program to add declarations or definitions
to namespace std or namespaces within namespace std unless otherwise
specified.
(and then goes on to say that it's OK to add specializations of
templates that are already in std).
The point is that you might inadvertently add something that introduces
a name clash with something in (some implementation of) std which might
just refuse to compile, but might compiler and give unexpected results.
You might prefer to do something like:
namespace mystuff
{
#if defined _UNICODE || defined UNICODE
typedef std::wstring tstring;
typedef std::wstringstream tstringstream;
#else
typedef std::string tstring;
typedef std::stringstream tstringstream;
#endif
}
and then use mystuff::tstring (etc) in your application.
Cheers,
Daniel.