I am looking for a tool that can scan my soyrce code and check if a
header file gets included more then once in a sequece of compiled code.
Can some one guide me to such a tool !!

Hi,
Multiple inclusion can be easily avoided by inserting Inclusion
guards on each headefiles. Follow it while creating any header file.
Then you need not have to worry about the multiple inclusion problem. I
will give an example for inclusion guard.

If your header is somthing like Reader.h, in Reader.h you write,

#ifndef _READER_H_
#define _READER_H_

// Put your complete header code here

// And at the end you put,
#endif //_READER_H_ ends here.

Now there cannot be multiple inclusions. Because when you include
Reader.h first time "_READER_H_" gets defined and the file gets
included. But when you try to include it again "_READER_H_" is already
defined and so the Reader.h will not be included.

Best regards,
Amal P.

Amal P wrote:[color=blue]
> If your header is somthing like Reader.h, in Reader.h you write,
>
> #ifndef _READER_H_
> #define _READER_H_
>
> // Put your complete header code here
>
> // And at the end you put,
> #endif //_READER_H_ ends here.[/color]

Just a small nit: names that start with an underscore followed by an
uppercase letter are reserved for the implementation. You should not
use them in your own code. So READER_H_ would be a better choice.

Gavin Deane

Hi Gavin,
Well its not like that. It's just some programming style. You can
actually use these names. There are a few other places where these kind
of names are used. Suppose i am building a big library and I want
others to use it. There I declare names starting with underscore and
write it to mean that is my system (The whole software as it is). The
most convenient way that I found out is you keep your own name n number
for this. So lets say you have <Some-File-Name>.h is the file. So
please take this name and give
#ifndef _<Some-file-name><DATE stamp><Time stamp>
Or something like that.

[replying to a statement that names starting with an underscore
followed by a capital letter...]
Student wrote:[color=blue]
> Well its not like that. It's just some programming style.[/color]

False. I can back-up the claim that names starting with an underscore
followed by a capital letter are reserved in all contexts for the
standard C++ library implementation quoting the standard:

17.4.3.1 (lib.reserved.names), paragraph 3:
If the program declares or defines a name in a context where it
is reserved, other than as explicitly allowed by this clause, the
behavior is undefined.

17.4.3.1.2 (lib.global.names), paragraph 1, first bullet:
Each name that contains a double underscore ("__") or begins with
an underscore followed by an uppercase letter (lex.key) is
reserved to the implementation for any use.

Your turn!
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence

Please quote some context. From Google Groups, don't use the Reply link
at the bottom of the message, click on Show Options at the top of the
message and use the Reply link revealed there. I wrote:

Just a small nit: names that start with an underscore followed by an
uppercase letter are reserved for the implementation. You should not
use them in your own code. So READER_H_ would be a better choice.

Student wrote:[color=blue]
> Hi Gavin,
> Well its not like that.[/color]

It is.
[color=blue]
> It's just some programming style.[/color]

It's not.
[color=blue]
> You can actually use these names.[/color]

You *can*, and you may get away with no problems. I said you *should
not*. The language standard agrees with me.

17.4.3.1.2
Certain sets of names and function signatures are always reserved to
the implementation:
- Each name that contains a double underscore (_ _) or begins with an
underscore followed by an uppercase letter is reserved to the
implementation for any use.
- Each name that begins with an underscore is reserved to the
implementation for use as a name in the global namespace.

As I said, this is a relatively minor point. But once you know them,
the rules are very simple and help ensure that you will not have name
clashes with the implementation.
[color=blue]
> There are a few other places where these kind
> of names are used. Suppose i am building a big library and I want
> others to use it. There I declare names starting with underscore and
> write it to mean that is my system (The whole software as it is).[/color]

What happens if my program uses your library and someone else's library
too, and you have both used that naming convention? Why not just put
your library in its own namespace?
[color=blue]
> The most convenient way that I found out is you keep your own name n number
> for this. So lets say you have <Some-File-Name>.h is the file. So
> please take this name and give
> #ifndef _<Some-file-name><DATE stamp><Time stamp>
> Or something like that.[/color]

Something like that, yes - just without the leading underscore.

Gavin Deane

Gavin Deane wrote:[color=blue]
> Please quote some context. From Google Groups, don't use the Reply link
> at the bottom of the message, click on Show Options at the top of the
> message and use the Reply link revealed there. I wrote:
>
> Just a small nit: names that start with an underscore followed by an
> uppercase letter are reserved for the implementation. You should not
> use them in your own code. So READER_H_ would be a better choice.
>
> Student wrote:[color=green]
> > You can actually use these names.[/color]
>
> You *can*, and you may get away with no problems. I said you *should
> not*. The language standard agrees with me.[/color]

Actually, the standard is stronger than that. See Dietmar Kuehl's post.
Using reserved names is undefined behaviour 17.4.3.1/3. So as with all
undefined behaviour, if you choose to rely on it, all bets are off.

To repeat from my previous post:[color=blue]
> As I said, this is a relatively minor point. But once you know them,
> the rules are very simple and help ensure that you will not have name
> clashes with the implementation.[/color]
.... and that you will avoid undefined behaviour.

Gavin Deane