Document :: Namespaces
Author :: Kris Erickson
From  The Bits... the c++ Builder Information & Tutorial Site
http://www.cbuilder.dthomas.co.uk
Contact :
Main Site : [e-mail]
Newspages : [e-mail]
Comments : [e-mail]
Editors:
Components : Alan D. Mills, [e-mail]
Tutorials : Kris Erickson, [e-mail]
Others bits: Jon Jenkinson, [e-mail]
Legal Stuff
This document is Copyright © Jon Jenkinson, December 1997
The PDF distribution release of this document is Copyright ©"The Bits... , December 1997
You Can,
Redistribute this file FREE OF CHARGE providing you do not charge recipients anything
for the
process of redistribution, or for the document itself.
You Can,
Use this document for educational purposes.
You Must Gain Permission, *Initial contact [e-mail]*
If you choose to redistribute this document in any way, (book/CD/Magazine/Web Site
etc.). (note, this is to avoid any possible conflict with commercial work the author may
be undertaking, though it is unlikely permission will be refused).
You Must Gain Permission, *Initial contact [e-mail]*
If you wish to use all or part of this document for commercial training purposes.
You Cannot,
Under any circumstances alter this document in any way without the express permission
of the author or  The Bits... .
You Cannot,
Receive **any** monies for this document without the prior consent of the author.
You Cannot,
Take any of the ideas presented here and produce a product for distribution without the
express consent of the author.
In plain words, if you wish to do anything other than read and print this document for you own
individual use, let us know so we can track what s going on:)
No liability is accepted by the author(s) for anything which may occur whilst following
this tutorial
Programming In the Large
This is the first in a planned series of articles on Programming in the Large. One of
the knocks against C++ Builder (and Delphi for that matter), is that it does not lend itself to
programming large projects. While I agree that the organization of projects with the program
manager leaves a lot to be desired (hopefully this will change with C++ Builder 3.0 - as it will be
called) and the pre-compiled headers will KILL your hard-drive in a large project (a recent project
I compeleted had something like 60 modules, and generated 200+ megs of pre-compiled header
files - - Kris s Tip #1 - if you have a project with lots of files, turn off pre-compiled headers).
However, I disagree that the component model itself is a poor choice for programming in the
Large. However, you have to approach programs with a different methodology than you do with
smaller programs.
Before I begin this entire series, I must admit that I am not an expert in programming in
the large, but it is a field that interests me. The largest project that I have had anything to do
with clocked in at just under 50 kloc s (fifty thousand lines of code), and (probably fortunately) I
have had nothing to do with it s maintenance so I am unsure how successful the project has
turned out to be. The first thing that any first year computer science student learns is that
maintenance of a program takes 80% of the labour of the life of any project, however, in
University you never are forced to maintain a project, so the coding practices that the instructors
attempt to instill in you hardly seems relevant until later in one s professional career. But, even if
you have never had to maintain a program, but just wanted to change something you wrote
several months before you can understand how poor coding practices can make future updates
very difficult.
This is especially true with programs written in C++ Builder that are quick one-off s. I
assume that everyone has written one these (they are one of the great joys of C++ Builder, the
ability to quickly make utilities that you need), where no planning goes into them before starting
to code. They start of as a simple user interface, with just a few lines of code, and quickly
mushroom into a thousand lines of code all in one file. Some major changes need to be made,
several months later, and what made sense while you where coding it, looks like a horendous
mess now. You spend half your time hitting ctrl-f to find the routines that are being called - and
then eventually you end up printing out the entire source code to figure out just what is going on.
Anyhow, this is what these series of tutorials is intended to put an end to, monolithic single file
programs. They are the reason it is difficult to code large programs in C++ Builder, however due
to the nature of Builder (all your code for a single form really has to be in one file) they are the
types of programs that Builder tends to evolve without strategic planning.
Anyhow, my opening rant has gone on for long enough, it is time to get to the issue at
hand, and that is Namespaces.
Namespaces
Probably the first issue to address here is what exactly are  namespaces. When I first
looked into Namespaces, I looked at the help in Bulider and was totally confused. It didn t really
help me out until I had done a little more research into Namespaces. Hopefully this brief
introduction will allow you to figure out just what namespaces are, what they are for, and allow
you to make sense of the help in Borland C++ Builder.
Namespaces is a way to allow a C++ compiler divides large multifile programs without
re-definition of classes, structs, variables or functions. Initially in C++ there was only one
 namespace , the global namespace, and everything that was included in a project was part of
that global namespace. The only way that one could protect functions from naming clashes was
to place them inside of a structure (or class), or try to create wierd names for your functions.
Perhaps this is best explained by a quick example:
// File1.h
void foo(void);
void bar(void);
....
// File2.h
void foo(void);
void fum(void);
....
// Main File
#include  file1.h
#include  file2.h
int main(void)
{
...
}
If this was a complete program (and the header files also had implimentation files), and you
compiled it, you would have a multiple definition error (remember you can declare a function or
class as many times as you want (if it has the same profile) but you can only define it once). A
technique that used to be used for getting rid of these problems was to place all your related
functions in a struct...
// File1.h
struct File1FunctionHolder
{
void foo(void);
void bar(void);
...
}
// File2.h
stuct File2FunctionHolder
{
void foo(void);
void fum(void);
...
}
// Main file
#include  file1.h
#include  file2.h
int main(void)
{
...
}
Voila, problem solved! (Sort of) However, what happens when you have two classes (or
structures) that have the same name?
// File1.h
class string
{
....
}
class something
{
private:
string S1,S2,S3;
...
}
// File2.h
class string
{
...
}
class nothing
{
private:
string nString1, nString2;
...
}
// File Main
#include  File1.h
#include  File2.h
int main(void)
{
...
}
Oh no, more compile time errors! And how many modules do you know that have their own
String class (for example). I know C++ Builder comes with 2, the AnsiString (which can be
abbreviated to String), and the the STL string class. Well, eventually those who look after the
C++ Language got together and decided that the best way to solve the problem was to create
namespaces. So now, if we have two modules that use a string class
// File1.h
namespace FILE1
{
class string
{
....
}
class something
{
private:
string S1,S2,S3;
...
}
}
// File2.h
namespace FILE2
{
class string
{
...
}
class nothing
{
 private:
string nString1, nString2;
...
}
}
// File Main
#include  File1.h
#include  File2.h
int main(void)
{
...
}
Now the two string classes don t cause multiple definitions since they each string class is
contained within their own namespaces, which is seperate from the global namespace. In fact
the way that compiler views the classes, there is no longer two classes called string, but a class
called FILE1::string and a class called FILE2::string. In fact, if you wanted to use either string
class in your main program, that is how you would identify them. For example, assume that
FILE1::string had a string reverse function that you wanted, and FILE2::string had a hashing
function that you needed (but didn t have the reverse feature you wanted), here is how you might
use them:
// File Main
#include  File1.h
#include  File2.h
int main(void)
{
FILE1::string String1, String2;
FILE2::string String3, String4;
String1 =  able was I ere I saw elba ;
String2 = String1.reverse();
if (String1 != String2)
{
cout <<  FILE1::string Reverse does not work! ;
}
else
{
cout <<  FILE1::string Reverse does not work! ;
}
String3 =  Hash this ;
String4 = String3.hash();
}
All right, it is probably not going to be too common of a situation when you actually will want to
do that, but if you wanted to that is how you could access two different classes with the same
name in the same program.
More frequently you are going to want to protect all your classes that you make with their
own namespaces, and then get access to functions and classes in that namespace. If you are
creating classes that you will re-use it is always a good idea to wrap them in their own
namespace. To use those classes, functions, etc, that have been protected in their own
namespace without specifically using the scope resolution operator you can can use the using
directive. For example, if we only wanted to the the String class from FILE1 we could go:
// File Main
#include  File1.h
#include  File2.h
using namespace FILE1
int main(void)
{
string S1,S2,S3;
...
}
And the program would use the string class from file1. What happens if you say:
using namespace FILE1;
using namespace FILE2;
Will there be a conflict? The answer is a qualified "no". There will not be a conflict until you try
to actually use string. The using directive doesn't add any names to the scope, but simply
makes them available.
There is a lot more that can be convered on namespaces, however, I feel that once you have
this introduction you should be able to make sense of the help that comes with C++ Builder on
namespaces. (Try compiling some of their examples to get a feel for how the namespaces are
working.)
Up Next: The Class, Model, View paradigm...
No liability is accepted by the author(s) for anything which may occur whilst following
this tutorial