Dave Tweed wrote:

> olin_piclist@embedinc.com (Olin Lathrop) wrote:
>> Gerhard Fiedler wrote:
>>> In a sensibly designed language, the user wouldn't create names in
>>> the same namespace where the standard library function names are.
>> 
>> None of the mainstream languages I've used had a reserved namespace
>> for standard library functions. In fact, C is unusual with its
>> notion of standard library functions.

C++ has a namespace "std" for its standard library. The functions in
there are not treated any special (even though, in the sense of the
discussion around built-in vs library, they could be as the compiler can
assume it knows what they are doing). A user may define functions in the
std namespace, or override any of the library functions with his own
implementation. But no reasonable user will define his own symbols in
the std namespace. The namespace is there to avoid name clashes.

Java also has what you can call namespaces for their library functions
(mainly java and javax); they just call them packages. Works similar to
what I described above. It's not such a rare concept.

> I think that's what's special about C relative to most other compiled
> languages. Yes, there's a "standard C library", but it is in fact
> completely distinct and separable from the language/compiler itself.
> You can write major applications -- especially embedded applications
> -- in C without even once calling a standard library function. I
> know, because I've done it. I've even replaced parts of "crt.s"
> (implicit code in the library that sets up the environment for and
> supports the compiled code, usually in assembly language) without
> fuss.

I think pretty much every embedded C developer has done this at one
point or another. (Even though some standard library functions are so
small that deliberately avoiding calling them and instead doing it with
custom code doesn't buy much if anything.)

> Some of the participants in this thread are downplaying the whole
> notion of separate compilation with an explicit linking step that is
> actually a fairly key part of C. This is what allows you, for
> example, to replace a standard library function wtih a custom
> implementation, again, with little to no fuss. Suppose you don't need
> the full-blown functionality of printf(), with its dependency on the
> floating-point library, etc. Just write your own and link it in ahead
> of the standard library and it will be used instead. 

Exactly. I think this flexibility is a good part of the popularity of C.


>> Some operating systems take care to use special naming for their
>> routines that are easily avoided by the user, but unfortunately Unix
>> and Windows are not among them. The standard C library routines and
>> Unix routines are particularly bad in this regard.
> 
> Well, now you're conflating several issues, few of which have
> anything to do with the actual definition of the language. Library
> naming issues are a problem in any language. 

There isn't really anything that would prevent a compiler vendor to ship
a library with its compiler where the Windows API is in namespace
"windows", the Posix API in a namespace "posix" and so on. They don't go
there, I think, because of the extra work required to wrap the Microsoft
etc. headers. (There is the functionality in the standard Microsoft C
headers that depends on the preprocessor, and the C/C++ preprocessor
doesn't know namespaces, so at least for C++, this would probably
require quite some work.)

Gerhard
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist