Why not add namespace feature into standard C?

[Richard Bos]

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.

Not realistically, you can't. Linkers _already_ handle names differently
on different platforms. It's so bad that the only thing the Standard
requires of them is that they shall be able to represent a limited size
external identifier; it makes no claim whatsoever about _how_ they do
so, let alone that they shall behave similarly to others.
It is entirely possible that there is a linker (though I don't know of
any) which doesn't support the _ symbol, and therefore needs _that_
mangled. It's equally possible that existing different compilers that
work with this linker do the mangling differently. How could a Standard
which mandates __c0xnamespace_<BINHEX> possibly be usefully implemented
using such linkers?

Richard

 

[P.J. Plauger]

You couldn't find a weaker reason?
.....

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

It does not predate C++'s natural behavior. If you're going to do this
obviously you want a template,
.....

Good deflection.
.....

Its a placebo for *real* compilers.
.....

The emphasis is on "unqualified".
.....

It's clear you have an answer for everything. Too bad you don't
supply them in a forum where you could make a difference. It's
*so* much easier to criticize what adults have done than to be
a participating adult yourself. You -- or anyone else -- have
every right to say "I don't like that feature" or "I wish they
had done something different" but not "I have all the correct
answers and you guys got it wrong". You haven't earned the right
to make such statements, IMO. (Well, you have the right to make
them -- this is an open forum -- you just don't command much
respect from some of us when you make them.)

Oh don't leave me in suspense ...

I didn't. See earlier postings in this thread.

.....

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

You're indulging in hyperbole, and misrepresenting what I said.
Namespaces aren't useless, but they are way less useful than
many proponents think. Macros blow a giant hole in the namespace
hierarchy, for one thing. Then you have the "using" problem --
either you require all names be unqualified or you come up with
sensible rules for omitting qualifiers. If you choose the former
path, you're no better off than using prefixed names (which
incur much scorn, however pragmatically useful they might be).
If you choose the latter, then you have a host of decisions to
make. And you'd better not just copy the C++ rules, because
they make namespaces even less useful than they might be. And
I speak from 13 years experience living with them.

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?

We did, among other people. And they haven't all balked.
Various vendors have added various features of C99. What
hasn't happened is a sufficient groundswell of user demand
to encourage most compiler vendors to aim for 100 per cent
conformance. Partly that's due to the success of C90 as a
"wallpaper" language -- it's everywhere and doesn't need
much more for its ubiquitous support role. Partly that's
due to the *dominance* of certain classes of compiler
vendors first in the Numerical C Extensions Group, then
in the revision that led to C99. But in the end, it's
because the committee failed to get adequate feedback from
a broad enough base of the C community. They simply put in
too many gimicks each of interest to too small a constituency.

So yes, the committee *does* need you, and other people with
strong opinions, to offer guidance. And maybe a little hsrd
work in the bargain. Uncompromising insistence doesn't cut
it, nor does Monday morning quarterbacking, however. That's
not the stuff of consensus.

Why don't you set criteria other than "widely requested" for
extensions to the language?

Who said that's the only criterion we used? It's just one
I cited a couple of times to counter your dismissiveness.

Why don't you take a look at what is
happening with other languages?

Who says we didn't? Read the minutes and papers of WG14. They're
available online.

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

Luckily, *you* bear no responsibility here.

(with some spot exceptions like stdint.h, va_copy(), more
precise FP functionality),

Ah! So there *were* a few things done right.

so results like the C99 fiasco are the
result.

There are so many obvious avenues that need to be addressed:
..... [long wish list elided]

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.

You have such a clear vision. It would be entertaining for you to
come to a C (or C++, or any other standards) meeting and share that
vision. I've watched dozens of people do that over the past quarter
century. The good ones survive the reasoned critiques of all those
other smart people in the room with equally clear visions, and stay
to help make some small difference. The really good ones even let
themselves get educated about other ways of looking at things.
Most leave after one meeting and never come back.

This doesn't seem to have stopped Bjarne Stroustrup.

No comment.

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

 

[Walter Bright]

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?

I suspect that much of the reason that more C++ features have not been moved
into C is because the people that wanted those features already simply moved
to C++ or D.

-Walter Bright
www.digitalmars.com C, C++, D programming language compilers

 

[Francis Glassborow]

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.

And C permits name mangling as well. The difference is that in C++
something such as name mangling is needed to deal with both overloaded
functions and scoped functions (even without namespaces, member
functions need support). The old Jensen & Partners TopSpeed C used some
form of simple name mangling to provide type-safe linkage.

What might be more interesting would be for C to provide modules with
explicitly exported names and pre-processor directives kept strictly
within the module.

 

[CBFalconer]

.... snip ...

What might be more interesting would be for C to provide modules
with explicitly exported names and pre-processor directives kept
strictly within the module.

But you have that now. If I write "#define foo bah" in file
foobar.c, that definition never escapes the foobar module. So I
suspect we are not talking about the same entities.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Richard Heathfield]

Walter Bright said:

I suspect that much of the reason that more C++ features have not been
moved into C is because the people that wanted those features already
simply moved to C++ or D.

Walter makes a very important point.

As dmr famously said when rejecting feature requests for C: "If you want
PL/1, you know where to find it." (No, I can't remember where I read that,
so I can't back up this claim. Sorry.)

For PL/1, read <foo>.

Clueful people who choose C over C++, whether it be in general or for
specific tasks, do so in the full knowledge that by so doing they are
effectively choosing /not/ to have access to specific features of C++. In
some cases, the very absence of these features from C is the reason for
that choice.

 

[David R Tribble]

What might be more interesting would be for C to provide modules with
explicitly exported names and pre-processor directives kept strictly
within the module.

By "module", I assume you mean "included header file". But then using
any macro defined within such a scope requires some kind of macro
naming to differentiate between the different places it could be
#defined.

Hence my preprocessor namespace suggestion, which allows preprocessor
macros to be defined within a given namespace (or "module"). Any use
of such a macro requires either an explicit namespace prefix or a #use
directive to "import" that pp-namespace.

#namespace Math // begin pp-namespace
#define PI 3.14159265358979323846264338
#namespace // end pp-namespace

double pi2()
{
return Math:I * 2.0; // explicit pp-prefix
}

#use Math // import pp-namespace

double pi3()
{
return PI * 3.0; // implied Math:: prefix
}

I would also suggest that the pp-namespace 'STDC' be reserved for
standard macros. It might also be useful that a '#use STDC' is
implied at the beginning of every source file.

-drt

 

[Al Balmer]

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

Ye gads - you mean it's going to get even worse?

 

[websnarf]

Not realistically, you can't. Linkers _already_ handle names differently
on different platforms. It's so bad that the only thing the Standard
requires of them is that they shall be able to represent a limited size
external identifier; it makes no claim whatsoever about _how_ they do
so, let alone that they shall behave similarly to others.
It is entirely possible that there is a linker (though I don't know of
any) which doesn't support the _ symbol, and therefore needs _that_
mangled. It's equally possible that existing different compilers that
work with this linker do the mangling differently. How could a Standard
which mandates __c0xnamespace_<BINHEX> possibly be usefully implemented
using such linkers?

I'm not proposing anything about what has to go into the linker. The
mapping that I am talking about would happen in the "C space" first.
The point being that C today already allows for the definition of
symbols like __c0xnamespace_this_3avariable_3ahere, except that you are
supposed to avoid them because it starts with an _, and it might be too
long (nevertheless pretty much all real C compilers can accept that
symbol verbatim today). Its actual representation in the linker is
clearly going to be platform specific no matter what, and isn't
actually part of any standard AFAIK; what we know is that existing C
compilers today can deterministically map from their internal C-syntax
symbols to the linker.

 

[WaterWalk]

thx

 

[WaterWalk]

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.

What if to make the grammars of conditional compilation and "common
macro definition" a little different? In my opinion, condition
compilation can't reside in any namespace other than the global
namespace. But the "common" macro definition such as the function-like
macro can be put to a namespace.

Maybe (e-mail address removed)'s suggestion makes some sense? I'm not sure...

 

[WaterWalk]

(e-mail address removed)'s suggestion is in a later post:
http://groups.google.com/group/comp...ot+add+namespace&rnum=1&#doc_a9b320cfd2838905

or his new post in comp.std.c
http://groups.google.com/group/comp.std.c/browse_frm/thread/93a1fa0afc39578e

 

[P.J. Plauger]

What if to make the grammars of conditional compilation and "common
macro definition" a little different? In my opinion, condition
compilation can't reside in any namespace other than the global
namespace. But the "common" macro definition such as the function-like
macro can be put to a namespace.

Maybe (e-mail address removed)'s suggestion makes some sense? I'm not sure...

Fine, go work out the details and write up a proposal. But I promise
you that I won't personally look at it unless it's accompanied by
several pages of use cases, with actual coding examples to show how
they're addressed. And I'd still feel queasy until I saw a trial
implementation that proves there are no surprises.

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