Qualified Names / Re: Standardized Predefined CPP Symbols ...

[David Canzi]

>     If predefined symbols were all to begin and end with underscore 
>     characters, and this fact were documented,
>     then nobody would fall into the trap of inadvertently using one.
> 
> Why do I continually run across the suggestion that prefixing names
> with underscores makes them unique, as if no one has used underscore
> characters for some special purpose before ?  

The important part of my suggestion was that the convention used be
documented.  (I ought to have added that it should be mentioned in every
document, manual page, or tutorial where it is relevant, so that no 
C programmer could help but know about it.)  Whether the names should
look like "_whatever_", or "cpp_whatever" doesn't matter.  As long as there is
a simple rule for avoiding names that may get magically predefined on you.
Computer systems should not spring surprises on users.

> What is really needed is a name qualification or prefixing convention
> that can be applied across all of UN*X, [Why only UNIX? - DMC] for example,
> 
>     <prefix> "_" <mnemonic name>
> 
> The prefix would be the name of the program or routine package;
> for example, "cpp" for the C Preprocessor, "lp" for the Pascal Library, &c.
> Thus, "unix" would become, for example, "cpp_unix", 
> "waterloo" would be "cpp_waterloo", and Pascal Library "IN" could be "lp_in".
> This isn't perfect, but it's much better than what we have now.
> Too bad that use of the UN*X subroutines with unqualified names,
> for example, "read", "write" is too well established to change now.

What you seem to be suggesting sounds horribly tedious.  Well-known and
frequently used routines like printf, or getchar should not have prefixes.
Only things the typical programmer doesn't need or want to know about (eg.
predefined preprocessor symbols, internal library routines, and perhaps
system calls) should get prefixed.  If I had to say things like 
"cl_printf(...)" or "cl_getchar()" all the time, I'd go looking for 
another programming language.