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

Groups > comp.lang.c++ > #6112 > unrolled thread

Anonymous namespace

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

Contents

  Anonymous namespace ruben safir <ruben@mrbrklyn.com> - 2011-06-02 21:53 -0400
    Re: Anonymous namespace Pete Becker <pete@versatilecoding.com> - 2011-06-02 16:00 -1000
    Re: Anonymous namespace ruben safir <ruben@mrbrklyn.com> - 2011-06-02 22:40 -0400
      Re: Anonymous namespace ruben safir <ruben@mrbrklyn.com> - 2011-06-03 02:29 -0400
        Re: Anonymous namespace Ian Collins <ian-news@hotmail.com> - 2011-06-03 20:12 +1200
          Re: Anonymous namespace Ruben Safir <mrbrklyn@panix.com> - 2011-06-04 02:40 +0000
            Re: Anonymous namespace Ian Collins <ian-news@hotmail.com> - 2011-06-04 15:40 +1200
              Re: Anonymous namespace Ruben Safir <ruben@mrbrklyn.com> - 2011-06-04 04:56 +0000
                Re: Anonymous namespace Ian Collins <ian-news@hotmail.com> - 2011-06-04 17:19 +1200
                  Re: Anonymous namespace Ruben Safir <ruben@mrbrklyn.com> - 2011-06-04 05:37 +0000
                    Re: Anonymous namespace Ian Collins <ian-news@hotmail.com> - 2011-06-04 17:40 +1200
          Re: Anonymous namespace Ruben Safir <ruben@mrbrklyn.com> - 2011-06-04 05:05 +0000
            Re: Anonymous namespace Ian Collins <ian-news@hotmail.com> - 2011-06-04 17:31 +1200
              Re: Anonymous namespace Ruben Safir <ruben@mrbrklyn.com> - 2011-06-04 05:42 +0000
        Re: Anonymous namespace Öö Tiib <ootiib@hot.ee> - 2011-06-03 06:08 -0700
          Re: Anonymous namespace Ruben Safir <ruben@mrbrklyn.com> - 2011-06-04 05:09 +0000
            Re: Anonymous namespace Ian Collins <ian-news@hotmail.com> - 2011-06-04 17:32 +1200
              Re: Anonymous namespace Ruben Safir <ruben@mrbrklyn.com> - 2011-06-04 05:39 +0000
                Re: Anonymous namespace Ian Collins <ian-news@hotmail.com> - 2011-06-04 17:45 +1200
      Re: Anonymous namespace gwowen <gwowen@gmail.com> - 2011-06-03 01:08 -0700
        Re: Anonymous namespace Ian Collins <ian-news@hotmail.com> - 2011-06-03 20:17 +1200
          Re: Anonymous namespace Ruben Safir <ruben@mrbrklyn.com> - 2011-06-04 05:08 +0000
        Re: Anonymous namespace Victor Bazarov <v.bazarov@comcast.invalid> - 2011-06-03 09:44 -0400
          Re: Anonymous namespace Ruben Safir <mrbrklyn@panix.com> - 2011-06-04 02:44 +0000
          Re: Anonymous namespace Ian Collins <ian-news@hotmail.com> - 2011-06-04 15:57 +1200
          Re: Anonymous namespace Ruben Safir <ruben@mrbrklyn.com> - 2011-06-04 05:14 +0000
            Re: Anonymous namespace "Bo Persson" <bop@gmb.dk> - 2011-06-04 11:33 +0200
    Re: Anonymous namespace Michael Doubez <michael.doubez@free.fr> - 2011-06-03 03:10 -0700
      Re: Anonymous namespace Ruben Safir <mrbrklyn@panix.com> - 2011-06-04 02:48 +0000
        Re: Anonymous namespace Ian Collins <ian-news@hotmail.com> - 2011-06-04 16:01 +1200
          Re: Anonymous namespace Ruben Safir <ruben@mrbrklyn.com> - 2011-06-04 05:16 +0000
            Re: Anonymous namespace Ian Collins <ian-news@hotmail.com> - 2011-06-04 17:34 +1200
    Re: Anonymous namespace Ruben Safir <ruben@mrbrklyn.com> - 2011-06-04 05:01 +0000
      Re: Anonymous namespace Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-06-09 11:26 +0000
        Re: Anonymous namespace Ruben Safir <ruben@mrbrklyn.com> - 2011-06-10 04:12 +0000
          Re: Anonymous namespace Michael Doubez <michael.doubez@free.fr> - 2011-06-10 01:49 -0700
            Re: Anonymous namespace mrbrklyn <ceo.brooklyn@gmail.com> - 2011-06-10 10:34 -0700
            Re: Anonymous namespace mrbrklyn <ceo.brooklyn@gmail.com> - 2011-06-10 10:45 -0700
              Re: Anonymous namespace Michael Doubez <michael.doubez@free.fr> - 2011-06-12 00:01 -0700
                Re: Anonymous namespace ruben safir <ruben@mrbrklyn.com> - 2011-06-13 04:08 +0000
                  Re: Anonymous namespace Michael Doubez <michael.doubez@free.fr> - 2011-06-13 08:43 -0700
          Re: Anonymous namespace Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-06-10 18:27 +0000
            Re: Anonymous namespace ruben safir <ruben@mrbrklyn.com> - 2011-06-13 05:02 +0000
              Re: Anonymous namespace Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-06-13 07:58 +0000
                Re: "namespaces were a mistake" (was: Anonymous namespace) Öö Tiib <ootiib@hot.ee> - 2011-06-13 09:56 -0700
                Re: "namespaces were a mistake" (was: Anonymous namespace) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-06-13 19:52 +0000
                  Re: "namespaces were a mistake" Miles Bader <miles@gnu.org> - 2011-06-14 13:43 +0900
                    Re: "namespaces were a mistake" Miles Bader <miles@gnu.org> - 2011-06-15 07:15 +0900
                      Re: "namespaces were a mistake" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-06-15 12:01 +0000
                  Re: "namespaces were a mistake" (was: Anonymous namespace) drew@furrfu.invalid (Drew Lawson) - 2011-06-14 12:24 +0000
                    Re: "namespaces were a mistake" (was: Anonymous namespace) gwowen <gwowen@gmail.com> - 2011-06-14 06:00 -0700
                      Re: "namespaces were a mistake" (was: Anonymous namespace) Joshua Maurice <joshuamaurice@gmail.com> - 2011-06-14 14:10 -0700
                    Re: "namespaces were a mistake" Miles Bader <miles@gnu.org> - 2011-06-15 06:30 +0900
                Re: Anonymous namespace Ruben Safir <ruben@mrbrklyn.com> - 2011-06-27 16:34 +0000
                  Re: Anonymous namespace Victor Bazarov <v.bazarov@comcast.invalid> - 2011-06-27 14:29 -0400

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

#6702

On 13 juin, 06:08, ruben safir <ru...@mrbrklyn.com> wrote:
> On Sun, 12 Jun 2011 00:01:17 -0700, Michael Doubez wrote:
> > On 10 juin, 19:45, mrbrklyn <ceo.brook...@gmail.com> wrote:
> >> On Jun 10, 4:49 am, Michael Doubez <michael.dou...@free.fr> wrote:
>
> >> > On 10 juin, 06:12, Ruben Safir <ru...@mrbrklyn.com> wrote:
[snip]
> >> C) The utterly fail to teach fundamentals.  Fundamentals...this is a
> >> compiler.  This is an editor.
>
> > Well. I guess an internet tutorial is best suited for this kid of
> > demand.
>
> This really needs to be integrated in every section of a language book.  
> Compilers, linkers and stacks need to be a constant subject.

But it is part of the context. The books teach the language, not the
tools.

I suppose your chemistry book didn't recall the principe of
spectroscometers (or whatever tools are used).

> It frankly
> boggles my mind that templates are taught without compiler discussion,
> and the standards could be annotated from time to time.
>
> >> D) They fail to teach theory.
>
> > Theory of what ?
>
> memory, compilers, stacks, binary representation (which might be taught
> before pointers), esied optimization, scope theory and practice,
> structure red programming theory, sorting theory, algorithms, lamda's
> just to name a few things.
>
> When i taught at the New School, it took me 2 weeks to understand that
> students really didn't understand what a variable was, or the
> relationship between their keyboard, output device to the computer.

The more things are complex, the more context you need.
It is even harder when teaching; you have my sympathy.

> > If you are thinking theory of design, there is the pattern movement.
>
> > There are also some books like Alexander stephanov's Elements of
> > programming.
> >http://www.elementsofprogramming.com/
>
> >> I have a doctoral in Pharmaceutics and if my text on differential
> >> equations were like that, I'd have difficult time graduating.
>
> > But that was science with a rather limited scope.
>
> The physical chemistry and math wasn't.

But they were science (which CS is not totally). And they were part of
the problem; the engineering part is still something you had to
practive in order to learn.


> >> But I'll look at your suggestions although the idea, "get you up to
> >> speed" would ordinary  be exactly what I don't want.  If I want to get
> >> up to speed fast, one can drop back down to perl.
>
> > I mean up to speed concerning C++'s usage and idioms.
>
> Learning idioms is very important.  But learning how and why they work is
> what is necessary to truly be a master of any language.

Yes, all the most with C++ IMO.

This article is a bit dated but still somewhat accurate:
http://www.allankelly.net/writing/webonly/highchurch.html

--
Michael

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

#6575

On Fri, 2011-06-10, Ruben Safir wrote:
> On Thu, 09 Jun 2011 11:26:08 +0000, Jorgen Grahn wrote:
>
>
>>>> namespace unique {} using namespace unique; namespace unique { ... }
>>>
>>> ugg - back to the namespace syntax chapter...
>> 
>> If you *do* have a book,
>
>
> Jorgen, do you think I have any C++ references and do you think I read 
> them.  

If you had mentioned that you've read book X but still don't
understand anonymous namespace because of Y, then I wouldn't have
complained.

> It's irrelevant since the namespace sections in Stroudtrup are 
> nearly incomprehensible and written more like a dissertation than a 
> learning tool,

I know that Stroustrup's book can be unhelpful at times, but as I
recall it, it was pretty clear about anonymous namespaces. I learned
how to use them (and where and why) based on only that book.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

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

#6673

On Fri, 10 Jun 2011 18:27:29 +0000, Jorgen Grahn wrote:

> On Fri, 2011-06-10, Ruben Safir wrote:
>> On Thu, 09 Jun 2011 11:26:08 +0000, Jorgen Grahn wrote:
>>
>>
>>>>> namespace unique {} using namespace unique; namespace unique { ... }
>>>>
>>>> ugg - back to the namespace syntax chapter...
>>> 
>>> If you *do* have a book,
>>
>>
>> Jorgen, do you think I have any C++ references and do you think I read
>> them.
> 
> If you had mentioned that you've read book X but still don't understand
> anonymous namespace because of Y, then I wouldn't have complained.
> 

I'm partly sympathetic to that point.  Your obviously not sitting in my 
chair and you don't really know what I have and haven't read.  But I'd 
think that after all those previous posts, you'd have the gist that I'm 
pouring over several texts.

>> It's irrelevant since the namespace sections in Stroudtrup are nearly
>> incomprehensible and written more like a dissertation than a learning
>> tool,
> 
> I know that Stroustrup's book can be unhelpful at times, but as I recall
> it, it was pretty clear about anonymous namespaces. I learned how to use
> them (and where and why) based on only that book.
>

I found the entire section, and other other section, and the other 
section, to be largely incomprehensible and I was going to get back to 
rereading them after i gained more fluency with the language.  I want to 
better learn iostreams etc first, then I'll swing back and look at 
namespaces again.  I'm not a single pass compiler :)

Lippman's explanation of namespaces was just outright bizarre and 
frustrating.

Trying to solve the problem of namespace polution by adding a 100,000 
extra keystroke, to me is pointless...but that is another issue.  I have 
to deal with what C++ is, not what I want it to be.

(at least it is not tcl)

Ruben
 
> /Jorgen

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

#6683

On Mon, 2011-06-13, ruben safir wrote:
> On Fri, 10 Jun 2011 18:27:29 +0000, Jorgen Grahn wrote:
>
>> On Fri, 2011-06-10, Ruben Safir wrote:
>>> On Thu, 09 Jun 2011 11:26:08 +0000, Jorgen Grahn wrote:
>>>
>>>
>>>>>> namespace unique {} using namespace unique; namespace unique { ... }
>>>>>
>>>>> ugg - back to the namespace syntax chapter...
>>>> 
>>>> If you *do* have a book,
>>>
>>>
>>> Jorgen, do you think I have any C++ references and do you think I read
>>> them.
>> 
>> If you had mentioned that you've read book X but still don't understand
>> anonymous namespace because of Y, then I wouldn't have complained.
>> 
>
> I'm partly sympathetic to that point.  Your obviously not sitting in my 
> chair and you don't really know what I have and haven't read.  But I'd 
> think that after all those previous posts, you'd have the gist that I'm 
> pouring over several texts.

No, I had missed that. I knew I had read other postings by you, but
didn't remember what they were about.

...
> Trying to solve the problem of namespace polution by adding a 100,000 
> extra keystroke, to me is pointless...but that is another issue.  I have 
> to deal with what C++ is, not what I want it to be.

I think of namespaces (user-defined, non-anonymous) this way:

  I want the freedom to name things in a straightforward way without
  risking clashes with other people's stuff. I don't want to call some
  sorting function reorder() just because the standard library used up
  the name sort().  And I want the same freedom from conflicts
  /between/ subsystems of my own program.
  
  So I invent the convention of prefixing everything: like my_sort(),
  foo_subsystem_sort(), ...
  
  Namespaces provide a standard way of doing that (my::sort()), and
  since it's part of the language it can be smart and not demand the
  prefix in contexts where it's /obvious/ which one I mean. And it
  lets me manually specify things like "in this context I mean
  my::sort()".
  
  So, compared to the manual alternative, you /save/ typing. /If/ you
  want to solve the naming problem, that is.

That's not the only way to think of it, but I find it helpful.

> (at least it is not tcl)

Damning with faint praise, are we? ;-)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

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

#6706 — Re: "namespaces were a mistake" (was: Anonymous namespace)

On Jun 13, 5:53 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Jorgen Grahn <grahn+n...@snipabacken.se> writes:
> >I want the freedom to name things in a straightforward way without
> >risking clashes with other people's stuff. I don't want to call some
>
>   Danny Kalev, a member of the C++ standards committee between
>   1997 and 2000, writes:
>
>       namespaces were a mistake , see
>
> http://google.to/search?q=cache:www.inform%69t.com/guides/content.asp...
>

I think that is more about taste than serious opinion. He blogs
elsewhere that removal of implicit int was also mistake. For me the
language would be poorer without namespaces and feels lousy with K&R
implicit int.

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

#6733 — Re: "namespaces were a mistake" (was: Anonymous namespace)

On Mon, 2011-06-13, Stefan Ram wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>>I want the freedom to name things in a straightforward way without
>>risking clashes with other people's stuff. I don't want to call some
>
>   Danny Kalev, a member of the C++ standards committee between
>   1997 and 2000, writes:
>
>       »namespaces were a mistake«, see

He's free to say so, but plenty of people I respect disagree.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

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

#6734 — Re: "namespaces were a mistake"

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>>   Danny Kalev, a member of the C++ standards committee between
>>   1997 and 2000, writes:
>>
>>       »namespaces were a mistake«, see
>
> He's free to say so, but plenty of people I respect disagree.

Seriously.  I _love_ namespaces, they're so convenient and painless
compared the stupid "make all your symbol names 5000 characters long
just in case" game we have to play in C (or the older "just don't care
and suffer tons of confusing and annoying conflicts" game)...

I also think his argument is flawed:

He argues that since using explicit prefixes is annoying, that most
people will resort to "using", and that this somehow eliminates the
safety offered by namespaces.  However that simply isn't true, because
in reality, there can be _many_ namespaces used in a non-trivial
program, and the user gets to pick and choose -- in a very fine-grained
way (every file and block can have its own "using" statements) -- which
namespaces are referenced explicitly with prefixes, and which ones are
referenced implicity with "using" (and also when to import specific
symbols vs. all symbols in a namespace).

That gives the _user_ (er, "developer") the flexibility to choose which
potential conflicts there are, and which tradeoffs to make between
verbosity and potential conflict based on his specific circumstances.
In practice, this usually means one or two of the most important
namespaces _for a particular context_ are imported with "using", and
other less heavily-used namespaces are referenced explicitly (or
individual symbols imported from them).  This is an extremely
convenient, and natural way to manage these name conflict issues.

Could namespaces be made better?  I dunno, probably, in some way, but
certainly the basic concept seems quite sound, and quite useful.

-Miles

-- 
Immortality, n.  A toy which people cry for, And on their knees apply for,
      Dispute, contend and lie for, And if allowed Would be right proud
      Eternally to die for.

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

#6756 — Re: "namespaces were a mistake"

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>Seriously.  I _love_ namespaces, they're so convenient and painless
>>compared the (...) "make all your symbol names 5000 characters long
>>just in case" game we have to play in C
>
>   C90 requires that an implementation needs to have at least
>   the first six characters of an external identifier to be
>   significant. So, a portable C90 program should have all
>   external identifiers differ in the first six characters.

Thank god pretty much everybody ignored that...

-miles

-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)

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

#6764 — Re: "namespaces were a mistake"

On Tue, 2011-06-14, Miles Bader wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>>Seriously.  I _love_ namespaces, they're so convenient and painless
>>>compared the (...) "make all your symbol names 5000 characters long
>>>just in case" game we have to play in C
>>
>>   C90 requires that an implementation needs to have at least
>>   the first six characters of an external identifier to be
>>   significant. So, a portable C90 program should have all
>>   external identifiers differ in the first six characters.
>
> Thank god pretty much everybody ignored that...

IIRC, Stroustrup writes in "Design and evolution" about how he lobbied
for longer symbols in linkers -- and that he was surprised how quickly
it became a non-issue.  I remember that Lattice C got support for 1000
(100?) characters in 1992 or so, as a side effect of shipping a C++
compiler.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .  .
\X/     snipabacken.se>   O  o   .

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

#6738 — Re: "namespaces were a mistake" (was: Anonymous namespace)

In article <slrnivcqkc.gtj.grahn+nntp@frailea.sa.invalid>
	Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>On Mon, 2011-06-13, Stefan Ram wrote:
>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>>>I want the freedom to name things in a straightforward way without
>>>risking clashes with other people's stuff. I don't want to call some
>>
>>   Danny Kalev, a member of the C++ standards committee between
>>   1997 and 2000, writes:
>>
>>       »namespaces were a mistake«, see
>
>He's free to say so, but plenty of people I respect disagree.

His point seems (to me) to be more that namespaces are not the
ideal they were hoped to be, rather than that namespaces are a bad
thing.

I agree with his main points -- that fully specifying them is tedious
to write and painful to read, and that "using" and the high tendency
to use it is a Bad Thing.  (I have the misfortune to be using a
package where the developers put "using" directives in the *headers*
so I have to qualify standard library calls that are in the global
name space.)

They are a useful tool, but I think the culture didn't adapt to
them in the best way.

-- 
Drew Lawson            |  Savage bed foot-warmer
                       |    of purest feline ancestry
                       |  Look out little furry folk
                       |    it's the all-night working cat

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

#6739 — Re: "namespaces were a mistake" (was: Anonymous namespace)

On Jun 14, 1:24 pm, d...@furrfu.invalid (Drew Lawson) wrote:

> They are a useful tool, but I think the culture didn't adapt to
> them in the best way.

I think the other problem that Kalev identifies (the difficulty of
fully understanding ADL) is something that afflicts those library
writers and those who use advanced template metaprogramming
techniques, far more than those of us who are unlikely to override
functions in the std namespace, and use templates far more
restrictively.

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

#6748 — Re: "namespaces were a mistake" (was: Anonymous namespace)

On Jun 14, 6:00 am, gwowen <gwo...@gmail.com> wrote:
> On Jun 14, 1:24 pm, d...@furrfu.invalid (Drew Lawson) wrote:
>
> > They are a useful tool, but I think the culture didn't adapt to
> > them in the best way.
>
> I think the other problem that Kalev identifies (the difficulty of
> fully understanding ADL) is something that afflicts those library
> writers and those who use advanced template metaprogramming
> techniques, far more than those of us who are unlikely to override
> functions in the std namespace, and use templates far more
> restrictively.

Not to add anything substantive, but I've always felt ADL was a
mistake. As far as I can tell, a simple workaround would be to put any
namespace functions that you want ADL to affect to the global
namespace. So you get some name pollution - but because of function
overloading it's ok, and it's not like the name pollution is worse:
with ADL, they're in different scopes, but they're still visible, so
IMHO it's still a form of name pollution.

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

#6751 — Re: "namespaces were a mistake"

drew@furrfu.invalid (Drew Lawson) writes:
> They are a useful tool, but I think the culture didn't adapt to
> them in the best way.

His paper essentially posits a straw-man though:  that either people
never use "using" (yielding inconvenience), or use "using" for
_everything_ (yielding hard-to-control conflicts).

But of course, that simply isn't true.  People are free to
mix-and-match, and therein lies much of the advantage of namespaces,
that the _user_ has fine control over the tradeoffs between convenience
and verbosity.

His apparent preferred solution, to simply use C-style symbols with
baked-in prefixes to avoid conflicts, results in the same annoying
verbosity he complains about with namespaces, _without_ giving the user
any control over it.  A big lose if you ask me...

-miles

-- 
The car has become... an article of dress without which we feel uncertain,
unclad, and incomplete.  [Marshall McLuhan, Understanding Media, 1964]

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

#7185

On Mon, 13 Jun 2011 07:58:12 +0000, Jorgen Grahn wrote:

> On Mon, 2011-06-13, ruben safir wrote:
>> On Fri, 10 Jun 2011 18:27:29 +0000, Jorgen Grahn wrote:
>>
>>> On Fri, 2011-06-10, Ruben Safir wrote:
>>>> On Thu, 09 Jun 2011 11:26:08 +0000, Jorgen Grahn wrote:
>>>>
>>>>
>>>>>>> namespace unique {} using namespace unique; namespace unique { ...
>>>>>>> }
>>>>>>
>>>>>> ugg - back to the namespace syntax chapter...
>>>>> 
>>>>> If you *do* have a book,
>>>>
>>>>
>>>> Jorgen, do you think I have any C++ references and do you think I
>>>> read them.
>>> 
>>> If you had mentioned that you've read book X but still don't
>>> understand anonymous namespace because of Y, then I wouldn't have
>>> complained.
>>> 
>>> 
>> I'm partly sympathetic to that point.  Your obviously not sitting in my
>> chair and you don't really know what I have and haven't read.  But I'd
>> think that after all those previous posts, you'd have the gist that I'm
>> pouring over several texts.
> 
> No, I had missed that. I knew I had read other postings by you, but
> didn't remember what they were about.
> 
> ...
>> Trying to solve the problem of namespace polution by adding a 100,000
>> extra keystroke, to me is pointless...but that is another issue.  I
>> have to deal with what C++ is, not what I want it to be.
> 
> I think of namespaces (user-defined, non-anonymous) this way:
> 
>   I want the freedom to name things in a straightforward way without
>   risking clashes with other people's stuff. I don't want to call some
>   sorting function reorder() just because the standard library used up
>   the name sort().  And I want the same freedom from conflicts /between/
>   subsystems of my own program.
>   
>   So I invent the convention of prefixing everything: like my_sort(),
>   foo_subsystem_sort(), ...
>   
>   Namespaces provide a standard way of doing that (my::sort()), and
>   since it's part of the language it can be smart and not demand the
>   prefix in contexts where it's /obvious/ which one I mean. And it lets
>   me manually specify things like "in this context I mean my::sort()".
>   
>   So, compared to the manual alternative, you /save/ typing. /If/ you
>   want to solve the naming problem, that is.
> 
> That's not the only way to think of it, but I find it helpful.
> 
>> (at least it is not tcl)
> 
> Damning with faint praise, are we? ;-)
> 
> /Jorgen


So there is one thing I'm still not understanding.  If something is 
declared in a anonymous namespace, how is it accessed in main?

Ruben

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

#7186

On 6/27/2011 12:34 PM, Ruben Safir wrote:
> On Mon, 13 Jun 2011 07:58:12 +0000, Jorgen Grahn wrote:
>
>> On Mon, 2011-06-13, ruben safir wrote:
>>> On Fri, 10 Jun 2011 18:27:29 +0000, Jorgen Grahn wrote:
>>>
>>>> On Fri, 2011-06-10, Ruben Safir wrote:
>>>>> On Thu, 09 Jun 2011 11:26:08 +0000, Jorgen Grahn wrote:
>>>>>
>>>>>
>>>>>>>> namespace unique {} using namespace unique; namespace unique { ...
>>>>>>>> }
>>>>>>>
>>>>>>> ugg - back to the namespace syntax chapter...
>>>>>>
>>>>>> If you *do* have a book,
>>>>>
>>>>>
>>>>> Jorgen, do you think I have any C++ references and do you think I
>>>>> read them.
>>>>
>>>> If you had mentioned that you've read book X but still don't
>>>> understand anonymous namespace because of Y, then I wouldn't have
>>>> complained.
>>>>
>>>>
>>> I'm partly sympathetic to that point.  Your obviously not sitting in my
>>> chair and you don't really know what I have and haven't read.  But I'd
>>> think that after all those previous posts, you'd have the gist that I'm
>>> pouring over several texts.
>>
>> No, I had missed that. I knew I had read other postings by you, but
>> didn't remember what they were about.
>>
>> ...
>>> Trying to solve the problem of namespace polution by adding a 100,000
>>> extra keystroke, to me is pointless...but that is another issue.  I
>>> have to deal with what C++ is, not what I want it to be.
>>
>> I think of namespaces (user-defined, non-anonymous) this way:
>>
>>    I want the freedom to name things in a straightforward way without
>>    risking clashes with other people's stuff. I don't want to call some
>>    sorting function reorder() just because the standard library used up
>>    the name sort().  And I want the same freedom from conflicts /between/
>>    subsystems of my own program.
>>
>>    So I invent the convention of prefixing everything: like my_sort(),
>>    foo_subsystem_sort(), ...
>>
>>    Namespaces provide a standard way of doing that (my::sort()), and
>>    since it's part of the language it can be smart and not demand the
>>    prefix in contexts where it's /obvious/ which one I mean. And it lets
>>    me manually specify things like "in this context I mean my::sort()".
>>
>>    So, compared to the manual alternative, you /save/ typing. /If/ you
>>    want to solve the naming problem, that is.
>>
>> That's not the only way to think of it, but I find it helpful.
>>
>>> (at least it is not tcl)
>>
>> Damning with faint praise, are we? ;-)
>>
>> /Jorgen
>
>
> So there is one thing I'm still not understanding.  If something is
> declared in a anonymous namespace, how is it accessed in main?

If that "something" is in the anonymous name in the same module, just 
use the name of that something in 'main', it should be accessible.  If 
that "something" is in another module (not the same as 'main'), then you 
can't access it in 'main'.

V
-- 
I do not respond to top-posted replies, please don't ask

[toc] | [prev] | [standalone]

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

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

csiph-web