Jingz said:
I know I can't win, you are in quite authoritative company in terms of
people I've argued with about programming paradigms, and I know anyone
reading this agrees with you, not me, but I do feel compelled to stick to
facts.
Microsoft thinks defined like "BOOL" and "WORD" make sense, so I'm not
quite sure invoking problems with their source code is credible.
The Microsoft Windows API is written for C compilers somewhere in the
eighties, they could not use C++ features. The choices they made do not
always make sense from a C++ point of view. Besides that Microsoft does not
always make the best possible technical decisions. Short macro names like
"BOOL" and "WORD" are likely to clash. The reason that they don't clash
that often in reality is that most programmers know that those names are
I have
indeed never seen a sane define collide in the manner you suggest happens
"all the time" but if we're going to assume insane programmers then you
can prety much claim anything you choose.
What you say may make sense for small projects, but with large complicated
projects the rules change. Problems that might seem accademic in one
context, may become a very real problems in another context. For example if
you use multiple 3rd party libraries or work on a large projects, name
clashes are not all that uncommon. I'm not making this up, I'm speaking from
personal experience. The usual workaround for these problems is using a
prefix for macro names. But what if two 3rd party libraries have name
clashes? In that case you are in deep shit I can tell you. Sure you can
modify the header files. But that means maintaining your own version of that
header file. Every time a new version of the library is released you will
have to do the modifications again. This can become quite a headache, and
therefore one should be extremely reluctant to do so.
Namespaces provide a much more elegant and scalable solution for the name
clash problem than prefixes. However preprocessor symbols don't care about
namespaces. Neither prefixes nor namespaces guarantee that you won't have
name clashes, but they do diminish the change you will get one.
I certainly agree that c++ promotes code cloarity and maintainability, no
question about it, but te fact that it can is often used as a cudgel to
beat code with. Complicated multiple inheritance, templates, and bizzare operator
overloading are automatically easier to maintain? I think not. They CAN
be, but care must be used, as in all programming.
I absolutely agree with the last sentence. C++ is a very powerful
programming language; in the right hands wonderful things can be done with
it, but in the wrong hands it is more like letting a monkey play with a gun.
In general I think the designers of the C++ made pragmatic decisions. Most
features in the language are there for a (good) reason, even if they don't
seem make all that much sense at first.