473,326 Members | 2,173 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

Namespace and #Include best practises

I am currently cleaning up an application which was origainlly hashed
together with speed of coding in mind and therefore contains quite a few
"hacky" shortcuts.

As part of this "revamping" process I am introducing namespaces to
properly compartmentalise sections of the code into logical units. What
I am speciffically trying to get right is the dependency tree for header
files to reduce compile time and simplify the code structure.

On this subject I have a few "best practise" questions:

1) I realise that the whole point of a .h file is to keep the interface
separate from the implementation. What I would like to understand better
is exaclty what one should normally place in header files and if there
are exceptions.

More specifically where should you place includes of system headers and
system namespaces? Should these normally go in the .h or the .cpp file?
Sometimes (i.e. when you are using templates) you need to put
implementation code in the header file. This implplementation is then
included in everything that references that header. If the file is used
lots, and/or many files cross-reference each other then the compilation
process is going to become slower and more complicated. Therefore header
files should reference each other as little as possible????

Are there any good internet articles on this subject (and on the other
things in this post)?

2) What is best practise when classes are interdependent and in
different .h files? (Is adding 'class Class2;' the best way?):

In class1.h:
----------------------
#include "class2.h"

class Class2; // How does it work internally in the compiler? I read
somewhere that there is there any runtime penatly for this, but I cant
see why this would be so. Is there any penalty?

class Class1
{
private:
Class2 m_C2;
};
----------------------

In class2.h:
----------------------
#include "class1.h"

class Class1;

class Class2
{
private:
Class1 m_C2;
};
----------------------

3) Where should "using namespace" directievs go, in the .cpp file or in
the .h file?

Obviously compilation times are increased as interdependency inceases
between header files. Header files should be kept to a bare minimum in
what they include. Does adding a "using namsespace" to a header cause
extra compilation? or is its just effectively a set of default
namespaces in which to look for class names?

We have these classes:

in file ClassNS1.h
----------------------
namespace NS1
{
class Class1
{
};
}
----------------------

in file ClassNS2.h
----------------------
namespace NS2
{
class Class1
{
};
}
----------------------

Is there any fundamental difference between these in terms of the
compilation process:

in file invoke.h
----------------------
#include "ClassNS1.h"
using namespace NS1; // does this compile all of NS1 and include it
(i.e. big compile time penalty) ? or is this just a syntax shortcut
(i.e. no compile time penalty)?

class Invokation
{
public:
void Go();
private:
Class1 *m_Class1;
};
----------------------
in file invoke.cpp
#include "invoke.h"
void Invokation::Go()
{
m_Class1 = new Class1();
}

in main.cpp
----------------------
void main()
{
Invokation *iv = new Invokation();
iv->Go();
}
----------------------

OR THIS ??:

in file invoke.h
----------------------
#include "ClassNS1.h"
class Invokation
{
public:
void Go();
private:
NS1::Class1 *m_Class1;
};

in file invoke.cpp
#include "invoke.h"
void Invokation::Go()
{
m_Class1 = new Class1();
}
----------------------

in main.cpp
----------------------
void main()
{
Invokation *iv = new Invokation();
iv->Go();
}
----------------------
Many Thanks,
Jon Rea
Jan 30 '06 #1
14 6652
In article <It*******@bath.ac.uk>, Jon Rea <jo*****@bris.ac.uk> wrote:
I am currently cleaning up an application which was origainlly hashed
together with speed of coding in mind and therefore contains quite a few
"hacky" shortcuts.

As part of this "revamping" process I am introducing namespaces to
properly compartmentalise sections of the code into logical units. What
I am speciffically trying to get right is the dependency tree for header
files to reduce compile time and simplify the code structure.

On this subject I have a few "best practise" questions:

1) I realise that the whole point of a .h file is to keep the interface
separate from the implementation. What I would like to understand better
is exaclty what one should normally place in header files and if there
are exceptions.
From [Stroustrup]:

As a rule of thumb, a header may contain:

Named namespaces namespace N { /*...*/ }
Type definitions struct Point { int x, y; };
Template declarations template<class T> class Z;
Template definitions template<class T> class V { /*...*/ };
Function declarations extern int strlen(const char*);
Inline function definitions inline char get(char* p) {return *p++;}
Data declarations extern int a;
Constant definitions const float pi = 3.141593;
Enumerations enum Light { red, yellow, green };
Named declarations class Matrix;
Include directives #include <algorithm>
Macro definitions #define VERSION 12
Conditional compliations directives #ifdef __cplusplus
Comments /* check for end of file */
More specifically where should you place includes of system headers and
system namespaces? Should these normally go in the .h or the .cpp file?
Put includes in the .cpp file when you can, in the .h file when you must.
Sometimes (i.e. when you are using templates) you need to put
implementation code in the header file. This implplementation is then
included in everything that references that header. If the file is used
lots, and/or many files cross-reference each other then the compilation
process is going to become slower and more complicated. Therefore header
files should reference each other as little as possible????
Yes.
2) What is best practise when classes are interdependent and in
different .h files? (Is adding 'class Class2;' the best way?):

In class1.h:
----------------------
#include "class2.h"

class Class2; // How does it work internally in the compiler? I read
somewhere that there is there any runtime penatly for this, but I cant
see why this would be so. Is there any penalty?

class Class1
{
private:
Class2 m_C2;
};
----------------------

In class2.h:
----------------------
#include "class1.h"

class Class1;

class Class2
{
private:
Class1 m_C2;
};
----------------------
You can't do the above. You have created an infinite sized object (a
Class1 contains a Class2 which contains a Class1 ad infinitum.)

One of the two classes above must contain a pointer instead. The one
that contains a pointer should have a named declaration in it for the
other class, and that class' header should only be included in the cpp
file.
3) Where should "using namespace" directievs go, in the .cpp file or in
the .h file?


Never in the .h file!

--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.
Jan 30 '06 #2

Jon Rea wrote:
I am currently cleaning up an application which was origainlly hashed
together with speed of coding in mind and therefore contains quite a few
"hacky" shortcuts.

As part of this "revamping" process I am introducing namespaces to
properly compartmentalise sections of the code into logical units. What
I am speciffically trying to get right is the dependency tree for header
files to reduce compile time and simplify the code structure.

On this subject I have a few "best practise" questions:

1) I realise that the whole point of a .h file is to keep the interface
separate from the implementation. What I would like to understand better
is exaclty what one should normally place in header files and if there
are exceptions.

More specifically where should you place includes of system headers and
system namespaces? Should these normally go in the .h or the .cpp file?
your header should include every other header it needs in order that it
can be compiled on its own, and no more. In other words

// header_test.cpp
#include "my_header.h"

This conceptual source file, which contains nothing but a single
#include, should compile successfully for every one of your headers.
Note that you can use forward declarations to reduce dependencies.
Sometimes (i.e. when you are using templates) you need to put
implementation code in the header file. This implplementation is then
included in everything that references that header. If the file is used
lots, and/or many files cross-reference each other then the compilation
process is going to become slower and more complicated. Therefore header
files should reference each other as little as possible????
Unless your compiler supports the export keyword, and you are happy to
sacrifice portability to all compilers that don't, you are stuck with
having template implementation code in the header.
Are there any good internet articles on this subject (and on the other
things in this post)?

2) What is best practise when classes are interdependent and in
different .h files? (Is adding 'class Class2;' the best way?):

In class1.h:
----------------------
#include "class2.h"

class Class2; // How does it work internally in the compiler? I read
somewhere that there is there any runtime penatly for this, but I cant
see why this would be so. Is there any penalty?

class Class1
{
private:
Class2 m_C2;
};
----------------------

In class2.h:
----------------------
#include "class1.h"

class Class1;

class Class2
{
private:
Class1 m_C2;
};
----------------------
Did you try and compile this? A forward declaration is the way to fix
this circular dependency problem. But you haven't gone far enough. Your
Class1 contains a Class2 member, which contains a Class1 member, which
contains a Class2 member, which contains .... and so on to infinity.
See the FAQ

http://www.parashift.com/c++-faq-lit...html#faq-39.11
3) Where should "using namespace" directievs go, in the .cpp file or in
the .h file?
using directives and using declarations should not go in headers. They
are convenience tools which are useful, however there is always a cost
to using them. That cost is namespace pollution. To a certain extent
using declarations and definitely using directives defeat the purpose
of having namespaces in the first place. Within your own code you can
always decide when you are prepared to accept that. If you put using
declarations and directives in the header, everyone who includes that
header, now and in the future, has that decision forced upon them
whether they like it or not.
Obviously compilation times are increased as interdependency inceases
between header files. Header files should be kept to a bare minimum in
what they include. Does adding a "using namsespace" to a header cause
extra compilation? or is its just effectively a set of default
namespaces in which to look for class names?
It won't add to compilation. It just forces namespace pollution on
every single user of the header, whether they like it or not.
We have these classes:

in file ClassNS1.h
----------------------
namespace NS1
{
class Class1
{
};
}
----------------------

in file ClassNS2.h
----------------------
namespace NS2
{
class Class1
{
};
}
----------------------

Is there any fundamental difference between these in terms of the
compilation process:

in file invoke.h
----------------------
#include "ClassNS1.h"
using namespace NS1; // does this compile all of NS1 and include it
(i.e. big compile time penalty) ? or is this just a syntax shortcut
(i.e. no compile time penalty)?
No compile time penalty. The using directive is not there to compile
the code, purely to give the compiler more information about where to
lookup names it encounters. But its use in a header is a bad idea as
discussed above.
class Invokation
{
public:
void Go();
private:
Class1 *m_Class1;
};
----------------------
in file invoke.cpp
#include "invoke.h"
void Invokation::Go()
{
m_Class1 = new Class1();
}

in main.cpp
----------------------
void main()
{
Invokation *iv = new Invokation();
iv->Go();
}
----------------------
Changing the subject for a moment, there are some style issues that you
may be well aware of but i'll mention anyway.

Go looks like it's doing work that should be in a constructor. Any
reason it can't be done in a constructor?
Any reason for creating iv dynamically?
There is no delete to match the new.
In standard C++ main returns int not void.

As I say, these points don't have anything to do with your question.
You may understand the issues perfectly well - this is example code
after all. But they are also all relatively common errors from
misunderstanding the language so I thought worth mentioning.
OR THIS ??:

in file invoke.h
----------------------
#include "ClassNS1.h"
class Invokation
{
public:
void Go();
private:
NS1::Class1 *m_Class1;
That's the way to do it in a header.
};

in file invoke.cpp
#include "invoke.h"
void Invokation::Go()
{
m_Class1 = new Class1();
Did you try and compile this? You've got rid of the using directive so
the compiler will not look inside namespace NS1 for the name Class1.
new NS1::Class1();
}
----------------------

in main.cpp
----------------------
void main()
{
Invokation *iv = new Invokation();
iv->Go();
}
----------------------


Gavin Deane

Jan 30 '06 #3
Thank you for your rapid reply, most helpful and ill follow that in the
future. I see your point about "namespace pollution", I just wanted to
make sure that explicitly defining things was indeed the way to go.

I was aware of the other things you have stated, the code that I posted
was uncompiled pseudo-code to illustrate my point. I guess I wrote it a
little too rapidly ;-).

Cheers,
Jon

Gavin Deane wrote:
Jon Rea wrote:
I am currently cleaning up an application which was origainlly hashed
together with speed of coding in mind and therefore contains quite a few
"hacky" shortcuts.

As part of this "revamping" process I am introducing namespaces to
properly compartmentalise sections of the code into logical units. What
I am speciffically trying to get right is the dependency tree for header
files to reduce compile time and simplify the code structure.

On this subject I have a few "best practise" questions:

1) I realise that the whole point of a .h file is to keep the interface
separate from the implementation. What I would like to understand better
is exaclty what one should normally place in header files and if there
are exceptions.

More specifically where should you place includes of system headers and
system namespaces? Should these normally go in the .h or the .cpp file?

your header should include every other header it needs in order that it
can be compiled on its own, and no more. In other words

// header_test.cpp
#include "my_header.h"

This conceptual source file, which contains nothing but a single
#include, should compile successfully for every one of your headers.
Note that you can use forward declarations to reduce dependencies.

Sometimes (i.e. when you are using templates) you need to put
implementation code in the header file. This implplementation is then
included in everything that references that header. If the file is used
lots, and/or many files cross-reference each other then the compilation
process is going to become slower and more complicated. Therefore header
files should reference each other as little as possible????

Unless your compiler supports the export keyword, and you are happy to
sacrifice portability to all compilers that don't, you are stuck with
having template implementation code in the header.

Are there any good internet articles on this subject (and on the other
things in this post)?

2) What is best practise when classes are interdependent and in
different .h files? (Is adding 'class Class2;' the best way?):

In class1.h:
----------------------
#include "class2.h"

class Class2; // How does it work internally in the compiler? I read
somewhere that there is there any runtime penatly for this, but I cant
see why this would be so. Is there any penalty?

class Class1
{
private:
Class2 m_C2;
};
----------------------

In class2.h:
----------------------
#include "class1.h"

class Class1;

class Class2
{
private:
Class1 m_C2;
};
----------------------

Did you try and compile this? A forward declaration is the way to fix
this circular dependency problem. But you haven't gone far enough. Your
Class1 contains a Class2 member, which contains a Class1 member, which
contains a Class2 member, which contains .... and so on to infinity.
See the FAQ

http://www.parashift.com/c++-faq-lit...html#faq-39.11

3) Where should "using namespace" directievs go, in the .cpp file or in
the .h file?

using directives and using declarations should not go in headers. They
are convenience tools which are useful, however there is always a cost
to using them. That cost is namespace pollution. To a certain extent
using declarations and definitely using directives defeat the purpose
of having namespaces in the first place. Within your own code you can
always decide when you are prepared to accept that. If you put using
declarations and directives in the header, everyone who includes that
header, now and in the future, has that decision forced upon them
whether they like it or not.

Obviously compilation times are increased as interdependency inceases
between header files. Header files should be kept to a bare minimum in
what they include. Does adding a "using namsespace" to a header cause
extra compilation? or is its just effectively a set of default
namespaces in which to look for class names?

It won't add to compilation. It just forces namespace pollution on
every single user of the header, whether they like it or not.

We have these classes:

in file ClassNS1.h
----------------------
namespace NS1
{
class Class1
{
};
}
----------------------

in file ClassNS2.h
----------------------
namespace NS2
{
class Class1
{
};
}
----------------------

Is there any fundamental difference between these in terms of the
compilation process:

in file invoke.h
----------------------
#include "ClassNS1.h"
using namespace NS1; // does this compile all of NS1 and include it
(i.e. big compile time penalty) ? or is this just a syntax shortcut
(i.e. no compile time penalty)?

No compile time penalty. The using directive is not there to compile
the code, purely to give the compiler more information about where to
lookup names it encounters. But its use in a header is a bad idea as
discussed above.

class Invokation
{
public:
void Go();
private:
Class1 *m_Class1;
};
----------------------
in file invoke.cpp
#include "invoke.h"
void Invokation::Go()
{
m_Class1 = new Class1();
}

in main.cpp
----------------------
void main()
{
Invokation *iv = new Invokation();
iv->Go();
}
----------------------

Changing the subject for a moment, there are some style issues that you
may be well aware of but i'll mention anyway.

Go looks like it's doing work that should be in a constructor. Any
reason it can't be done in a constructor?
Any reason for creating iv dynamically?
There is no delete to match the new.
In standard C++ main returns int not void.

As I say, these points don't have anything to do with your question.
You may understand the issues perfectly well - this is example code
after all. But they are also all relatively common errors from
misunderstanding the language so I thought worth mentioning.

OR THIS ??:

in file invoke.h
----------------------
#include "ClassNS1.h"
class Invokation
{
public:
void Go();
private:
NS1::Class1 *m_Class1;

That's the way to do it in a header.

};

in file invoke.cpp
#include "invoke.h"
void Invokation::Go()
{
m_Class1 = new Class1();

Did you try and compile this? You've got rid of the using directive so
the compiler will not look inside namespace NS1 for the name Class1.
new NS1::Class1();

}
----------------------

in main.cpp
----------------------
void main()
{
Invokation *iv = new Invokation();
iv->Go();
}
----------------------

Gavin Deane

Jan 30 '06 #4
Hi
just as a small followup Question: How do precompiled headers fit into all
this? Which files should include the precompiled header? Which files should
be included inside the precompiled header? Are there any other guidelines to
using them ? ( Like use of #pragma hdrstop ? )

Thanks in advance
Jan 30 '06 #5

Frank Neuhaus wrote:
Hi
just as a small followup Question: How do precompiled headers fit into all
this? Which files should include the precompiled header? Which files should
be included inside the precompiled header? Are there any other guidelines to
using them ? ( Like use of #pragma hdrstop ? )


Precompiled headers is not a standard C++ concept. How they work is
down to your particular implementation. You're probably better off
asking a group specific to your compiler.

Gavin Deane

Jan 31 '06 #6
A few rules about header file include management can be found at:

http://www.eventhelix.com/RealtimeMa...dePatterns.htm

--
EventStudio System Designer 2.5 - http://www.EventHelix.com/EventStudio
Sequence Diagram Based Systems Engineering and Object Modeling Tool

Jan 31 '06 #7
Jon Rea wrote:
I am currently cleaning up an application which was origainlly hashed
together with speed of coding in mind and therefore contains quite a few
"hacky" shortcuts.
Did this. Do not envy you.
As part of this "revamping" process I am introducing namespaces to
properly compartmentalise sections of the code into logical units. What
I am speciffically trying to get right is the dependency tree for header
files to reduce compile time and simplify the code structure.

On this subject I have a few "best practise" questions: 3) Where should "using namespace" directievs go, in the .cpp file or in
the .h file?

Obviously compilation times are increased as interdependency inceases
between header files. Header files should be kept to a bare minimum in
what they include. Does adding a "using namsespace" to a header cause
extra compilation? or is its just effectively a set of default
namespaces in which to look for class names?


The using directive affects only lookup. Never runtime. The impact on
compilation time should not be noticible.

Besides
using namespace uff;
You can also use
using uff::Class;
to bring some specific class into scope.

*Never* *ever* use 'using' in a header file. (Using it _inside_ a class
declaration is a different beast, thats not what I mean here). I'll
explain: Namespaces exist so the client has to explicitly say what
'logical unit' he wants to use. It avoids name-clashes. Example: sort.
With namespaces, std::sort, my_things::sort, some_lib::sort can coexist
peacefully. A client needs to be explicit about which one he wants to
use. He doesn't even need to know about every one of them. If he uses
std::sort it's still unique. If you wrote
using namespace my_things;
in some header, the client might (indirectly) include it and might not
be aware of it. If the client then writes
using namespace std;
you have a name-clash. Worse yet, if he _thinks_ he wrote "using
namespace std" and actually forgot about it, he is in trouble because he
will use my_things::sort but thinks he is using std::sort.

To sum up, with this using directive, you shuffle the carefully sorted
things all back into the big bowl and invalidate the 'logical units' you
just build.

In source files the using directive is of course a different matter
because here it does not propagate into unknown code of unknown users.
There it can be a valid choice.

Gabriel

--
Who is General Failure and why is he reading my hard disk?
Jan 31 '06 #8
Hello all,
I have a follow-up question. I have doubts when we use the combinations
of the following 3 statements:-
using namespace std;
#include <iostream.h>
#include <iostream>

I wrote the following sample code:-
Case 1:-
--------------------
using namespace std;
#include <iostream.h>
#include <iostream>
int main()
{
cout<<"Hello world";
return 0;
}
-------On Compiling--------
bash-2.03# xlC namespace.cpp
"namespace.cpp", line 6.9: 1540-0600 (S) The reference to "cout" is
ambiguous.
"/usr/vacpp/include/iostream", line 73.28: 1540-0424 (I) "std::cout" is
declared on line 73 of "/usr/vacpp/include/iostream".
"/usr/vacpp/include/iostream.h", line 918.27: 1540-0424 (I) "cout" is
declared on line 918 of "/usr/vacpp/include/iostream.h".

Case 2:-
-----------------
using namespace std;
#include <iostream.h>
#include <iostream>
int main()
{
/*cout<<"Hello world";*/
return 0;
}
-------On Compiling--------
bash-2.03# xlC namespace.cpp
bash-2.03#

Case 3:-
-----------------
using namespace std;
#include <iostream>
#include <iostream.h>
int main()
{
/*cout<<"Hello world";*/
return 0;
}
-------On Compiling--------
bash-2.03# xlC namespace.cpp
"/usr/vacpp/include/iostream.h", line 114.38: 1540-0063 (S) The text
"*" is unexpected.
"/usr/vacpp/include/iostream.h", line 300.25: 1540-0040 (S) The text
"seekoff" is unexpected. "streampos" may be undeclared or ambiguous.
"/usr/vacpp/include/iostream.h", line 443.32: 1540-0600 (S) The
reference to "ios" is ambiguous.
"/usr/vacpp/include/iostream.h", line 78.7: 1540-0425 (I) "ios" is
defined on line 78 of "/usr/vacpp/include/iostream.h".
"/usr/vacpp/include/iosfwd", line 330.45: 1540-0425 (I) "std::ios" is
defined on line 330 of "/usr/vacpp/include/iosfwd".
"/usr/vacpp/include/iostream.h", line 692.32: 1540-0600 (S) The
reference to "ios" is ambiguous.
"/usr/vacpp/include/iostream.h", line 78.7: 1540-0425 (I) "ios" is
defined on line 78 of "/usr/vacpp/include/iostream.h".
"/usr/vacpp/include/iosfwd", line 330.45: 1540-0425 (I) "std::ios" is
defined on line 330 of "/usr/vacpp/include/iosfwd".
<<<--and lot of similar errors-->>>

Please note that I have deliberately included both iostream and
iostream.h headers in this sample program, as this kind of thing is
happening indirectly in my application.

Kindly explain this kind of behaviour and suggest possible practices to
avoid such errors.

Thanks,
Anunay

Feb 1 '06 #9
Anunay wrote:
Hello all,
I have a follow-up question. I have doubts when we use the combinations
of the following 3 statements:-
using namespace std;
#include <iostream.h>
#include <iostream>

I wrote the following sample code:-
Case 1:-
--------------------
using namespace std;
#include <iostream.h>
#include <iostream>
int main()
{
cout<<"Hello world";
return 0;
}
-------On Compiling--------
bash-2.03# xlC namespace.cpp
"namespace.cpp", line 6.9: 1540-0600 (S) The reference to "cout" is
ambiguous.
"/usr/vacpp/include/iostream", line 73.28: 1540-0424 (I) "std::cout" is
declared on line 73 of "/usr/vacpp/include/iostream".
"/usr/vacpp/include/iostream.h", line 918.27: 1540-0424 (I) "cout" is
declared on line 918 of "/usr/vacpp/include/iostream.h".

Case 2:-
-----------------
using namespace std;
#include <iostream.h>
#include <iostream>
int main()
{
/*cout<<"Hello world";*/
return 0;
}
-------On Compiling--------
bash-2.03# xlC namespace.cpp
bash-2.03#

Case 3:-
-----------------
using namespace std;
#include <iostream>
#include <iostream.h>
int main()
{
/*cout<<"Hello world";*/
return 0;
}
-------On Compiling--------
bash-2.03# xlC namespace.cpp
"/usr/vacpp/include/iostream.h", line 114.38: 1540-0063 (S) The text
"*" is unexpected.
"/usr/vacpp/include/iostream.h", line 300.25: 1540-0040 (S) The text
"seekoff" is unexpected. "streampos" may be undeclared or ambiguous.
"/usr/vacpp/include/iostream.h", line 443.32: 1540-0600 (S) The
reference to "ios" is ambiguous.
"/usr/vacpp/include/iostream.h", line 78.7: 1540-0425 (I) "ios" is
defined on line 78 of "/usr/vacpp/include/iostream.h".
"/usr/vacpp/include/iosfwd", line 330.45: 1540-0425 (I) "std::ios" is
defined on line 330 of "/usr/vacpp/include/iosfwd".
"/usr/vacpp/include/iostream.h", line 692.32: 1540-0600 (S) The
reference to "ios" is ambiguous.
"/usr/vacpp/include/iostream.h", line 78.7: 1540-0425 (I) "ios" is
defined on line 78 of "/usr/vacpp/include/iostream.h".
"/usr/vacpp/include/iosfwd", line 330.45: 1540-0425 (I) "std::ios" is
defined on line 330 of "/usr/vacpp/include/iosfwd".
<<<--and lot of similar errors-->>>

Please note that I have deliberately included both iostream and
iostream.h headers in this sample program, as this kind of thing is
happening indirectly in my application.

Kindly explain this kind of behaviour and suggest possible practices to
avoid such errors.

Thanks,
Anunay


<iostream.h> is deprecated. So are all <standard_header_name.h>. I
couldn't think of a reason right now to use them. Why would you use
them, and what compiler/stl implementation do you use?

Anyway, if you *have* to use them, then you should stay away from 'using
namespace std'. Just say what you need in your code: cout or std::cout.

Gabriel

--
Who is General Failure and why is he reading my hard disk?
Feb 1 '06 #10

Gabriel wrote:
<iostream.h> is deprecated. So are all <standard_header_name.h>. I
couldn't think of a reason right now to use them. Why would you use
them, and what compiler/stl implementation do you use?


<iostream.h> is not deprecated. It is not and never has been standard.
It is a pre-standard header that many implementations provided before
C++ was standardised. But since <iostream.h> itself has never been
standardised, you can't rely on different implementations that do
provide it actually providing identical functionality.

The only deprecated <xxx.h> headers are only those inherited from the C
library and they are deprecated in favour of the corresponding <cxxx>
headers, which are supposed to put all the names in namespace std
(although a lot of implementations incorrectly leave the names in the
global namespace too, which is enough for me to question their
utility).

So if your implementation provides, for example, <fstream.h>, that is
not deprecated. It's another pre-standard header that you can't rely on
being portable.

Gavin Deane

Feb 1 '06 #11
> <iostream.h> is deprecated. So are all <standard_header_name.h>. I
couldn't think of a reason right now to use them. Why would you use
them, and what compiler/stl implementation do you use?


Am using AIX xlC compiler (VisualAge C++ 6.0)
I am having a similar situation in my application which i have
reproduced here in this sample program. Is there a way to prevent the
errors of Case 3?

Feb 1 '06 #12

Jon Rea wrote:
I am currently cleaning up an application which was origainlly hashed
together with speed of coding in mind and therefore contains quite a few
"hacky" shortcuts.

As part of this "revamping" process I am introducing namespaces to
properly compartmentalise sections of the code into logical units. What
I am speciffically trying to get right is the dependency tree for header
files to reduce compile time and simplify the code structure.

On this subject I have a few "best practise" questions:

1) I realise that the whole point of a .h file is to keep the interface
separate from the implementation. What I would like to understand better
is exaclty what one should normally place in header files and if there
are exceptions.

More specifically where should you place includes of system headers and
system namespaces? Should these normally go in the .h or the .cpp file?
Sometimes (i.e. when you are using templates) you need to put
implementation code in the header file. This implplementation is then
included in everything that references that header. If the file is used
lots, and/or many files cross-reference each other then the compilation
process is going to become slower and more complicated. Therefore header
files should reference each other as little as possible????

Are there any good internet articles on this subject (and on the other
things in this post)?

2) What is best practise when classes are interdependent and in
different .h files? (Is adding 'class Class2;' the best way?):
Lakos '96 provides all the answers to these questions.
3) Where should "using namespace" directievs go, in the .cpp file or in
the .h file?


You should never have 'using namespace' declarations. At the very most,
you may consider, for example, 'using std::cout', but otherwise, you
should always use full scoping syntax.

Feb 1 '06 #13

Anunay wrote:
<iostream.h> is deprecated. So are all <standard_header_name.h>. I
couldn't think of a reason right now to use them. Why would you use
them, and what compiler/stl implementation do you use?


Am using AIX xlC compiler (VisualAge C++ 6.0)
I am having a similar situation in my application which i have
reproduced here in this sample program. Is there a way to prevent the
errors of Case 3?


Yes. Don't mix standard C++ I/O from <iostream> with the pre- or
non-standard I/O your implementation provides in <iostream.h>. Pick one
or the other, preferably the standard one, and stick to it.

Gavin Deane

Feb 1 '06 #14
da********@warpmail.net wrote:
Jon Rea wrote:
I am currently cleaning up an application which was origainlly hashed
together with speed of coding in mind and therefore contains quite a few
"hacky" shortcuts.

As part of this "revamping" process I am introducing namespaces to
properly compartmentalise sections of the code into logical units. What
I am speciffically trying to get right is the dependency tree for header
files to reduce compile time and simplify the code structure.

On this subject I have a few "best practise" questions:

1) I realise that the whole point of a .h file is to keep the interface
separate from the implementation. What I would like to understand better
is exaclty what one should normally place in header files and if there
are exceptions.

More specifically where should you place includes of system headers and
system namespaces? Should these normally go in the .h or the .cpp file?
Sometimes (i.e. when you are using templates) you need to put
implementation code in the header file. This implplementation is then
included in everything that references that header. If the file is used
lots, and/or many files cross-reference each other then the compilation
process is going to become slower and more complicated. Therefore header
files should reference each other as little as possible????

Are there any good internet articles on this subject (and on the other
things in this post)?

2) What is best practise when classes are interdependent and in
different .h files? (Is adding 'class Class2;' the best way?):


Lakos '96 provides all the answers to these questions.
3) Where should "using namespace" directievs go, in the .cpp file or in
the .h file?


You should never have 'using namespace' declarations. At the very most,
you may consider, for example, 'using std::cout', but otherwise, you
should always use full scoping syntax.


I sometimes do in my source files. I think thats OK, especially if I use
not more than one namespace this way. What reason do you see for always
using fill scoping syntax/only using particular classes/functions?

Gabriel

--
Who is General Failure and why is he reading my hard disk?
Feb 1 '06 #15

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: Agent Mulder | last post by:
I have problems moving my project into a seperate namespace. Namespace introduces its own level of bugs. #include <iostream.h> class Fury{};//comment this out and it compiles namespace Green...
8
by: Douglas | last post by:
**** Post for FREE via your newsreader at post.usenet.com **** Hello, The following code does not compile if line 3 is uncommented "using namespace std". I do not understand it. Could...
2
by: puzzlecracker | last post by:
after reading some of the post I found out something rather radical to my previous understanding: that when you do #include<iostream> #include<string> #include<vector> etc compiler puts...
10
by: Christian Christmann | last post by:
Hi, are there any drawbacks using "using namespace std" instead of defining the required namespaces like using std::cout
7
by: Kai-Uwe Bux | last post by:
Hi folks, I observed something that puzzles me. When I do namespace xxx { using std::swap; } it appears that xxx::swap and std::swap are not strictly equivalent. In particular, I think...
2
by: Roman Mashak | last post by:
Hello, All! I wonder are there any typical, common used practises to organize all #include's in the large/medium size project. Try to explain what I mean: suppose I have three tranlsation units...
1
by: DelphiLover | last post by:
Hi. I'm reading and reading, testing and testing, trying to figure out how to do things, how to do things according to best practises and how to do things in the best object oriented way. ...
5
by: michael.d.pedersen | last post by:
Hello group, I am new to Visual C++ 8 and have a seemingly trivial problem using namespaces. The scenario: I have two classes, TestClass1 and TestClass2, in the namespace Test. I would like to...
4
by: Hua.watson | last post by:
I want to add some declaration intio my namespace. But I do not have the right to modify proto header files. So I try namespace mynamespace{ #include "a.h" #include "b.h" }
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.