Re: Is there a convention mandating macros to be all-uppper-case?



"Tamas Demjen" wrote:
Generally speaking, the std namespace belongs to the standard library
EXCLUSIVELY. I strongly discourage you to make your own declarations in
the std namespace, unless you are a standard library vendor (even they
use double underscore names for every internal type not mentioned in the
standard). If I'm not mistaken, the standard explicitly prohibits you
(as a std library user) from adding your own declarations to the std
namespace:

http://www.ishiboo.com/~nirva/c++/stl-ref/lib_cpp.html

If it's at all possible, try to use your own namespace here.
OK, there's 1 company whose not following standards well enough i don't
like, although i hear it's changing, so i don't want to be among standard
violators. ;)

Here's the obfuscated new version:
#include <string> // for com::company::std::tstring

#include <proprietary.h> // for com::company::proprietary::TString

#include <proprietary2.h> // for com::company::proprietary2::TString...

// Introducing a namespace to avoid definition of names in original
namespaces:
// in case of std, it appears it would be a standard violation. Plus, this
ensures global uniqueness.
namespace com {
namespace company {
// If and when std introduces tstring type, com::company::std in using
namespace declarations will need to be
// replaced with std, if applicable.
namespace std {
#ifdef UNICODE
typedef ::std::wstring tstring;
#else
typedef ::std::string tstring;
#endif
}

namespace proprietary {
#ifdef UNICODE
typedef ::proprietary::WideString TString;
#else
typedef ::proprietary::String TString;
#endif
}

namespace proprietary2 {
#ifdef UNICODE
typedef ::proprietary2::WideString TString;
#else
typedef ::proprietary2::String TString;
#endif
}

}
}

The problem with corrupting the std namespace is that the standard may
change in the future, and if they add their own tstring type, it will
conflict with yours. Think of std as a strictly reserved namespace.
Adding anything to it is like adding your own C declarations to the
stdlib.h file.
Although i've made the change, i actually think violating the standard might
have been more maintainable:
if std introduced this type, i may not have needed to change any files,
because my std::tstring would be identical to standard std::tstring, and
whichever one is picked, compilation would have succeeded. With this version,
however, if a file does:

using namespace std;
using namespace com::company::std;

tstring becomes ambiguous, so
using namespace com::company::std;
will have to be removed in the future.

This is one case where i'd like to break the standard defining an std::
type, but i'm too honest to do it. ;)
.

Relevant Pages