An example of what you should most likely do in your program is the following:

  namespace myprogram{   class myclass;}using namespace myprogram;int main(int argc, char *argv[]){   myclass myinstance;}  

There isn''t much benefit to that other than that it gets you in the habit of doing it. You didn''t ask what you should do in your program though. You asked what they are and when/how they should be used. So you got stripped down examples. Certainly it would not make any sense to simply nest a bunch of namespaces to define one class. Generally I divide things up into groups of five to ten. So if the company had five systems and each system had five projects and each project created five libraries and each library had five classes that would be 625 classes. Across an entire company with an I/S staff of a few thousand you could easily get into tens of thousands of classes. Think Microsoft, not you dinking around on a computer at home.

What a namespace does is provide a context. So someone says ram. Do they mean random access memory, a male goat or running something into something else? You need a context. So perhaps you have Computer::RAM, Animal::Ram, Action::Ram. Now the possiblities are reduced considerably. Do you write programs in an environment where the most appropriate name for a class is the same as the most appropriate name for a differant class in a differant context? Apparently not. It doesn''t change what they are and when/how you should use them. It simply means you may have no need for them. Since it only takes four lines of code if you count the brackets I would argue you might as well use them even if you don''t need them. Then perhaps someday you will have an alternative to change a name used in a hundred programs. That alternative would be fully qualifying the name in the one program within which you actually have a problem.

Thanks Oluseyi, but that wasn't exactly what I was asking. Java packages work in almost the exactly the same way as you described namespaces (just use "import whatever .*;" instead of "using whatever").

In Java you can do this

    package wayfarerx.stuff; // Puts this class in the 'wayfarerx.stuff' packageclass MyClass{  public int pubInt; // public, everyone can read/write  protected int proInt; // protected, only this class and sub-classes can read/write  int packInt; // Look wierd (for Java)? This uses package protection, only this                // class and classes in the 'wayfarerx.stuff' package can read/write  private int priInt; // private, only for this class}    

I was wondering if C++ provided a mechanism similar to package protection in Java.

quote:
However, since you can import entities at varying scope, you may wish to import the entire namespace within a restricted scope.

Hmmm, didn't know you could do that. Sweet.

"So crucify the ego, before it's far too late. To leave behind this place so negative and blind and cynical, and you will come to find that we are all one mind. Capable of all that's imagined and all conceivable."
- Tool
------------------------------


Edited by - wayfarerx on December 11, 2001 2:32:35 PM

You can always use the unnamed namespace, which makes anything declared in it invisible from other files. Just like the ol'' C static keyword. And yes, you can nest it withing other namespaces.

file 1:=======namespace FOO{  namespace  {    int foo() { return 0; }  }  int bar()  {    return foo(); // Can use functions of the unnamed namespace locally  }}int myfunc1(){  return FOO::bar() + FOO::foo(); // still works}file 2:namespace FOO{  namespace  {    int foo() { return 1; } // ok, no conflict, unnamed namespace  }  int bar() // won''t work: FOO::bar() already exist  {    return foo(); // Can use functions of the unnamed namespace locally  }  int baz()  {    return foo(); // Will use the local foo(), returning 1  }}int myfunc2(){  return FOO::baz() + FOO::foo(); // will work, with the local foo();}    

There''s no additional protection gained by C++ namespaces, that''s what friend is for

Actually I think I lied. If you declare a variable to be static at a namespace scope, only things in that namespace will know it exist. It''s a bit crduer than Java''s package scope... but that''s what friend is for. It''d be nice if you could distinguish between protected and private friends without using a proxy class.

Actaully, the C++ way would be to allow a public, protected, and private visiblity defintion within a namespace. Public is for all to see, sub-namespaces can see protected, and only that namespace can see it''s private part.

Actually, it''s sooo obivous I wonder if it work that way now....

quote:
syntax error : ''public''

Damn

Magmai Kai Holmlor

"Oh, like you''ve never written buggy code" - Lee

"What I see is a system that _could do anything - but currently does nothing !" - Anonymous CEO

Thanks for the info guys!

"So crucify the ego, before it''s far too late. To leave behind this place so negative and blind and cynical, and you will come to find that we are all one mind. Capable of all that''s imagined and all conceivable."
- Tool
------------------------------

quote:
But in reality do we use all these features?

A better question is should we use those features.

.Net makes extensive use of namespaces, as does the Java core, oui?

Is there even such a thing as namespace overkill? How could it be too organized? Well, I guess one namespace per class would be overkill...

My motivation is to make code-compeletion more useful. If you know you need a socket::protocol::&ltavialable protocols pop-up here&gr and not everything under the sun.

Magmai Kai Holmlor

"Oh, like you''ve never written buggy code" - Lee

"What I see is a system that _could do anything - but currently does nothing !" - Anonymous CEO