Why not add namespace feature into standard C?

toolmas...@163.com 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.
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
--
Nick Keighley

Nick Keighley wrote:

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.

"Nick Keighley" <ni******************@hotmail.com> writes:

toolmas...@163.com 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.
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.

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

to********@163.com 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.
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.

--
Ian Collins.

Ian Collins <ia******@hotmail.com> writes:

to********@163.com 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.
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.

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Nick Keighley" <ni******************@hotmail.com> writes:

toolmas...@163.com 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.
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.

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.

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.

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

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

Ian Collins <ia******@hotmail.com> writes:

to********@163.com 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.
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.

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

Keith Thompson wrote:

Ian Collins <ia******@hotmail.com> writes:

to********@163.com 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.
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.

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.

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

to********@163.com 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, 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.

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

websn...@gmail.com wrote:

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; \
}

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

"P.J. Plauger" <pj*@dinkumware.com> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

[...]

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.

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

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.

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

<we******@gmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

to********@163.com 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.
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++.

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.

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

Keith Thompson wrote:

"P.J. Plauger" <pj*@dinkumware.com> writes:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org... [...]

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.

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

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.

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?
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

In article <11*********************@g47g2000cwa.googlegroups. com>,
to********@163.com 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.
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.

On 6 Feb 2006 09:37:18 -0800, in comp.lang.c , we******@gmail.com
wrote:

to********@163.com 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

(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
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

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

websnar wrote:

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

P.J. Plauger wrote: And some subtle semantic implications that have yet to be worked out
completely in C++.

toolmaster wrote:

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.

websnar wrote:

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.

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

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?

P.J. Plauger wrote:

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.

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

"WaterWalk" <to********@163.com> writes:

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.
P.J. Plauger wrote:

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.

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

P.J. Plauger wrote:

<we******@gmail.com> wrote in message

to********@163.com 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/

we******@gmail.com wrote:

Keith Thompson wrote:

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.

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

<we******@gmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

P.J. Plauger wrote:

<we******@gmail.com> wrote in message

> to********@163.com 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?
.....

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

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

> the "inline" placebo (register anyone?),

Also widely requested, and more than a placebo.

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

> "restrict" keyword.

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

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

> 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 didn't. See earlier postings in this thread.
.....

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

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.

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

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.

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

No comment.

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

<to********@163.com> wrote in message
news:11*********************@g47g2000cwa.googlegro ups.com...

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

In article <11*********************@g14g2000cwa.googlegroups. com>,
da***@tribble.com writes

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.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

Francis Glassborow wrote:

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

Francis Glassborow wrote:

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::PI * 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

On 6 Feb 2006 22:01:58 -0800, we******@gmail.com wrote:

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

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

--
Al Balmer
Sun City, AZ

Richard Bos wrote:

we******@gmail.com wrote:

Keith Thompson wrote:

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.

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.

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

thx

P.J.Plauger wrote:

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.

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 d...@tribble.com's suggestion makes some sense? I'm not sure...

d...@tribble.com's suggestion is in a later post:
http://groups.google.com/group/comp....b320cfd2838905

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

"WaterWalk" <to********@163.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...

P.J.Plauger wrote:

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

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 d...@tribble.com'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