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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#19298

On 04/03/2012 03:34 PM, Stefan Ram wrote:
> William Ahern <william@wilbur.25thandClement.com> writes:
>> I always thought the soluion to that was:
>> 	pnvlt_do_stuff()
> 
>   C89 only had the first six characters being significant in
>   external identifiers. (And there are reports that C89 still
>   is widely used today.)

Only six characters were guaranteed significant in C89, but an
implementation was permitted to use more than just the first six. Do you
have any reports of a C89 implementation, in use today, that treats
fewer than 31 characters as significant? If so, how few does it use?

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

#19304

William Ahern wrote:

> I always thought the soluion to that was:
> 
> pnvlt_do_stuff()

This sort of naming policy has the nasty consequence of leading to 
unintelligible names, which in turn leads to unreadable code.  


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

Maybe the question which should be asked is simply: is that limit really 
justified nowadays?  Maybe it was practically mandatory in 1972, but things 
have progressed a bit since then.  Possibly the reason that led to that 
limit in 1972 is no longer present in 2011.


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

This would imply that using short identifier names somehow represents the 
right way of doing things, but I don't see how anyone can claim that a piece 
of code can improve if someone decides to employ a form of dictionary 
compression on the identifier names, or if a function is somehow made worse 
if an extra letter is added to its identifier.


Rui Maciel

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

#19314

בתאריך יום שלישי, 3 באפריל 2012 21:27:46 UTC+1, מאת Rui Maciel:
> 
> This would imply that using short identifier names somehow represents the 
> right way of doing things, but I don't see how anyone can claim that a piece 
> of code can improve if someone decides to employ a form of dictionary 
> compression on the identifier names, or if a function is somehow made worse 
> if an extra letter is added to its identifier.
> 
>
That's important.

You want "mean" for an average, not meanf, meand and so on, which soon creates a situation where the user is left scratching round in the documentation for the right name, and maybe what it does (is stdev_s sample standard devation, or deviation of a  list of shorts?)

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

#19532

In article <namespaces-20120403213425@ram.dialup.fu-berlin.de>,
Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>  C89 only had the first six characters being significant in
>  external identifiers.

And this is -totally- unworkable.  I mean really, 'window_draw' and
'window_destroy' are the same?

Realistically, if one were confined to such a linker, it would be
necessary to implement some sort of symbol hashing, to write at-all
non-trivial software, and avoid insane programmers.

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

#19535

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> jgk@panix.com (Joe keane) writes:
>>Realistically, if one were confined to such a linker, it would be
>>necessary to implement some sort of symbol hashing, to write at-all
>>non-trivial software, and avoid insane programmers.
>
>   Possibly, one could employ the preprocessor?
>
> #define window_draw kP2RzQ

As long as we're talking about lousy linkers, C89 also allowed
the linker to ignore differences in case, so possibly there would
be no point in using both cases in your macro expansions.

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

#19539

In article <877gxm6ix6.fsf@blp.benpfaff.org>,
Ben Pfaff  <blp@cs.stanford.edu> wrote:
>As long as we're talking about lousy linkers, C89 also allowed the
>linker to ignore differences in case, so possibly there would be no
>point in using both cases in your macro expansions.

worst case

Allowed characters are space, uppercase letters, digits, '.', '$'.
Space is used in a predefined way for symbols less than six characters;
the punctuation is for assembly programmers who know what they are doing
and would like to stay out of the way of those darn C programmers.

about two billion codes

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

#19596

In article <877gxm6ix6.fsf@blp.benpfaff.org>,
Ben Pfaff  <blp@cs.stanford.edu> wrote:
>As long as we're talking about lousy linkers, C89 also allowed the
>linker to ignore differences in case, so possibly there would be no
>point in using both cases in your macro expansions.

worst case

Allowed characters are space, uppercase letters, digits, '.', '$'.
Space is used in a predefined way for symbols less than six characters;
the punctuation is for assembly programmers who know what they are doing
and would like to stay out of the way of those darn C programmers.

about two billion codes

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

#19601

jgk@panix.com (Joe keane) writes:
> In article <877gxm6ix6.fsf@blp.benpfaff.org>,
> Ben Pfaff  <blp@cs.stanford.edu> wrote:
>>As long as we're talking about lousy linkers, C89 also allowed the
>>linker to ignore differences in case, so possibly there would be no
>>point in using both cases in your macro expansions.
>
> worst case
>
> Allowed characters are space, uppercase letters, digits, '.', '$'.
> Space is used in a predefined way for symbols less than six characters;
> the punctuation is for assembly programmers who know what they are doing
> and would like to stay out of the way of those darn C programmers.
>
> about two billion codes

You say that linker symbols can contain space, '.', and '$'?  Do you
have some specific linker in mind?

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

#19613

"Keith Thompson" <kst-u@mib.org> wrote in message
news:lnd37c1jj7.fsf@nuthaus.mib.org...
> jgk@panix.com (Joe keane) writes:
>> In article <877gxm6ix6.fsf@blp.benpfaff.org>,
>> Ben Pfaff  <blp@cs.stanford.edu> wrote:
>>>As long as we're talking about lousy linkers, C89 also allowed the
>>>linker to ignore differences in case, so possibly there would be no
>>>point in using both cases in your macro expansions.
>>
>> worst case
>>
>> Allowed characters are space, uppercase letters, digits, '.', '$'.
>> Space is used in a predefined way for symbols less than six characters;
>> the punctuation is for assembly programmers who know what they are doing
>> and would like to stay out of the way of those darn C programmers.
>>
>> about two billion codes
>
> You say that linker symbols can contain space, '.', and '$'?  Do you
> have some specific linker in mind?

I think he means the implied spaces, after a name shorter than 6 characters 
(although that only makes sense if all names are padded out to the same 
length).

And my Nasm assembler doesn't seem to mind "." and "$" inside global names,
so I'd guess the linker will accept it too.

-- 
Bartc 

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

#19625

"BartC" <bc@freeuk.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lnd37c1jj7.fsf@nuthaus.mib.org...
>> jgk@panix.com (Joe keane) writes:
>>> In article <877gxm6ix6.fsf@blp.benpfaff.org>,
>>> Ben Pfaff  <blp@cs.stanford.edu> wrote:
>>>>As long as we're talking about lousy linkers, C89 also allowed the
>>>>linker to ignore differences in case, so possibly there would be no
>>>>point in using both cases in your macro expansions.
>>>
>>> worst case
>>>
>>> Allowed characters are space, uppercase letters, digits, '.', '$'.
>>> Space is used in a predefined way for symbols less than six characters;
>>> the punctuation is for assembly programmers who know what they are doing
>>> and would like to stay out of the way of those darn C programmers.
>>>
>>> about two billion codes
>>
>> You say that linker symbols can contain space, '.', and '$'?  Do you
>> have some specific linker in mind?
>
> I think he means the implied spaces, after a name shorter than 6 characters 
> (although that only makes sense if all names are padded out to the same 
> length).
>
> And my Nasm assembler doesn't seem to mind "." and "$" inside global names,
> so I'd guess the linker will accept it too.

My point is that nothing in the C standard suggests that space, '.', and
'$' are valid characters.  C89/C90 merely says that external names have
at least 6 significant initial characters, possibly case-insensitive.

A linker that's part of a conforming C89 implementation needn't accept
anything other than letters, digits, and underscores.

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

#19660

In article <lnd37c1jj7.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@mib.org> wrote:
>Do you have some specific linker in mind?

I stole this from RSTS filenames.

From the PDP-10, it looks obvious where the magic number six comes from.
So it has 6-bit bytes.  From there you can see why lower case is usually
not allowed in filenames et cetera.

On the PDP-11, you'd be crazy to have other than eight-bit bytes.  So
then everyone agrees on ASCII and disagrees on what if the last bit is
set.  But you can still do funny stuff.

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

#19805

Joe keane wrote on Sunday, April 15, 2012 12:46 PM (comp.lang.c):

> In article <lnd37c1jj7.fsf@nuthaus.mib.org>,
> Keith Thompson  <kst-u@mib.org> wrote:
>>Do you have some specific linker in mind?
> 
> I stole this from RSTS filenames.
> 
> From the PDP-10, it looks obvious where the magic number six comes from.
> So it has 6-bit bytes.  From there you can see why lower case is usually
> not allowed in filenames et cetera.

The PDP-10 "byte" was any size from 1-36 bits using the bype-pointer 
instructions.  Symbol tables rarely used 6-bit characters, but an even 
smaller character set using RAD50 (modulo decimal 40 = octal 50).
It was not unusual to use 5 7-bit bytes or 4 9-bit bytes in a 36 bit word.  
And you could easily have 4 8-bit bytes with 4 bits to to play with as flags 
or error checking.


> 
> On the PDP-11, you'd be crazy to have other than eight-bit bytes.  So
> then everyone agrees on ASCII and disagrees on what if the last bit is
> set.  But you can still do funny stuff.

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

#19813

"Martin Ambuhl" <mambuhl@earthlink.net> wrote in message 
news:jmtrlh$jgr$1@dont-email.me...
> Joe keane wrote on Sunday, April 15, 2012 12:46 PM (comp.lang.c):
>
>> In article <lnd37c1jj7.fsf@nuthaus.mib.org>,
>> Keith Thompson  <kst-u@mib.org> wrote:
>>>Do you have some specific linker in mind?
>>
>> I stole this from RSTS filenames.
>>
>> From the PDP-10, it looks obvious where the magic number six comes from.
>> So it has 6-bit bytes.  From there you can see why lower case is usually
>> not allowed in filenames et cetera.
>
> The PDP-10 "byte" was any size from 1-36 bits using the bype-pointer
> instructions.  Symbol tables rarely used 6-bit characters, but an even
> smaller character set using RAD50 (modulo decimal 40 = octal 50).

Radix-50 was designed to store 3 characters in 16-bits, or 6 characters in 
32-bits.

But the pdp-10 had 36-bits and could also use 'Sixbit' encoding to more 
easily store six 6-bit characters in a machine word. You got a 6-bit 
character subtracting 32 from the Ascii code. That's easier than mapping to 
a totally new character set and using multiplication to pack every 3 chars 
into 16-bits.

I can't remember whether the actual file system and linker programs, which 
were usually restricted to 6 characters, used radix-50 or sixbit, but the 
latter would seem to be the sensible choice on that machine (radix-50 seemed 
more a pdp-11 thing). (Certainly I for one used sixbit for symbol tables, 
and never radix-50.)

-- 
Bartc 

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

#19536

"Joe keane" <jgk@panix.com> wrote in message 
news:jm4r5l$lah$1@reader1.panix.com...
> In article <namespaces-20120403213425@ram.dialup.fu-berlin.de>,
> Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>>  C89 only had the first six characters being significant in
>>  external identifiers.
>
> And this is -totally- unworkable.  I mean really, 'window_draw' and
> 'window_destroy' are the same?
>
> Realistically, if one were confined to such a linker, it would be
> necessary to implement some sort of symbol hashing, to write at-all
> non-trivial software, and avoid insane programmers.

Perhaps writing a proper linker is an option. How difficult can it be?

It must be less effort to do that once, than for a bunch of programmers to 
struggle with 6-character limitations for years.

-- 
Bartc 

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

#19626

In article <jm4uvq$q3d$1@dont-email.me>, BartC <bc@freeuk.com> wrote:
>Perhaps writing a proper linker is an option. How difficult can it be?

Sometimes it's easier to just fix the problem.

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

#19553

Joe keane <jgk@panix.com> wrote:
> In article <namespaces-20120403213425@ram.dialup.fu-berlin.de>,
> Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> >  C89 only had the first six characters being significant in
> >  external identifiers.
> 
> And this is -totally- unworkable.  I mean really, 'window_draw' and
> 'window_destroy' are the same?

Which is why you don't call them that, you call them wndraw and wndest. 
I know it's hard to believe, but people actually managed to write
complex software systems under those kinds of restrictions for decades.

> Realistically, if one were confined to such a linker, it would be
> necessary to implement some sort of symbol hashing, to write at-all
> non-trivial software, and avoid insane programmers.

Some implementations on such platforms did choose to go with a
proprietary object file format and linker, but that makes
interoperability with other languages problematic.  (Yes, people used to
actually use different languages for differents pieces of a single
program.)
-- 
Larry Jones

I sure like summer vacation. -- Calvin

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

#19559

lawrence.jones@siemens.com wrote:

> Joe keane <jgk@panix.com> wrote:
> > In article <namespaces-20120403213425@ram.dialup.fu-berlin.de>,
> > Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> > >  C89 only had the first six characters being significant in
> > >  external identifiers.
> > 
> > And this is -totally- unworkable.  I mean really, 'window_draw' and
> > 'window_destroy' are the same?
> 
> Which is why you don't call them that, you call them wndraw and wndest. 
> I know it's hard to believe, but people actually managed to write
> complex software systems under those kinds of restrictions for decades.

That's true but we had mostly 8 characters for labels and 7 for external
names. I don't know if I could have survived with only 6 ;-)

> > Realistically, if one were confined to such a linker, it would be
> > necessary to implement some sort of symbol hashing, to write at-all
> > non-trivial software, and avoid insane programmers.

Are there any other kind?

> Some implementations on such platforms did choose to go with a
> proprietary object file format and linker, but that makes
> interoperability with other languages problematic.  (Yes, people used to
> actually use different languages for differents pieces of a single
> program.)

They still do, only they tend to interoperate much better on almost all
platforms than they did before.

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

#19319

Stefan Ram wrote:

> Rui Maciel <rui.maciel@gmail.com> writes:
>>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 this regard, one can also read the paragraph starting with
> 
>       »The sad conclusion that namespaces were a mistake.«
> 
> http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=286

The thesis presented in that article is that "namespaces were a mistake" due 
to the following two reasons:
- programmers may use namespaces in a way that the author doesn't like
- operator overloading may have led the implementation of argument dependent 
lookup in some compilers way back in 2006 to be a bit dodgy


The first reason is a bit silly while the second one doesn't apply to the C 
programming language.


Rui Maciel

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

#19320

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

> > Rui Maciel <rui.maciel@gmail.com> writes:
> >>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 this regard, one can also read the paragraph starting with
> > 
> >       »The sad conclusion that namespaces were a mistake.«
> > 
> > http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=286

> The thesis presented in that article is that "namespaces were a mistake"
> due to the following two reasons:
> - programmers may use namespaces in a way that the author doesn't like
<snip>
> The first reason is a bit silly while the second one doesn't apply to the C 
> programming language.

I think you understate this. What he showed wasn't what "programmers" did,
but how actual standards writers and implementors abused and diminished
namespaces.

Namespaces don't prevent name clashing. As regards naming conflicts,
namespaces are hardly any different than prefixing and undercores. That's
because everybody prefers to use (and reuse) short, easy to remember
prefixes--like xml or dns or socket or, in the C++ case, "std". The
alternative is to go the Java route, incorporating global namespaces a la
DNS or X.500. One leaves you, effectively, with the status quo; the other
leads somewhere many people don't want to go.

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

#19335

On Wednesday, April 4, 2012 12:44:19 AM UTC+1, William Ahern wrote:
> Rui Maciel <rui.maciel@gmail.com> wrote:
> > Stefan Ram wrote:
> > > Rui Maciel <rui.maciel@gmail.com> writes:

> > >>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 this regard, one can also read the paragraph starting with
> > > 
> > >       »The sad conclusion that namespaces were a mistake.«
> > > 
> > > http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=286
> 
> > The thesis presented in that article is that "namespaces were a mistake"
> > due to the following two reasons:
> > - programmers may use namespaces in a way that the author doesn't like
> <snip>
> > The first reason is a bit silly while the second one doesn't apply to the C 
> > programming language.
> 
> I think you understate this. What he showed wasn't what "programmers" did,
> but how actual standards writers and implementors abused and diminished
> namespaces.
> 
> Namespaces don't prevent name clashing. As regards naming conflicts,
> namespaces are hardly any different than prefixing and undercores. That's
> because everybody prefers to use (and reuse) short, easy to remember
> prefixes--like xml or dns or socket or, in the C++ case, "std". The
> alternative is to go the Java route, incorporating global namespaces a la
> DNS or X.500. One leaves you, effectively, with the status quo; the other
> leads somewhere many people don't want to go.

I'm not sure namespaces quite leave you at status quo. You have the option of using a using directive- and using short names

   using my_wonderful_sockets;
   socket.open();

or ommitting the using directive and having long names
    my_wonderful_sockets::socket.open();

but also (I understand) having some sort of namespace alias
    sock::socket.open();


If sock:: turns out to collide you can fiddle with aliases and using directives until you get the right library.

Even using the using directive you've eliminated all those other socket.open() versions that might confuse things.

C++'s problem might be that the standard libary is a pretty poor example of how to partition a namespace! ie. not to partition it at all. The reason they tell you not to stick "using std;" in, is because it stuffs thousands of names into your namespace. "using" wouldn't be such bad news with decently sized namespaces.




   

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web