Why not add namespace feature into standard C?

[toolmaster]

Since many of the modern computer languages have built-in namespace
features, I can't understand why not add this feature into standard C.
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. Is it because
adding namespace will make C more complex or some other reasons?

 

[Nick Keighley]

Since many of the modern computer languages have built-in namespace
features, I can't understand why not add this feature into standard C.
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. Is it because
adding namespace will make C more complex or some other reasons?

If you didn't, it might be worth considering asking this question in
comp.c.std.
My (not particularly informed) opinion.follows.

1. anything from C++ I'd view... warily. C is not C++ nor should it be.
2. contrai-wise, namespaces don't seem to be particularly OO or
strongly
C++ like.
3. adding *anything* to the standard is going make C more complex
4. I think some features of C99 were a step too far and its wide-spread

non-adoption indicates other people think the same. (I liked bool
)


I'll be interested in other (better informed) opinions

 

[WaterWalk]

2. contrai-wise, namespaces don't seem to be particularly OO or
strongly
C++ like.

Yes, but I don't mean namespace should be an OO feature before it can
be added into C. I think C needs namespace because I think namespace
improves C code organization.

3. adding *anything* to the standard is going make C more complex

Yes. So the problem is whether it is worth adding. And I think it is.

4. I think some features of C99 were a step too far and its wide-spread

non-adoption indicates other people think the same. (I liked bool

Agree.

 

[Keith Thompson]

If you didn't, it might be worth considering asking this question in
comp.c.std.
My (not particularly informed) opinion.follows.

1. anything from C++ I'd view... warily. C is not C++ nor should it be.

If I recall correctly, prototypes (added by the 1989 ANSI C standard)
were inspired by C++.

2. contrai-wise, namespaces don't seem to be particularly OO or
strongly
C++ like.
3. adding *anything* to the standard is going make C more complex
4. I think some features of C99 were a step too far and its wide-spread
non-adoption indicates other people think the same. (I liked bool
)

In my opinion, C++-style namespaces could be added to C without too
much difficulty, and without drastically increasing the complexity of
the language. On the other hand, any additional feature will make the
language more complex, and the line has to be drawn somewhere.

And of course backward compatibility could also be an issue. If the
language were being designed from scratch today with namespaces,
either the standard library declarations could be in a single
namespace, or each header could define its own namespace -- but if
namespaces were added today, existing code that refers directly to
declarations from the standard headers would still have to work.

 

[Ian Collins]

Since many of the modern computer languages have built-in namespace
features, I can't understand why not add this feature into standard C.
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. Is it because
adding namespace will make C more complex or some other reasons?

While a very handy feature of C++, I don't think they would fit well in
C. The biggest practical problem I can see is that C with namespaces
would require (like C++) some form of name mangling to provide unique
symbol names for the linker. While these could be standardised (unlike
C++) there would be backwards compatibility issues with operating
environments built with current compilers.

One good feature of C99 is backwards compatibility of binaries.

 

[Keith Thompson]

While a very handy feature of C++, I don't think they would fit well
in C. The biggest practical problem I can see is that C with
namespaces would require (like C++) some form of name mangling to
provide unique symbol names for the linker. While these could be
standardised (unlike C++) there would be backwards compatibility
issues with operating environments built with current compilers.

One good feature of C99 is backwards compatibility of binaries.

I'm not sure name mangling would be required. With namespaces, a name
like foo::bar::x would be unique. If the linker doesn't like ':'
characters in symbols, each "::" could be translated to some character
that can't appear in a C identifier, perhaps yielding something like
"foo$bar$x".

C++ uses name mangling to deal with overloaded functions, which C
(even a hypothetical C with namespaces) doesn't support.

 

[P.J. Plauger]

If I recall correctly, prototypes (added by the 1989 ANSI C standard)
were inspired by C++.

Not exactly:

-- We in X3J11 knew that we had to add argument declarations to C,
even before we knew anything about C++.

-- I had written a commercial C compiler in the mid 1970s that
had argument declarations as part of function declarations, so
we had prior art that we knew worked.

-- We saw no good reason to deviate in major ways from the C++
form, once we knew about it. But we still added ..., for varying
length argument lists, and the Miranda rule (suggested by Sam
Harbison) for reconciling the old declarations with the new.

All in all, the borrowing from C++ was incidental. In a similar
way, we knew we needed to add constant declarations. There was
no perceived reason not to use the keyword const, though we
changed its semantics in subtle ways.

In my opinion, C++-style namespaces could be added to C without too
much difficulty, and without drastically increasing the complexity of
the language.

Yes and no. First of all, namespaces are poorly designed in C++ --
they fail to solve most of the problems advanced as justification
for adding namespaces to C++. Second, and IMO more important, they
do nothing to solve the much larger problem in C (and C++) of
controlling the scope of macro definitions. Since C does not have
user-defined overloading of operators or functions, we would at
least avoid the worst problems of namespaces in C++, which are
only partially mitigated by argument-dependent lookup.

On the other hand, any additional feature will make the
language more complex, and the line has to be drawn somewhere.

Indeed. For a time in the early 1990s, I proposed picking up a number
of the "simpler" C++ additions. In the end, the C committee roundly
defeated all such proposals (other than // comments). In hindsight,
I think the committee was absolutely right.

And of course backward compatibility could also be an issue. If the
language were being designed from scratch today with namespaces,
either the standard library declarations could be in a single
namespace, or each header could define its own namespace -- but if
namespaces were added today, existing code that refers directly to
declarations from the standard headers would still have to work.

We certainly wouldn't want to imitate the disastrous decision in
C++ of putting all existing headers in namespace std.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[P.J. Plauger]

I'm not sure name mangling would be required. With namespaces, a name
like foo::bar::x would be unique. If the linker doesn't like ':'
characters in symbols, each "::" could be translated to some character
that can't appear in a C identifier, perhaps yielding something like
"foo$bar$x".

And this differs from name mangling in what important respect?
If the C Standard doesn't dictate the mapping, it presents
exactly the same problems.

C++ uses name mangling to deal with overloaded functions, which C
(even a hypothetical C with namespaces) doesn't support.

You gotta watch what your hypothetical C does, once you start tinkering
with it.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[websnarf]

I'm not sure name mangling would be required. With namespaces, a name
like foo::bar::x would be unique. If the linker doesn't like ':'
characters in symbols, each "::" could be translated to some character
that can't appear in a C identifier, perhaps yielding something like
"foo$bar$x".

But you want to remain backwards compatible with whatever the linker
standard is for the platform you were on. I.e., its possible that an
older linker supports *NO* extended characters (it might actually
validate the symbols by enforcing this or something), in which case you
cannot link together old and new objects. Remember that linkers
typically have a much longer lived and older legacy support than
compilers -- its also possible that two different linkers are
compatible only under the assumption of non-use of extended characters.

The right way to do this is to leverage the "compiler reserved
namespace", naming stuff that starts with "_". So something like
foo::bar::x would be encoded as:

__c0xnamspace_<BINHEX("foo::bar::x")>

And in fact you could mandate this exact name mapping into the
standard. So collisions can only happen if someone is deliberately
constructing a symbol with a leading "_" which is already considered
undefined by the standard. This also requires that a new standard
would have to drastically increase the acceptable symbol size, which of
course it should have done in the C99 standard (why is *ANY* symbol
size limit less than 2.147 billion characters?).

But perhaps BINHEX is not human readable. So you can instead use an
escape mode grammar. Sticking with the same prefix, you would pick _
as your escape character *after* the prefix. So __ (two underscores in
a row) gets translated to a single _, otherwise _<HEXCHAR,HEXCHAR>
would translate to a char or ASCII character. So foo::bar::x would be
__c0xnamspace_foo_3A_3Abar_3A_3Ax which you could still sort of read as
foo::bar::x.

If you want to keep the symbol size down to a smaller fixed length
(which your linker again might enforce) then do:
BINHEX(SHA256("foo::bar::x")) which will keep it fixed length (but I
think its more than 31 characters) regardless of how long the string
is.

So this is better than name mangling in the sense that it asserts a
very specific name mangling algorithm so that the standardization and
backward compatibility modes still make sense.

 

[websnarf]

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, the // comments, complex numbers that are
incompatible with C++, variable length arrays which are incompatible
with gcc, the "inline" placebo (register anyone?), and an unqualified
"restrict" keyword. In short, I don't understand either.

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.)

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.

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. Remember that most C compiler
vendors today are also C++ vendors. So the compiler people already
know how to add namespaces into their compilers.

 

[websnarf]

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

Ok, lets try this:

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

 

[Keith Thompson]

And this differs from name mangling in what important respect?
If the C Standard doesn't dictate the mapping, it presents
exactly the same problems.

If the linker supports ':' characters in symbol names, names wouldn't
have to be mangled at all. If it doesn't, all that's required is a
minor workaround. Some C implementations do a similar kind of
translation already, prepending '_' to external symbols; the language
already doesn't define the relationship between declared names and
linker symbols.

If some linkers need to map "::" to, say, "___", it might become
necessary to ban identifers containing "___" (I think C++ has some
restrictions on identifiers relative to C).

You gotta watch what your hypothetical C does, once you start tinkering
with it.

Right, you can't change just one thing. I *suspect* that some form of
namespaces could be added to C without breaking anything, but since I
haven't looked into it my suspicion is largely baseless.

 

[P.J. Plauger]

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

Widely requested.

the // comments,

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

complex numbers that are
incompatible with C++,

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

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.

the "inline" placebo (register anyone?),

Also widely requested, and more than a placebo.

and an unqualified
"restrict" keyword.

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

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++.

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.

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...

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.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Flash Gordon]

If the linker supports ':' characters in symbol names, names wouldn't
have to be mangled at all. If it doesn't, all that's required is a
minor workaround. Some C implementations do a similar kind of
translation already, prepending '_' to external symbols; the language
already doesn't define the relationship between declared names and
linker symbols.
Agreed.

If some linkers need to map "::" to, say, "___", it might become
necessary to ban identifers containing "___" (I think C++ has some
restrictions on identifiers relative to C).

Actually, the author(s) of the implementation know the maximum number of
underscores they have at the start of any symbols they currently
declare, so all they have to do is say that names beginning with one
more underscore than that (say three underscores) have been mangled in
some way they decide on to specify the namespace. For example, if the
most they have is three inderscores at the start of any implementation
defined symbol, they could use:
____namespace_symbol
No user identifier is allowed to have a name starting with three
underscores, so safe from clashes there, and no system identifier does
because that is known by the system. You can be certain that there is
*always* a number of underscores that is sufficient to meet these
requirements, because no real system has infinite symbol length.

That just leave the possibility of symbols becoming too long for the
compiler.

BTW, this can also work for nested namespaces, e.g.
___namespace1___namespace2_symbol
for namespace1::namespace2::symbol

Right, you can't change just one thing. I *suspect* that some form of
namespaces could be added to C without breaking anything, but since I
haven't looked into it my suspicion is largely baseless.

Define that all current standard defined symbols stay in the global
namespace, namespaces starting with an underscore are reserved and leave
all other name spaces free for the users and third party library writers
to use. With my suggested implementation above, as far as I can see this
gives you full binary compatibility with code pre-dating the namespace
implementation, including compatibility with a library that pre-dates
the implementation. It also allows newer versions of the C library to
still be binary compatible with code that was built prior to namespaces
being added to the implementation.

There is still a problem in terms of macros, but could you not have the
namespaces apply to macros as well? Or say that namespace::symbol is a
single token in the preprocessor phase?

 

[Christian Bau]

Since many of the modern computer languages have built-in namespace
features, I can't understand why not add this feature into standard C.
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. Is it because
adding namespace will make C more complex or some other reasons?

Probably yes.

 

[Mark McIntyre]

Because the standards people were more concerned with

(snip weird diatribe)

I was going to respond to this, but PJ Plauger did a most excellent
job. I'm generally baffled as to why Paul wastes his energy with such
bizarre tirades.
Mark McIntyre

 

[david]

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

Probably the simplest reason that C does not (and probably will not, at
least for the forseeable future) support namespaces is because it
complicates the linker model required for C compilers. C++ allows
compilers to do name mangling, which many ISO C committee members
consider a rather unclean solution.

I started writing a proposal long ago for adding namespaces to the
C preprocessor. Something along the lines of:

#namespace MyLib // Begin namespace 'MyLib'
#define swap(a,b,t) (t = (a), (a) = (b), (b) = t)
#namespace // End namespace

#use MyLib // Enable 'MyLib:xxx' macros

void func(float a, float b)
{
float t;

MyLib::swap(a, b, t);
...
}

The advantages of doing namespaces in the preprocessor instead
of in the linker are:
a) there is zero impact on the C linker model,
b) it could be made to work with C++.

-drt

 

[WaterWalk]

Well, It seems that a certain namespace mechamism does need to be add
into C. The problem is how to add it elegantly. Am I right here?

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

What does this mean? I'm confused here because my English is a little
weak...

 

[Keith Thompson]

Well, It seems that a certain namespace mechamism does need to be add
into C. The problem is how to add it elegantly. Am I right here?

It's not *necessary* to add a namespace mechanism to C at all. The
language has survived without them for many years.

What does this mean? I'm confused here because my English is a little
weak...

He's saying that the maintainers of gcc haven't done much to add C99
features to their compiler, even those features that don't conflict
with existing gcc features. (I'm not saying I agree or disagree, just
interpreting what he said.)

gcc's C99 status is summarized at <http://gcc.gnu.org/c99status.html>.

 

[websnarf]

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.

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

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

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.

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.

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.

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.

No, I wouldn't expect you to.


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

Oh don't leave me in suspense ...

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.

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.

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++.