Re: Why not add namespace feature into standard C?

[da...@tribble.com]

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

[Francis Glassborow]

In article <1139270704....@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

[CBFalconer]

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

[David R Tribble]

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