Topic: [++] Private namespace members in C++?


Author: clamage@taumet.eng.sun.com (Steve Clamage)
Date: 1996/08/09
Raw View
I checked the April '95 draft and the C++ beyond ARM site,
but couldn't find anything that would indicate that this
has already been proposed.

Namespaces have one deficiency: their members cannot be
protected from the outside like class members can be with
a "private:" or "protected:" keyword.

Namespaces could be useful to group together a number of
functions that operate on common data - but such data that
only requires a single instantiation in a program, and is
therefore not suitable for a class. For instance, code
that handles screen I/O could be grouped into namespace ScrIO.
This is an advantage over grouping the code into a class;
class members always have to be dereferenced, while members
of a namespace can be imported into local scope. But, as long
as the members of a namespace cannot be protected like the
members of a class can be, this is not acceptable.

Therefore, "private:" and "public:" keywords might be very
welcome with namespaces, particularly because this probably
wouldn't add to much text to the C++ standard. In fact, it
might be a major deficiency that these keywords aren't already
there.

denis (denis.bider@abm.si)



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763)
Date: 1996/08/09
Raw View
In article <9608090116.AA0064@ppp02.abm.si> clamage@taumet.eng.sun.com
(Steve Clamage) writes:

    [Actually, this is from denis (denis.bider@abm.si).  I've noticed
  that this sometimes happens on articles that Steve Clamage
  moderates...  Please sign your posts (as this author did) just in
  case it happens to your article.]


|> I checked the April '95 draft and the C++ beyond ARM site,
|> but couldn't find anything that would indicate that this
|> has already been proposed.

|> Namespaces have one deficiency: their members cannot be
|> protected from the outside like class members can be with
|> a "private:" or "protected:" keyword.

The main reason that this was not considered, I suspect, is that
namespaces are extendable.  This means that anyone who comes along could
add a (public) member function, and do whatever he wanted with the
private members.

Namespaces are *NOT* protection.  Their only role is to simplify the
prevention of naming conflicts. If you need protection, use a class.

|> Namespaces could be useful to group together a number of
|> functions that operate on common data - but such data that
|> only requires a single instantiation in a program, and is
|> therefore not suitable for a class.

Namespaces do not group together functions that oeprate on common data.
They do exactly what the name suggests, and no more.  They create a new
space for naming, which affects name lookup.

If you require only a single instance of data, then I would suggest
using the singleton pattern.  Static member data is also a possibility.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]





Author: esap@cs.tut.fi (Pulkkinen Esa)
Date: 1996/08/10
Raw View
<biderd@abm.si> wrote:
>Namespaces have one deficiency: their members cannot be
>protected from the outside like class members can be with
>a "private:" or "protected:" keyword.

But you don't need those. First, namespaces can't be derived from
each other, so I can't see much use for the protected keyword.
Secondly, you can use unnamed namespaces to implement private members
as follows:

namespace A
{
  namespace {
    int x,y,z; // only functions in A can access these!
  };
};
--
   Esa Pulkkinen                        | C++ programmers do it virtually
   E-Mail:  esap@cs.tut.fi              | everywhere with a class, resulting
   WWW   :  http://www.cs.tut.fi/~esap/ | in multiple inheritance.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]





Author: davidb@datalytics.com (David Bradley)
Date: 1996/08/12
Raw View
clamage@taumet.eng.sun.com (Steve Clamage) wrote:

>Namespaces have one deficiency: their members cannot be
>protected from the outside like class members can be with
>a "private:" or "protected:" keyword.

If you need this behavior why not just use a class?

It would mean that each function is a static member, but would not
that accomplish what you want?

The quirk would be protected, as there is no such thing as deriving a
name space.

--------------------------------------------
David Bradley         davidb@datalytics.com
Software Engineer
Datalytics, Inc.      http://www.datalytics.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]