Here is a good example of what can happen to you due to CUMs:
// this would typically be in another compilation unit
// and the header be included in the main program
class TextEditor
{
//...
public:
//...
void LoadFile(const char* name)
{
//...
};
char * FindText(const char* search)
{
return (char*) 0; // ok, there are better search algorithms ;-)
};
};
// the main program goes here...
#include <windows.h>
int main()
{
TextEditor t;
t.LoadFile("foo.txt");
char *c = t.FindText("some text"); // oh surprise... a missing symbol
return 0;
}
You will not be able to build this because your class has an unresolved symbol. Why is there an unresolved symbol, you wonder. Everything is correct, isn't it?
Yes, except that some freaking moron at Microsoft deemed it a good idea to implement Unicode support by defining a macro for each and every Win32 API function name (such as for example
FindText).
Thus, if you include "windows.h" after including your own header, your member function is renamed to
FindTextA or
FindTextU, depending on whether you compile with Unicode support or without!
You can spend weeks searching for errors in your code where there are none, and you will never find out why it does not work. Aren't macros just great?
