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

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

ultranet wrote:

#ifdef UNICODE
typedef std::wstring tstring;
typedef proprietary::WString TString;
#else
typedef std::string tstring;
typedef proprietary::String TString;
#endif

I'd rather not do that, to keep namespaces intact.

Do you think macros don't disrupt symbols in other namespaces? Macros are even worse, because they make the substitution completely blindly, without any consideration to their real meaning. At least with typedef, you can be sure it's not going to disrupt types in other namespaces, member functions in other classes, etc.

Every time I #include <windows.h>, it completely messes up a bunch of names. For example, the first thing I have to do is #undef min, #undef max, #undef abs, otherwise my code usually doesn't compile. windows.h macros also redefine a number of .NET classes and member function. Using macros to rename types and function names is pure evil, because it also renames every symbol, without consideration where they belong to. For example, if I roll my own class:

class C
{
public:
std::string TString() const { return "hello"; }
};

Your macro will completely disrupts my member function, because it's renaming it. If it happens to be an imported class from a DLL, it won't link anymore.

The typedef version doesn't have this problem, because it's context sensitive, and won't replace symbols in other namespaces and classes.

Wrap your typedefs into a namespace to avoid name collision with other TString types. That's the solution to namespace conflicts. Macros just make things worse than typedef, not better.

If you absolutely have to use macros, which is inevitable sometimes, make sure they're in all caps and as unique as possible. For example, ULTRANET_TSTRING is unlikely to conflict with anything. A good example to proper macro naming in modern C++ code is BOOST_STATIC_ASSERT.

Tom
.

Relevant Pages

  • Re: CL vs scheme macros, namespaces.
    ... > I've heard that CL macros are more poweful than Scheme macros. ... > It seems to me that CL's 2 namespaces confers no particular advantage ... (block foo ...) ...
    (comp.lang.lisp)
  • Re: Index a #define string
    ... > templates are for. ... > to many things that macros were used for at one time. ... > templates are a great feature for what they are intended to do. ... Namespaces do not exist to protect from name collisions. ...
    (comp.lang.cpp)
  • PRI* considered harmful
    ... PRI* Considered Harmful: ... standard typedef names, such as time_t, to the appropriate int*_t type, ... The next suggestion is inevitably to define a pair of macros: ...
    (comp.std.c)
  • Re: typedef vs. #define
    ... Looks quite ugly to me, I'd prefer 'typedef' these types, ... I prefer the readily changable part of the code to be macros. ... void ssort(e_type *array, size_t nmemb) ...
    (comp.lang.c)
  • Re: printf specifications
    ... OK but those are MACROS that should expand to SOMETHING... ... just as int128_t would be a typedef that expands to something. ... An implementation can define a 128-bit extended integer type. ...
    (comp.std.c)