problems with .h files

[puzzlecracker]

can someone explain why
int k; canNOT be definied in .h file?

what are general rules for what can/cannot be placed in .h file. FAQ
doesn't seem to address this problem.

[davidrubin]

See Lakos ;-)

[puzzlecracker]

[e-mail] wrote:

See Lakos ;-)

I have been interviewed by him not so long ago.. i.e. forgot to ask
this question. but he is probably expensive for private consultations,
I would assume!

suggest something more within the scope of this group or ballpark me
through an explanation.
thanks

[Andrey Tarasevich]

puzzlecracker wrote:

can someone explain why

int k; canNOT be definied in .h file?
The purpose of header files is to be '#include'd into several
translation units. If you place a definition of an object with external
linkage in header file, you'll sooner or later end up with several
definitions of this object in the program. This is a violation of ODR
(One Definition Rule) normally resulting in compilation error (at
linking stage). That's why such definition cannot be placed into header
file.
what are general rules for what can/cannot be placed in .h file.

H-files are for non-defining declarations and for certain kinds of
definitions. Namely, class definitions, template definitions, inline
function definitions, typename definitions can/should be placed into
header files. Entities with static linkage can also be defined in header
files, if for some reason you need to do so. Everything else (unless I
missed something) should only be _declared_ (as opposed to _defined_) in
header files.

--
Best regards,
Andrey Tarasevich

[puzzlecracker]

Andrey Tarasevich wrote:

puzzlecracker wrote:

can someone explain why

int k; canNOT be definied in .h file?
The purpose of header files is to be '#include'd into several
translation units. If you place a definition of an object with

external linkage in header file, you'll sooner or later end up with several
definitions of this object in the program. This is a violation of ODR
(One Definition Rule) normally resulting in compilation error (at
linking stage). That's why such definition cannot be placed into header file.

what are general rules for what can/cannot be placed in .h file.
H-files are for non-defining declarations and for certain kinds of
definitions. Namely, class definitions, template definitions, inline
function definitions, typename definitions can/should be placed into
header files. Entities with static linkage can also be defined in

header files, if for some reason you need to do so. Everything else (unless I missed something) should only be _declared_ (as opposed to _defined_) in header files.

--
Best regards,
Andrey Tarasevich

3 questions in this regards:

a. if I define an object in .h but it is [.h file] only included in
just one file with no name conflicts, then it won't cause problems with
external linkage, but compiler still complains, why?

b. Why is inline function bypassing it? Actually b/c it is static in a
nature, but it is not discouraged as other static functions, objects,
etc., for bloating the space... why? also, sometimes, compiler chooses
not to inline, would it then affects the linkage?
c. what is the deal with 'const' definition in .h files... what is the
linkage rules applied to them?
THANKS THANKS THANKS

[Peteris Krumins]

puzzlecracker wrote:

can someone explain why

int k; canNOT be definied in .h file?

It can.
what are general rules for what can/cannot be placed in .h file. FAQ
doesn't seem to address this problem.

Because it's not a problem. There are no rules.
You can write all you program in a .h file and then include it in a
..cpp file and include your .cpp file in .zzz file and compile it.
Everything's allowed. But it would be ridiculous.
P.Krumins

[puzzlecracker]

Peteris Krumins wrote:

puzzlecracker wrote:

can someone explain why

int k; canNOT be definied in .h file?

It can.

what are general rules for what can/cannot be placed in .h file. FAQ doesn't seem to address this problem.

Because it's not a problem. There are no rules.
You can write all you program in a .h file and then include it in a
.cpp file and include your .cpp file in .zzz file and compile it.
Everything's allowed. But it would be ridiculous.
P.Krumins

I know it is! even confirmed it. I am curious what is the
justification for such standard.

thanks

[Andrey Tarasevich]

puzzlecracker wrote:

3 questions in this regards:

a. if I define an object in .h but it is [.h file] only included in
just one file with no name conflicts, then it won't cause problems with
external linkage, but compiler still complains, why?
No, it shouldn't cause problems. What kind of complaint are you
receiving from the compiler?
b. Why is inline function bypassing it?
Because that's the way it is in C++.
Actually b/c it is static in a nature,
No, it is not static. Inline functions have external linkage by default.
Even though each translation unit gets its own definition of an inline
function, the address of the function should be the same in all
translation units.
but it is not discouraged as other static functions, objects,
etc., for bloating the space... why?
I don't exactly understand this question.
also, sometimes, compiler chooses
not to inline, would it then affects the linkage?
No. "Linkage" in C++ is a language level concept. It is not affected by
low-level compiler decisions.
c. what is the deal with 'const' definition in .h files... what is the
linkage rules applied to them?

In C++ definitions of const-qualified objects have static linkage by
default. The rest follows.

--
Best regards,
Andrey Tarasevich

[E. Robert Tisdale]

puzzlecracker wrote:

Can someone explain why

int k;

cannot be defined in a *.h [header] file?
It certainly can.
what are general rules
for what can/cannot be placed in a *.h [header] file.
Header files are simply files that are included
near the top [head] of a *.cc [source] file or another header file.
The *.h extension is merely a convention.
Files with the *.h extension or any other extension
including no extension may be included anywhere if a fail
but probably should *not* be called header files
unless they are included somewhere near the head of the file.

There are no rules for what an/cannot be placed in a header file
except when the header file is used to define a *module interface*
which is the most common use for a header file.
Like all other interfaces, a module interface has *no* substance.
It should not, by itself, cause the compiler to emit code
or reserve memory for data. It should not, for example,
contain definitions like:

int k;

which would compel the compiler to reserve memory for k.
It may contain type definitions and declarations like:

extern int k;
void f(void);
inline
int g(int i) {
return i + 1;
}
class X {
private:
int I;
public:
X(int i = 0): I(i) { }
};

etc.

A module interface (header file) should be idempotent.
The contents should be enclosed in "guard macros:
cat file.h #ifndef GUARD_FILE_H
#define GUARD_FILE_H 1
// contents
#endif//GUARD_FILE_H

The module definition (header file) should be self-sufficient.
It should include every module interface (header file)
required to process it's contents.
[The C++] FAQ doesn't seem to address this problem.

The problem is that neither C or C++ possess a strong notion of modules
much less module interfaces like modula. See Modula-2

http://en.wikipedia.org/wiki/Modula-2

C and C++ programmers are obliged
to manufacture ad hoc module interfaces
and the most convenient way to do that is using header files.

[puzzlecracker]

No, it is not static. Inline functions have external linkage by default. Even though each translation unit gets its own definition of an inline function, the address of the function should be the same in all
translation units.

wait, if inline function has external linkage, wouldn't that cause a
link problem when units get assambled? or it is an exception to the
general rule of external linkage?

[Andrey Tarasevich]

puzzlecracker wrote:

No, it is not static. Inline functions have external linkage by

default.

Even though each translation unit gets its own definition of an

inline

function, the address of the function should be the same in all
translation units.

wait, if inline function has external linkage, wouldn't that cause a
link problem when units get assambled? or it is an exception to the
general rule of external linkage?

Yes, you can put it this way, I guess. It is an extension to the general
rule of "external linkage", as it is known in outside the scope of C++
language, in general linker world :)

Inside C++ language though, it is not an extension. It is just the way
the ODR is formulated in language specification. Inline functions shall
have external linkage by default and this shall not cause any problems.
How implementations deal with this requirement is their own internal
business (read about comdat sections in object files for details).

--
Best regards,
Andrey Tarasevich