Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #19265 > unrolled thread

What about namespaces ?

Back to article view | Back to comp.lang.c

Contents

  What about namespaces ? Rui Maciel <rui.maciel@gmail.com> - 2012-04-03 10:25 +0100
    Re: What about namespaces ? "BartC" <bc@freeuk.com> - 2012-04-03 11:20 +0100
      Re: What about namespaces ? Ian Collins <ian-news@hotmail.com> - 2012-04-03 22:29 +1200
        Re: What about namespaces ? "BartC" <bc@freeuk.com> - 2012-04-03 12:38 +0100
      Re: What about namespaces ? Keith Thompson <kst-u@mib.org> - 2012-04-03 12:19 -0700
        Re: What about namespaces ? "BartC" <bc@freeuk.com> - 2012-04-03 20:57 +0100
    Re: What about namespaces ? gordonb.9sh3w@burditt.org (Gordon Burditt) - 2012-04-03 06:23 -0500
      Re: What about namespaces ? Rui Maciel <rui.maciel@gmail.com> - 2012-04-03 19:54 +0100
        Re: What about namespaces ? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-04-03 12:18 -0700
          Re: What about namespaces ? jgharston <jgh@arcade.demon.co.uk> - 2012-04-03 13:09 -0700
      Re: What about namespaces ? Rui Maciel <rui.maciel@gmail.com> - 2012-04-03 19:54 +0100
      Re: What about namespaces ? Rui Maciel <rui.maciel@gmail.com> - 2012-04-03 19:54 +0100
    Re: What about namespaces ? 88888 Dihedral <dihedral88888@googlemail.com> - 2012-04-03 06:49 -0700
    Re: What about namespaces ? Robert Wessel <robertwessel2@yahoo.com> - 2012-04-03 11:10 -0500
      Re: What about namespaces ? Rui Maciel <rui.maciel@gmail.com> - 2012-04-03 20:12 +0100
      Re: What about namespaces ? Ian Collins <ian-news@hotmail.com> - 2012-04-04 07:20 +1200
    Re: What about namespaces ? Fritz Wuehler <fritz@spamexpire-201204.rodent.frell.theremailer.net> - 2012-04-03 20:58 +0200
      Re: What about namespaces ? Rui Maciel <rui.maciel@gmail.com> - 2012-04-03 21:05 +0100
        Re: What about namespaces ? "BartC" <bc@freeuk.com> - 2012-04-03 21:33 +0100
    Re: What about namespaces ? William Ahern <william@wilbur.25thandClement.com> - 2012-04-03 12:05 -0700
      Re: What about namespaces ? James Kuyper <jameskuyper@verizon.net> - 2012-04-03 15:50 -0400
      Re: What about namespaces ? Rui Maciel <rui.maciel@gmail.com> - 2012-04-03 21:27 +0100
        Re: What about namespaces ? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-04-03 14:40 -0700
      Re: What about namespaces ? jgk@panix.com (Joe keane) - 2012-04-11 20:56 +0000
        Re: What about namespaces ? Ben Pfaff <blp@cs.stanford.edu> - 2012-04-11 14:46 -0700
          Re: What about namespaces ? jgk@panix.com (Joe keane) - 2012-04-11 23:03 +0000
          Re: What about namespaces ? jgk@panix.com (Joe keane) - 2012-04-13 00:40 +0000
            Re: What about namespaces ? Keith Thompson <kst-u@mib.org> - 2012-04-12 18:56 -0700
              Re: What about namespaces ? "BartC" <bc@freeuk.com> - 2012-04-13 13:20 +0100
                Re: What about namespaces ? Keith Thompson <kst-u@mib.org> - 2012-04-13 13:43 -0700
              Re: What about namespaces ? jgk@panix.com (Joe keane) - 2012-04-15 16:46 +0000
                Re: What about namespaces ? Martin Ambuhl <mambuhl@earthlink.net> - 2012-04-21 04:38 -0400
                  Re: What about namespaces ? "BartC" <bc@freeuk.com> - 2012-04-21 16:44 +0100
        Re: What about namespaces ? "BartC" <bc@freeuk.com> - 2012-04-11 23:01 +0100
          Re: What about namespaces ? jgk@panix.com (Joe keane) - 2012-04-13 21:04 +0000
        Re: What about namespaces ? lawrence.jones@siemens.com - 2012-04-11 22:09 -0400
          Re: What about namespaces ? Nomen Nescio <nobody@dizum.com> - 2012-04-12 10:55 +0200
    Re: What about namespaces ? Rui Maciel <rui.maciel@gmail.com> - 2012-04-04 00:17 +0100
      Re: What about namespaces ? William Ahern <william@wilbur.25thandClement.com> - 2012-04-03 16:44 -0700
        Re: What about namespaces ? nick_keighley_nospam@hotmail.com - 2012-04-04 00:49 -0700
    Re: What about namespaces ? Ian Collins <ian-news@hotmail.com> - 2012-04-04 14:54 +1200
      Re: What about namespaces ? Ian Collins <ian-news@hotmail.com> - 2012-04-04 15:43 +1200
        Re: What about namespaces ? Ian Collins <ian-news@hotmail.com> - 2012-04-04 16:06 +1200
    Re: What about namespaces ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-04-04 04:37 +0100
      Re: What about namespaces ? Kaz Kylheku <kaz@kylheku.com> - 2012-04-04 18:43 +0000
        Re: What about namespaces ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-04-05 01:43 +0100
    Re: What about namespaces ? "io_x" <a@b.c.invalid> - 2012-04-04 09:32 +0200
    Re: What about namespaces ? Tim Rentsch <txr@alumni.caltech.edu> - 2012-04-05 11:22 -0700
      Re: What about namespaces ? Rui Maciel <rui.maciel@gmail.com> - 2012-04-05 21:04 +0100
      Re: What about namespaces ? Kaz Kylheku <kaz@kylheku.com> - 2012-04-06 01:10 +0000

Page 1 of 3  [1] 2 3  Next page →

#19265 — What about namespaces ?

When a C program grows, the odds that two identifier names will clash will 
increase.  So, unless the programmer has in place an effective policy to 
name every identifier that is able to avoid any naming clash, including 
thosed introduced by third-party code, the odds that this problem will 
manifest itself will also become greater.

This problem isn't particularly hard to avoid.  A simple policy based on 
adding a descriptive prefix to the identifier name tends to be enough for 
most cases.  Even in corner cases, such as possible name clashes between 
incompatible versions of the same library, it is possible to sidestep this 
by adding a reference to the library version to the prefix being used.

Nonetheless, by relying on this method, identifier names tend to become a 
bit verbose.  This, in itself, isn't a major problem, but it isn't very 
helpful either.  After all, it tends to be preferable if it's possible to 
call a function named do_stuff() instead of being forced to call another one 
named package_name_version_library_task_do_stuff(), and long identifier 
names tend to make some code constructs a bit hard to read.

A possible way to cut on verbose identifier names would be to implement a 
system where these prefixes could be left implied by the programmer in such 
a way that, in a given context, a call to do_stuff() could unambiguously be 
interpreted as a call to package_name_version_library_task_do_stuff().  This 
could, hypothetically, be accomplished by letting programmers specify 
exactly, both in declarations and definitions, which group of identifiers 
would share a specific naming prefix, and then also specify in which block 
these naming prefixes could be left implied. 

What I've described is, in essence, the concept of namespaces, which has 
been a part of other programming languages, such as C++, for a long time 
now.

So, with this in mind, what are your thoughts on the idea of introducing 
namespaces to the C programming language?  Would it be a bad idea? 


Rui Maciel

[toc] | [next] | [standalone]

#19266

"Rui Maciel" <rui.maciel@gmail.com> wrote in message 
news:jleflk$kv0$1@speranza.aioe.org...

> This problem isn't particularly hard to avoid.  A simple policy based on
> adding a descriptive prefix to the identifier name tends to be enough for
> most cases.
...
> So, with this in mind, what are your thoughts on the idea of introducing
> namespaces to the C programming language?  Would it be a bad idea?

Does it really need anything more than allowing "##" (or equivalent) to be 
used outside of macros? Then it is possible to replace a long prefix with a 
short one. It will do roughly the same job as "::" or ".".

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#19267

On 04/ 3/12 10:20 PM, BartC wrote:
> "Rui Maciel"<rui.maciel@gmail.com>  wrote in message
> news:jleflk$kv0$1@speranza.aioe.org...
>
>> This problem isn't particularly hard to avoid.  A simple policy based on
>> adding a descriptive prefix to the identifier name tends to be enough for
>> most cases.
> ....
>> So, with this in mind, what are your thoughts on the idea of introducing
>> namespaces to the C programming language?  Would it be a bad idea?
>
> Does it really need anything more than allowing "##" (or equivalent) to be
> used outside of macros? Then it is possible to replace a long prefix with a
> short one. It will do roughly the same job as "::" or ".".

Namespaces (in the C++ sense) need a lot more.  A C++ namespace is a 
scope, not just a text prefix.  So adding them to C would require at 
lest one (and probably two with "using") new keywords, basic name 
mangling and significant parser changes.  All most unlikely.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#19270

"Ian Collins" <ian-news@hotmail.com> wrote in message 
news:9u01ojF77mU2@mid.individual.net...
> On 04/ 3/12 10:20 PM, BartC wrote:
>> "Rui Maciel"<rui.maciel@gmail.com>  wrote in message
>> news:jleflk$kv0$1@speranza.aioe.org...
>>
>>> This problem isn't particularly hard to avoid.  A simple policy based on
>>> adding a descriptive prefix to the identifier name tends to be enough 
>>> for
>>> most cases.
>> ....
>>> So, with this in mind, what are your thoughts on the idea of introducing
>>> namespaces to the C programming language?  Would it be a bad idea?
>>
>> Does it really need anything more than allowing "##" (or equivalent) to 
>> be
>> used outside of macros? Then it is possible to replace a long prefix with 
>> a
>> short one. It will do roughly the same job as "::" or ".".
>
> Namespaces (in the C++ sense) need a lot more.  A C++ namespace is a 
> scope, not just a text prefix.  So adding them to C would require at lest 
> one (and probably two with "using") new keywords, basic name mangling and 
> significant parser changes.  All most unlikely.

That's why a simple solution, to shorten the otherwise unwieldy names that 
can result from not having namespaces, might be more useful than doing 
nothing.

-- 
Bartc

 

[toc] | [prev] | [next] | [standalone]

#19293

"BartC" <bc@freeuk.com> writes:
> "Rui Maciel" <rui.maciel@gmail.com> wrote in message 
> news:jleflk$kv0$1@speranza.aioe.org...
>
>> This problem isn't particularly hard to avoid.  A simple policy based on
>> adding a descriptive prefix to the identifier name tends to be enough for
>> most cases.
> ...
>> So, with this in mind, what are your thoughts on the idea of introducing
>> namespaces to the C programming language?  Would it be a bad idea?
>
> Does it really need anything more than allowing "##" (or equivalent) to be 
> used outside of macros? Then it is possible to replace a long prefix with a 
> short one. It will do roughly the same job as "::" or ".".

Are you suggesting that one could declare something as

    foo##bar

and then refer to it either as "foo##bar" or just as "bar"?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#19299

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnsjgk39np.fsf@nuthaus.mib.org...
> "BartC" <bc@freeuk.com> writes:
>> "Rui Maciel" <rui.maciel@gmail.com> wrote in message
>> news:jleflk$kv0$1@speranza.aioe.org...
>>
>>> This problem isn't particularly hard to avoid.  A simple policy based on
>>> adding a descriptive prefix to the identifier name tends to be enough 
>>> for
>>> most cases.
>> ...
>>> So, with this in mind, what are your thoughts on the idea of introducing
>>> namespaces to the C programming language?  Would it be a bad idea?
>>
>> Does it really need anything more than allowing "##" (or equivalent) to 
>> be
>> used outside of macros? Then it is possible to replace a long prefix with 
>> a
>> short one. It will do roughly the same job as "::" or ".".
>
> Are you suggesting that one could declare something as
>
>    foo##bar
>
> and then refer to it either as "foo##bar" or just as "bar"?

No:

void long_function_prefix_fna(int,int);
void long_function_prefix_fnb(int);
...

define lfp long_function_prefix_

long_function_prefix_fna(10,20);    /* long-winded call */
lfp##fna(10,21);                    /* short call */
lfp::fna(10,22);                    /* (looks better like this) */

But you can't, in general, just use:

fna(10,23);

Not without defining a macro for each function:

#define fna long_function_prefix_fna

While this is a possibility, and can be done now, it's not as easy
as defining a macro for each library.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#19269

> So, with this in mind, what are your thoughts on the idea of introducing 
> namespaces to the C programming language?  Would it be a bad idea? 

In what way would that be an improvement over "Use C++"?

I see little point in gradually adding features to C to 
try to turn it into C++, or a poor version of it.

[toc] | [prev] | [next] | [standalone]

#19285

Gordon Burditt wrote:

> In what way would that be an improvement over "Use C++"?
> 
> I see little point in gradually adding features to C to
> try to turn it into C++, or a poor version of it.

Just because C++ has namespaces it doesn't mean that this is an attempt to 
turn C into C++, or into any other language for that matter.  If that was 
the case, the addition of range-based for loops to the C++ programming 
language would also imply that the C++ people were trying to turn C++ into 
Java.

Namespaces can correspond to nothing more than syntactic sugar which happens 
to be considerably useful.  It doesn't make sense to snub any feature, no 
matter how useful it might be, just because some other language already has 
it.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#19292

בתאריך יום שלישי, 3 באפריל 2012 19:54:21 UTC+1, מאת Rui Maciel:
> 
> Namespaces can correspond to nothing more than syntactic sugar which happens 
> to be considerably useful.  It doesn't make sense to snub any feature, no 
> matter how useful it might be, just because some other language already has 
> it.
> 
>
You need short identifiers, mu = mean(x, N), not myobject::mean_salary = std::Math.mean(myobject::employees.salary, std::length(myobject::employees));

In a snippet, the long version looks a bit better, since it tells you something. But in real code, if every line is like that, it rapidly becomes unreadable.

I believe in the rule of two. (See my website). Humans like binomial names. That's true in biology, it's true for people's names, it's true for computing as well. So if you call your variable mean-salary, ypu've used up your two names. You can't call it mylib_mean_salary, without violating the rule of two and making people unwilling to use your system.

What we need is a hierarchy. Say you're writing an image library. The user simply wants to call loadimage() and saveimage(). These will intelligently detect the various formats used. However you yourself won't want your jpeg saver in the same file as the gif saver. Lower-lvel functions like savejpeg(), savegif() and the like will exist in separate source files. These symbols shouldn't be visible to anyone who includes  "imagelibrary.h".

-- 
MiniBasic - now on offer for a few days only
http://www.malcolmmclean.site11.com/www

[toc] | [prev] | [next] | [standalone]

#19303

Malcolm McLean wrote:
> What we need is a hierarchy. Say you're writing an image library.
> The user simply wants to call loadimage() and saveimage().

The beat them around the head until they want to call image_load()
and image_save() and understand the concept of "hiererchy".

loadimage() is one of a set of load* calls. Things that are to
do with images should be called image*.

Programmer discipline. Naming should be global_local_specific.
acia_int(), acia_test(), acia_send(), acia_read()
image_load(), image_save(), image_jpegtogif(), image_flatten()
skt_open(), skt_close(), skt_send(), skt_read()

See http://www.ganssle.com/articles/namingconventions.htm

Underline namespace is my prefered method, as it clearly identifies
the module and the subfunction (eg net_fsop() vs netfs_op()), but
if you prefer sktopen(), sktclose(), ImageLoad(), ImageSave() they
work as long as you use big-middle-small.

JGH

[toc] | [prev] | [next] | [standalone]

#19286

Gordon Burditt wrote:

> In what way would that be an improvement over "Use C++"?
> 
> I see little point in gradually adding features to C to
> try to turn it into C++, or a poor version of it.

Just because C++ has namespaces it doesn't mean that this is an attempt to 
turn C into C++, or into any other language for that matter.  If that was 
the case, the addition of range-based for loops to the C++ programming 
language would also imply that the C++ people were trying to turn C++ into 
Java.

Namespaces can correspond to nothing more than syntactic sugar which happens 
to be considerably useful.  It doesn't make sense to snub any feature, no 
matter how useful it might be, just because some other language already has 
it.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#19289

Gordon Burditt wrote:

> In what way would that be an improvement over "Use C++"?
> 
> I see little point in gradually adding features to C to
> try to turn it into C++, or a poor version of it.

Just because C++ has namespaces it doesn't mean that this is an attempt to 
turn C into C++, or into any other language for that matter.  If that was 
the case, the addition of range-based for loops to the C++ programming 
language would also imply that the C++ people were trying to turn C++ into 
Java.

Namespaces can correspond to nothing more than syntactic sugar which happens 
to be considerably useful.  It doesn't make sense to snub any feature, no 
matter how useful it might be, just because some other language already has 
it.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#19272

Rui Maciel於 2012年4月3日星期二UTC+8下午5時25分10秒寫道：
> When a C program grows, the odds that two identifier names will clash will 
> increase.  So, unless the programmer has in place an effective policy to 
> name every identifier that is able to avoid any naming clash, including 
> thosed introduced by third-party code, the odds that this problem will 
> manifest itself will also become greater.
> 
> This problem isn't particularly hard to avoid.  A simple policy based on 
> adding a descriptive prefix to the identifier name tends to be enough for 
> most cases.  Even in corner cases, such as possible name clashes between 
> incompatible versions of the same library, it is possible to sidestep this 
> by adding a reference to the library version to the prefix being used.
> 
> Nonetheless, by relying on this method, identifier names tend to become a 
> bit verbose.  This, in itself, isn't a major problem, but it isn't very 
> helpful either.  After all, it tends to be preferable if it's possible to 
> call a function named do_stuff() instead of being forced to call another one 
> named package_name_version_library_task_do_stuff(), and long identifier 
> names tend to make some code constructs a bit hard to read.
> 
> A possible way to cut on verbose identifier names would be to implement a 
> system where these prefixes could be left implied by the programmer in such 
> a way that, in a given context, a call to do_stuff() could unambiguously be 
> interpreted as a call to package_name_version_library_task_do_stuff().  This 
> could, hypothetically, be accomplished by letting programmers specify 
> exactly, both in declarations and definitions, which group of identifiers 
> would share a specific naming prefix, and then also specify in which block 
> these naming prefixes could be left implied. 
> 
> What I've described is, in essence, the concept of namespaces, which has 
> been a part of other programming languages, such as C++, for a long time 
> now.
> 
> So, with this in mind, what are your thoughts on the idea of introducing 
> namespaces to the C programming language?  Would it be a bad idea? 
> 
> 
> Rui Maciel

I think one has to declare static variables in the file scope for those 
not to be exported and a package header for all extern variables in one's
organization of c files can remedy the problem. 

[toc] | [prev] | [next] | [standalone]

#19279

On Tue, 03 Apr 2012 10:25:10 +0100, Rui Maciel <rui.maciel@gmail.com>
wrote:

>When a C program grows, the odds that two identifier names will clash will 
>increase.  So, unless the programmer has in place an effective policy to 
>name every identifier that is able to avoid any naming clash, including 
>thosed introduced by third-party code, the odds that this problem will 
>manifest itself will also become greater.
>
>This problem isn't particularly hard to avoid.  A simple policy based on 
>adding a descriptive prefix to the identifier name tends to be enough for 
>most cases.  Even in corner cases, such as possible name clashes between 
>incompatible versions of the same library, it is possible to sidestep this 
>by adding a reference to the library version to the prefix being used.
>
>Nonetheless, by relying on this method, identifier names tend to become a 
>bit verbose.  This, in itself, isn't a major problem, but it isn't very 
>helpful either.  After all, it tends to be preferable if it's possible to 
>call a function named do_stuff() instead of being forced to call another one 
>named package_name_version_library_task_do_stuff(), and long identifier 
>names tend to make some code constructs a bit hard to read.
>
>A possible way to cut on verbose identifier names would be to implement a 
>system where these prefixes could be left implied by the programmer in such 
>a way that, in a given context, a call to do_stuff() could unambiguously be 
>interpreted as a call to package_name_version_library_task_do_stuff().  This 
>could, hypothetically, be accomplished by letting programmers specify 
>exactly, both in declarations and definitions, which group of identifiers 
>would share a specific naming prefix, and then also specify in which block 
>these naming prefixes could be left implied. 
>
>What I've described is, in essence, the concept of namespaces, which has 
>been a part of other programming languages, such as C++, for a long time 
>now.
>
>So, with this in mind, what are your thoughts on the idea of introducing 
>namespaces to the C programming language?  Would it be a bad idea? 



I don't think anyone really likes namespaces as done in C++ (or in
most other implementations).  It works, but...

C++-style classes are probably much more useful in that regard.  It
effectively does isolate all the class member names behind a prefix
(the class name), and often allows short (unprefixed) access to the
members.  In the real world, the number of name clashes per line of
C++ code is vastly lower than for C code.  Namespaces work best on top
of that.

As has been often said, everyone works in a different subset of C++,
so YMMV, but I'm far more interested in the encapsulation offered by
classes (which, as mentioned above, significantly helps name space
pollution), than say, inheritance or polymorphism.

[toc] | [prev] | [next] | [standalone]

#19290

Robert Wessel wrote:

> I don't think anyone really likes namespaces as done in C++ (or in
> most other implementations).  It works, but...

I don't remember ever seeing anyone complain about namespaces in C++, and a 
quick google on "C++ namespace criticism" comes up empty.  What criticism 
are you referring to?


> C++-style classes are probably much more useful in that regard.
<snip/>

There is already a C with classes.  In fact, there are two of them, or 3 if 
you count the D programming language.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#19294

On 04/ 4/12 04:10 AM, Robert Wessel wrote:
>>
>> So, with this in mind, what are your thoughts on the idea of introducing
>> namespaces to the C programming language?  Would it be a bad idea?
>
> I don't think anyone really likes namespaces as done in C++ (or in
> most other implementations).  It works, but...

Eh?

> C++-style classes are probably much more useful in that regard.  It
> effectively does isolate all the class member names behind a prefix
> (the class name), and often allows short (unprefixed) access to the
> members.  In the real world, the number of name clashes per line of
> C++ code is vastly lower than for C code.  Namespaces work best on top
> of that.

There's one big difference between a namespace and a struct/class in 
C++:  a namespace can be split between multiple files.  Otherwise we 
could just use a struct to emulate a namespace in C.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#19288

Rui Maciel <rui.maciel@gmail.com> wrote:

> When a C program grows, the odds that two identifier names will clash will 
> increase.  So, unless the programmer has in place an effective policy to 
> name every identifier that is able to avoid any naming clash, including 
> thosed introduced by third-party code, the odds that this problem will 
> manifest itself will also become greater.

There is probably no solution to this given the gigantic amount of C library
code that already exists and the unbelievable lack of discipline and "don't
tell me what to do" typical of C programmers as well as the huge number of C
programmers. The linker will probably also have to be changed to support the
weird names, but I am not sure.

> What I've described is, in essence, the concept of namespaces, which has 
> been a part of other programming languages, such as C++, for a long time 
> now.

Yeah

> So, with this in mind, what are your thoughts on the idea of introducing 
> namespaces to the C programming language?  Would it be a bad idea? 

Many older languages suffer from this problem and it would be nice to solve
it. I suppose some liberal use of the preprocessor could help here or maybe
writing some m4 scripts. I'm as interested as you to hear if anybody thinks
this will ever fly in the standards committee. Until then if you try rolling
your own you may win and have your idea implemented ;-)

[toc] | [prev] | [next] | [standalone]

#19301

Fritz Wuehler wrote:

> Rui Maciel <rui.maciel@gmail.com> wrote:
> 
>> When a C program grows, the odds that two identifier names will clash
>> will
>> increase.  So, unless the programmer has in place an effective policy to
>> name every identifier that is able to avoid any naming clash, including
>> thosed introduced by third-party code, the odds that this problem will
>> manifest itself will also become greater.
> 
> There is probably no solution to this given the gigantic amount of C
> library code that already exists and the unbelievable lack of discipline
> and "don't tell me what to do" typical of C programmers as well as the
> huge number of C programmers. The linker will probably also have to be
> changed to support the weird names, but I am not sure.

Basically, the only changes which would be required to implement this 
feature is how the front-end of a compiler handles identifiers.  Let's 
consider that all a namespace implementation would do is provide a 
programmer with a way to define regions of code where:
- a specific prefix was omitted from declarations and definitions
- prefixes could be left implied in identifiers

With this in mind, consider the following function definition:

<code>
int package_version_do_stuff()
{
    return 42;
}
</code>


The previous function definition could be considered equivalent to the 
following code:
<code>
namespace package
{
    namespace version
    {
        int do_stuff();
        {
            return 42;
        }
    }
}
</code>

Then, whenever any identifier was referenced, the compiler would only need 
to check the identifier list to search for any identifier which matched the 
identifier string, or any version which included a prefix which has been set 
with a "using namespace" directive.

The best part about this way of implementing namespaces in C is that it 
would open the door to polymorphism, similar to the one implemented through 
the _Generic() keyword in C11.  Consider the following example:

<code>
namespace foo
{
    namespace int_version
    {
        void do_stuff(int param)
        {
            puts("int parameter");
        }
    }

    namespace float_version
    {
        void do_stuff(float param)
        {
            puts("float parameter");
        }
    }
}


int main(void)
{
    using namespace foo::int_version, foo_float_version;

    do_stuff(1);   // this would call foo_int_version_do_stuff(1);
   
    do_stuff(1.0f);   // this would call foo_float_version_do_stuff(1);

    return 0;
}
</code>



Rui Maciel

[toc] | [prev] | [next] | [standalone]

#19305

"Rui Maciel" <rui.maciel@gmail.com> wrote in message
news:jlfl67$16g$1@speranza.aioe.org...

> The best part about this way of implementing namespaces in C is that it
> would open the door to polymorphism, similar to the one implemented
> through
> the _Generic() keyword in C11.  Consider the following example:

> namespace foo
>    namespace int_version
>        void do_stuff(int param)
>    namespace float_version
>        void do_stuff(float param)

>    using namespace foo::int_version, foo_float_version;

foo::float_version?

>    do_stuff(1);   // this would call foo_int_version_do_stuff(1);
>
>    do_stuff(1.0f);   // this would call foo_float_version_do_stuff(1);

Looks deceptively simple, but I think would very quickly become a nightmare
to implement, or understand. You're trying match a set of N parameter (and
return?) types, against a set of M identically-named functions. There might
be more than one match. Or there might be no perfect matches, while some can
match if you perform a cast on one or more arguments.

And then there is the search order to consider, even when parameter types
are not significant.

Also, don't you still have to duplicate essentially the same code in each 
function? Unless this covers template programming too..

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#19291

Rui Maciel <rui.maciel@gmail.com> wrote:
<snip>
> Nonetheless, by relying on this method, identifier names tend to become a
> bit verbose. This, in itself, isn't a major problem, but it isn't very
> helpful either. After all, it tends to be preferable if it's possible to
> call a function named do_stuff() instead of being forced to call another
> one named package_name_version_library_task_do_stuff(), and long
> identifier names tend to make some code constructs a bit hard to read.

I always thought the soluion to that was:

	pnvlt_do_stuff()

Also, package_name_version_library_task_do_stuff() is much longer than 31
characters. Which begs the question; is 31 characters really too
constraining, or just an annoyance when things break because we didn't put
any subsantial effort into the task at hand.

I've always considered C's lack of features a kind of "engineer forcing".
Similar to legislative forcing--a term used in American judicial and
political philosophy which implies that, e.g., a court's nullification of a
law is effectively submittal to the legislature to "do it right", as opposed
to a passive constitutional exercise.

In other words, environmental constraints (or stresses, so to speak) aren't
merely meaningless or abstract limits; but ways of saying that, if you work
hard enough to stay within certain bounds, you're more likely to get it
right than under an alternative system; and if we were to loosen such
limits, there would likely be unintended and detrimental consequences.

I'm not sure I want to live in a software ecosystem where people can run
roughshod over short and sensible identifiers.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web