Re: Why not add namespace feature into standard C?

P.J. Plauger wrote:
<websnarf@xxxxxxxxx> wrote in message
toolmaster@xxxxxxx wrote:
Since many of the modern computer languages have built-in namespace
features, I can't understand why not add this feature into standard C.

Because the standards people were more concerned with adding arbitrary
declaration positioning,

Widely requested.

You couldn't find a weaker reason? C++ *has* to have it to control the
order of constructor invocation in your code. C has no such issue. If
you can always assume that declarations are at the top of scope, you
can read your code more easily. If you're going to just add things
capriciously like this, you might as well adopt Perl's attitude towards
syntax.

the // comments,

Widely presumed to be already valid, thanks to C++.

Yes, but the point is that its superficial, but creates a backwards
compatibility problem.

complex numbers that are
incompatible with C++,

Which predate the C++ effort, so they're to blame for this one.

It does not predate C++'s natural behavior. If you're going to do this
obviously you want a template, not a fixed type; you know for "Guassian
integers". Secondly, you have to justify its inclusion. The only
people who need to use complex numbers are people who already know how
to implement them.

variable length arrays which are incompatible
with gcc,

Which has made next to no effort to do even the things required
by C99 that don't cause any backward compatability problems.

Good deflection. Somehow I think gcc has somewhat more mindshare than
C99 does. It would probably have been a good idea to consider this
when you made the standard.

the "inline" placebo (register anyone?),

Also widely requested, and more than a placebo.

Its a placebo for *real* compilers. You could have at least been
consistent and use the word "register" again. But instead you continue
to deceive people about what this placebo really is.

and an unqualified
"restrict" keyword.

Also requested by the vector processor folks, after they had
several years experience using it.

The emphasis is on "unqualified". Vector processor folks were
desperate for something that worked for them so they could actually
write useful C libraries in Fortran. To be generally applicable,
however, its obvious that you want to set up distinct sets of
non-aliasing pointers, so that one group of pointers can be considered
non-aliasing of each other, but not of other pointers in the same
scope.

In short, I don't understand either.

No, I wouldn't expect you to.

Namespaces and parameter references (which essentially provides a
compile time guarantee that a pointer is valid) are two "obvious"
features from C++ that would be a good thing to add to C (since they
have nothing to do with OO programming, and have obvious value.)

And some subtle semantic implications that have yet to be worked out
completely in C++.

Oh don't leave me in suspense ...

I've heard many people complain of the lacking of namespace in C. Of
course, namespace doesn't eliminate name polution, but it helps more
than just to put some prefix before a function name.

Actually its a *critical* problem with C. Trying implementing a swap
macro in a namespace safe way. The best you can do is to have an
obfuscated symbol prefix. With namespaces you can at least do the
following:

namespace swaptemp;
#define swap(x,y,type) {
type swaptemp::tmp = (x);
(x) = (y);
(y) = swaptemp::tmp;
}

So as long as people stay away from the "swaptemp" namespace, this will
work regardless of what variable name is chosen for x or y.

And so long as you don't define a function or macro called swap,
or a macro called swaptemp, or a macro called tmp. Big win.

Oh yeah, you're right, namespaces are totally useless. Its too bad I
couldn't come up with a possible use for them.

Is it because adding namespace will make C more complex or some
other reasons?

I think its just misplaced priorities. The C standards people *DID*
add a lot of things into the C99 standard (including some C++ things)
-- they just picked the *wrong* things.

Perhaps that's because you weren't there to guide us...

All the compiler vendors have balked. You don't need *me* to guide you
-- why didn't you just ask the compiler vendors who you are beholden to
anyways? Why don't you set criteria other than "widely requested" for
extensions to the language? Why don't you take a look at what is
happening with other languages?

The C language is in decline, and the features in C99 are not focused
towards recapturing mindshare. The reason its losing mindshare is
because other languages are solving real problems in programming that C
does not. The point is that you people in the ISO C committee are not
making any effort whatsoever to identify or address any of these
problems (with some spot exceptions like stdint.h, va_copy(), more
precise FP functionality), so results like the C99 fiasco are the
result.

There are so many obvious avenues that need to be addressed:

1. Memory management -- other languages use GC to good effect, and
highlight the weakness of C's malloc/free system. Since adding GC to C
is out of the question, the obvious alternative is to improve the
malloc/free system (my personal take is to have multiple heaps, a
"freeall" function, a heap walker, a getsizeofallocation() function, as
well as basic statistics to know whether or not I have leak) to
minimize the percieved weaknesses.

2. Lambda/metaprogramming -- this is a feature of languages like Lisp
which they've been able to hang over the heads of other languages for
ever. But meta-compiling in general is a very useful feature. The
obvious place to put this in is the C preprocessor. Another advantage
to beefing up the preprocessor is to try to replace the "interpreted"
sprintf()/sscanf() style functions into faster inline functions, that
don't necessarily force the linking in of floating point support.

3. Some sort of threading support -- since this is so hard to do
portably, just adding coroutines is the obvious compromise that makes
the most sense (there are no deadlock or race conditions that naturally
result, is fairly easy to implement, and there is obvious precedent for
it in the Lua and Python languages.) Also the C library should be
supplemented with functions that have full reentrancy support, since
most modern systems do have real multithreading.

4. Add in extensibility to the printf/scanf functions, or a extensible
version of them. Clearly the printf/scanf family of functions should
be used as at least a plausible way for general (de)-serialization of
datastructures. This would require a guarantee of a maximally
injective mapping of floating point through printf.

5. Add in functions that are easily emulated, but otherwise map to
native instructions for many CPUs. (Hiword multiply, bit count, bit
rotation, endian swap, multiply-then-add, sincos(), log2(), exp2(),
etc.)

6. Fix numerous problems: 64 bit or bitless file pointer, get rid of
gets, add in some *useful* rand() functions (like a long randl(), float
randf())

7. And obviously you could add something like STL for C.

If you added these things, the language would be *CLEARLY* better than
what it was before, and really put the question to those who are using
other languages. It also does not change the core nature of the
language to add these things.

Remember that most C compiler
vendors today are also C++ vendors. So the compiler people already
know how to add namespaces into their compilers.

Well, yes, they just don't know exactly what semantics to ascribe
to them.

This doesn't seem to have stopped Bjarne Stroustrup. He at least is
considering adding really useful things to the next C++. Things that
will really put the question to other languages that are pretending to
be better than C++.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

.

Relevant Pages

  • Re: Why not add namespace feature into standard C?
    ... features, I can't understand why not add this feature into standard C. ... macro in a namespace safe way. ... And so long as you don't define a function or macro called swap, ...
    (comp.lang.c)
  • Re: Forth from the perspective of Python
    ... word comparable to keys is WORDLIST-WORDS; if I SEE that, ... in a complete application different languages lead to different ... wrt to specific features you mentioned: ... next revision of the Forth standard? ...
    (comp.lang.forth)
  • Re: Why not add namespace feature into standard C?
    ... features, I can't understand why not add this feature into standard C. ... compile time guarantee that a pointer is valid) are two "obvious" ... macro in a namespace safe way. ...
    (comp.lang.c)
  • Re: Why not add namespace feature into standard C?
    ... I've heard many people complain of the lacking of namespace in C. ... prototypes (added by the 1989 ANSI C standard) ... I think some features of C99 were a step too far and its wide-spread ... language more complex, and the line has to be drawn somewhere. ...
    (comp.lang.c)
  • Re: Why not add namespace feature into standard C?
    ... I've heard many people complain of the lacking of namespace in C. ... prototypes (added by the 1989 ANSI C standard) ... -- We in X3J11 knew that we had to add argument declarations to C, ... I think some features of C99 were a step too far and its wide-spread ...
    (comp.lang.c)