multiple DLLs with the same namespace

Yes you can. The framework is built that way. Think of namespaces as the equivalent of a directory system, but for classes. They play the same role.

System.Data is made of different dlls. System.Data.dll contains the basic namespaces (System.Data, System.Data.OleDb, System.Data.SqlClient), but System.Data.OracleClient is built into another dll (System.Data.OracleClient).

So you usually have one big namespace (System.Data), that can be split into many "subnamespaces", either in the same dll, either in different directories.

The convention is that the namespace begins with the name of your company, followed by a general namespace for a group of classes, and possible subnamespaces. And the name of the dll should reflect the main namespace defined inside of it.

My company is JBFI. I have a JBLib library that I carry in all of my applications. The classes in that library are in the JBFI.JBLib namespace, and included in the JBFI.JBlib.dll. But inside that library, I have a few custom components, that I wanted to be able to access directly, so I defined these as being in the JBFI.JBLib.Components namespace. I have another library specific to an application that has a namespace of JBFI.JBWoodwork, included in a JBFI.JBWoodwork.dll.

The advantage of starting a namespace with the name of the company, is that you can easily isolate all your dll through IntelliSense. If I type JBFI when i am working on my woodworking application, I automatically my JBLib and JBWoodwork libraries. When I select JBLib, I automatically see most of the classes in the library, but I have a specific sections in which my Components are regrouped.

I am porting from K&R C some large home-grown libraries.

i made the experience that name issues even with very old code are rare and easy-to-solve after you get a compiler error. especially if you intend to port to a class interface anyhow, the costs for solving name problems should be small.

namespaces are a solution to naming issues but also may create new problems with wrongly placed using clauses or when mixing up similar functions in different name spaces.

i can't confirm the advantages of namespaces for the intellisense forecast, since this is much more precise if you would use the class scope or a variable (try 'this->' to get a list of current members).

Sara

I just want to close the loop.

using namespace one;
using namespace two;
using namespace three;

Will make all three namespaces available to the ensuing program?  If there is a class "foo" in namespace one and also in two, the compiler/linker will throw an error, but I can resolve that by using something like two::foo.  Correct?

As for nested namespaces, for instance:
    namespace RH
          .
          .
          .
          namespace RH.one
          .
          .
          .
         namespace RH.two
         .
         .
         .
So to see the items in RH.two
       using namespace RH----I think that RH.two would still be hidden.  Correct?

       using namespace RH
       using namespace RH.two  will this expose RH.two?

       using namespace RH::RH.two  will this work?

Finally, if I create a library/dll with namespace one, and in that namespace is a class foo, then there are only two ways for a program to see the class: using namespace one, or one::foo?  In other words, a class, or for that matter, any item in a namespace, is invisible/hidden unless the namespace is named in a using directive, or is explicitly referenced with a :: (e.g. one::foo).  Correct?

Thanks again!

James, was able to verify the accuracy of everything that you said.

Thank you very much; it really helped clarify the issues.