473,322 Members | 1,846 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,322 software developers and data experts.

What is a header?

If a header is not necessarily a source file, and the sequences delimited by
< and > in header names aren't necessarily valid source file names, what
exactly is a header?
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #1
31 1731
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message
news:h-********************@speakeasy.net...
If a header is not necessarily a source file, and the sequences delimited by < and > in header names aren't necessarily valid source file names, what
exactly is a header?


A set of declarations. The actual ultimate source of
these declarations is unspecified. It's typically
a file (often with the same name).

-Mike
Jul 22 '05 #2
Steven T. Hatton wrote:
If a header is not necessarily a source file, and the sequences delimited by
< and > in header names aren't necessarily valid source file names, what
exactly is a header?


From a compiler's perspective they don't exist. The preprocessor
combines source and header files (via #include) into translation units.

It's just a programmer convenience. It makes it easier to refer to
common code between translation units by including all the
interfaces/declarations into both.

Everything else you'll see in there is simply the convention (or coding
standards) that were used to write the program. Like where on the line
you indent or put braces.

-- Pete
Jul 22 '05 #3
"Steven T. Hatton" wrote:

If a header is not necessarily a source file, and the sequences delimited by
< and > in header names aren't necessarily valid source file names, what
exactly is a header?


A header is _necessarily_ a source file that is exclusively distinctly visible
by the preprocessor.
Jul 22 '05 #4
Julie wrote:
"Steven T. Hatton" wrote:

If a header is not necessarily a source file, and the sequences delimited
by < and > in header names aren't necessarily valid source file names,
what exactly is a header?


A header is _necessarily_ a source file that is exclusively distinctly
visible by the preprocessor.

"A header is not necessarily a source file, nor are the sequences delimited
by < and > in header names necessarily valid source file names (16.2)."
ISO/IEC 14882:2003(E)
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #5
Julie wrote:
"Steven T. Hatton" wrote:
If a header is not necessarily a source file, and the sequences delimited by
< and > in header names aren't necessarily valid source file names, what
exactly is a header?

A header is _necessarily_ a source file that is exclusively distinctly visible
by the preprocessor.


2.8 Header names [lex.header]
header-name:
<h-char-sequence>
"q-char-sequence"
h-char-sequence:
h-char
h-char-sequence h-char
h-char:
any member of the source character set except
new-line and >
q-char-sequence:
q-char
q-char-sequence q-char
q-char:
any member of the source character set except
new-line and "

1 Header name preprocessing tokens shall only appear within a #include
preprocessing directive (_cpp.include_). The sequences in both forms
of header-names are mapped in an implementation-defined manner to
headers or to external source file names as specified in
_cpp.include_.

16.2 Source file inclusion [cpp.include]

1 A #include directive shall identify a header or source file that can
be processed by the implementation.

2 A preprocessing directive of the form
# include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a header
identified uniquely by the specified sequence between the < and >
delimiters, and causes the replacement of that directive by the entire
contents of the header. How the places are specified or the header
identified is implementation-defined.
I don't see anything here requiring headers to be files. In fact, it
sounds like they went out of their way to make sure that was not implied
(e.g., "header _or_ source file").

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Jul 22 '05 #6
"Steven T. Hatton" wrote:

Julie wrote:
"Steven T. Hatton" wrote:

If a header is not necessarily a source file, and the sequences delimited
by < and > in header names aren't necessarily valid source file names,
what exactly is a header?


A header is _necessarily_ a source file that is exclusively distinctly
visible by the preprocessor.

"A header is not necessarily a source file, nor are the sequences delimited
by < and > in header names necessarily valid source file names (16.2)."
ISO/IEC 14882:2003(E)


I would have preferred you posting that with your original post.
Jul 22 '05 #7
Kevin Goodsell wrote:
I don't see anything here requiring headers to be files. In fact, it
sounds like they went out of their way to make sure that was not implied
(e.g., "header _or_ source file").


I have the feeling there is some ancient dark secret surrounding this issue
that none of the oldtimers wants to talk about. I tried to ask about the
history of research into alternatives to the traditional header file on
comp.std.c++, but received no reply.

--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #8
* "Steven T. Hatton" <su******@setidava.kushan.aa> schriebt:
Kevin Goodsell wrote:
I don't see anything here requiring headers to be files. In fact, it
sounds like they went out of their way to make sure that was not implied
(e.g., "header _or_ source file").

I have the feeling there is some ancient dark secret surrounding this issue
that none of the oldtimers wants to talk about.


No dark secrets.

I tried to ask about the
history of research into alternatives to the traditional header file on
comp.std.c++, but received no reply.


The current wording allows an implementation to implement standard
headers in other and perhaps more efficient ways than using files, like
like having e.g. <string> hardwired into the compiler.

Because of that it also allows non-file-based headers in general.

But as far as I know there are no commonly used implementations taking
advantage of this. In terms of designing the standard it's like the common
error of adding complexity to a class in order to support some imagined
future need which never actually materializes. So perhaps what you think
of as the "oldtimers" in [comp.std.c++] simply were a bit ashamed, or even
simpler, didn't think this important enough to waste time on.

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 22 '05 #9
Alf P. Steinbach wrote:
* "Steven T. Hatton" <su******@setidava.kushan.aa> schriebt:
Kevin Goodsell wrote:
> I don't see anything here requiring headers to be files. In fact, it
> sounds like they went out of their way to make sure that was not
> implied (e.g., "header _or_ source file").
>


I have the feeling there is some ancient dark secret surrounding this
issue that none of the oldtimers wants to talk about.


No dark secrets.

I tried to ask about the
history of research into alternatives to the traditional header file on
comp.std.c++, but received no reply.


The current wording allows an implementation to implement standard
headers in other and perhaps more efficient ways than using files, like
like having e.g. <string> hardwired into the compiler.

Because of that it also allows non-file-based headers in general.

But as far as I know there are no commonly used implementations taking
advantage of this. In terms of designing the standard it's like the
common error of adding complexity to a class in order to support some
imagined
future need which never actually materializes. So perhaps what you think
of as the "oldtimers" in [comp.std.c++] simply were a bit ashamed, or even
simpler, didn't think this important enough to waste time on.


There's an interesting epigraph at the beginning of chapter 18 in
TC++PL(SE). Form is liberating. - engineers' proverb.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #10
On Thu, 01 Apr 2004 17:10:38 -0500, Steven T. Hatton wrote:

I have the feeling there is some ancient dark secret surrounding this issue
that none of the oldtimers wants to talk about. I tried to ask about the
history of research into alternatives to the traditional header file on
comp.std.c++, but received no reply.


People here and in comp.std.c++ volunteer their free time to participate
in discussions they find interesting. If you don't get an answer to your
posts, it's either because a) there's a great conspiracy against you or
b) your question was not regarded as something worth spending time on.

Now, which of the two alternatives do you think is the more likely one?

//JD

Jul 22 '05 #11
John Doe wrote:
On Thu, 01 Apr 2004 17:10:38 -0500, Steven T. Hatton wrote:

I have the feeling there is some ancient dark secret surrounding this
issue that none of the oldtimers wants to talk about. I tried to ask
about the history of research into alternatives to the traditional header
file on comp.std.c++, but received no reply.


People here and in comp.std.c++ volunteer their free time to participate
in discussions they find interesting. If you don't get an answer to your
posts, it's either because a) there's a great conspiracy against you or
b) your question was not regarded as something worth spending time on.

Now, which of the two alternatives do you think is the more likely one?

//JD


Actually there's more to it than just posting the question once. But, like I
said, it's just a feeling.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #12
On Thu, 01 Apr 2004 14:01:53 -0800, Julie <ju***@nospam.com> wrote:
"Steven T. Hatton" wrote:

Julie wrote:
> "Steven T. Hatton" wrote:
>>
>> If a header is not necessarily a source file, and the sequences delimited
>> by < and > in header names aren't necessarily valid source file names,
>> what exactly is a header?
>
> A header is _necessarily_ a source file that is exclusively distinctly
> visible by the preprocessor.

"A header is not necessarily a source file, nor are the sequences delimited
by < and > in header names necessarily valid source file names (16.2)."
ISO/IEC 14882:2003(E)


I would have preferred you posting that with your original post.


The OP doesn't seem to believe in providing more information than it takes
in order for him to be able to understand his own questions. Or, he just
phrases questions in a way that misrepresents the level he's approaching
the issue from; whether he's doing this to deliberately draw folks who are
earnestly trying to help him into making errors he can "poach", or he just
takes opportunities when they arise to demonstrate what he possibly thinks
of as his superior intellect, I can't say. I do, however, now find myself
embarrassed to be seen in the same thread with him (I would have preferred
to email this to you directly, but you don't give out your address.)
-leor

--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: Download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html
Jul 22 '05 #13
Leor Zolman wrote:


The OP doesn't seem to believe in providing more information than it takes
in order for him to be able to understand his own questions. Or, he just
phrases questions in a way that misrepresents the level he's approaching
the issue from;
Hu?
whether he's doing this to deliberately draw folks who are
earnestly trying to help him into making errors he can "poach",


Na, I only take fair game.

--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #14
> The OP doesn't seem to believe in providing more information than it takes
in order for him to be able to understand his own questions. Or, he just
phrases questions in a way that misrepresents the level he's approaching
the issue from; whether he's doing this to deliberately draw folks who are
earnestly trying to help him into making errors he can "poach", or he just
takes opportunities when they arise to demonstrate what he possibly thinks
of as his superior intellect, I can't say. I do, however, now find myself
embarrassed to be seen in the same thread with him (I would have preferred
to email this to you directly, but you don't give out your address.)
-leor


It might be useful to layout what was said.

Mr Hatton's first post:
If a header is not necessarily a source file, and the sequences delimited by
< and > in header names aren't necessarily valid source file names, what
exactly is a header?

2nd: (Note the same wording as above)
"A header is not necessarily a source file, nor are the sequences delimited
by < and > in header names necessarily valid source file names (16.2)."
ISO/IEC 14882:2003(E)

3rd:
I have the feeling there is some ancient dark secret surrounding this issue
that none of the oldtimers wants to talk about. I tried to ask about the
history of research into alternatives to the traditional header file on
comp.std.c++, but received no reply.

4th:
There's an interesting epigraph at the beginning of chapter 18 in
TC++PL(SE). Form is liberating. - engineers' proverb.

5th:
Actually there's more to it than just posting the question once. But, like I
said, it's just a feeling.

Jul 22 '05 #15
Frosted Flake wrote:
Mr Hatton's first post:
If a header is not necessarily a source file, and the sequences delimited
by < and > in header names aren't necessarily valid source file names,
what exactly is a header?

2nd: (Note the same wording as above)
"A header is not necessarily a source file, nor are the sequences
delimited by < and > in header names necessarily valid source file names
(16.2)." ISO/IEC 14882:2003(E)

3rd:
I have the feeling there is some ancient dark secret surrounding this
issue that none of the oldtimers wants to talk about. I tried to ask about
the history of research into alternatives to the traditional header file
on comp.std.c++, but received no reply.

4th:
There's an interesting epigraph at the beginning of chapter 18 in
TC++PL(SE). Form is liberating. - engineers' proverb.

5th:
Actually there's more to it than just posting the question once. But, like
I said, it's just a feeling.


So what is this? Your idea of one-upsmanship? Try harder next time. You're
dealing with a pro.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #16
Steve,
I'm sorry I meant this to show there didn't seem to be anything
to what the guy was saying about about poaching. Sometimes
what people remember is not how it is when you take
another look. I hope you understand.
Jul 22 '05 #17
Frosted Flake wrote:
Steve,
I'm sorry I meant this to show there didn't seem to be anything
to what the guy was saying about about poaching. Sometimes
what people remember is not how it is when you take
another look. I hope you understand.


No problem. I was just having fun with obscurity. ;-)
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #18
Joe
who actually gives a shit?

we know what it does... that's enough 4 me
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message
news:h-********************@speakeasy.net...
If a header is not necessarily a source file, and the sequences delimited by < and > in header names aren't necessarily valid source file names, what
exactly is a header?
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

Jul 22 '05 #19
Joe
the CLR rules now anayway. u r dust

"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message
news:h-********************@speakeasy.net...
If a header is not necessarily a source file, and the sequences delimited by < and > in header names aren't necessarily valid source file names, what
exactly is a header?
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org

Jul 22 '05 #20
Steven T. Hatton wrote:
If a header is not necessarily a source file, and the sequences delimited by
< and > in header names aren't necessarily valid source file names,
what exactly is a header?


A header is an inclusion at the beginning (head) of your source file.
A header partially compensates for the lack of a true module interface
in the C and C++ programming languages.
A well designed header file is both self sufficient and idempotent.
A header file contains declarations and definitions
that are (or could be) common to two or more source files.
A header file should contain no source code that, by itself,
causes the compiler to emit object code.
Jul 22 '05 #21
Steven T. Hatton wrote:
If a header is not necessarily a source file, and the sequences delimited by
< and > in header names aren't necessarily valid source file names,
what exactly is a header?


A header is an inclusion at the beginning (head) of your source file.
A header partially compensates for the lack of a true module interface
in the C and C++ programming languages.
A well designed header file is both self sufficient and idempotent.
A header file contains declarations and definitions
that are (or could be) common to two or more source files.
A header file should contain no source code that, by itself,
causes the compiler to emit object code.
Jul 22 '05 #22
E. Robert Tisdale wrote:
Steven T. Hatton wrote:
If a header is not necessarily a source file, and the sequences delimited
by < and > in header names aren't necessarily valid source file names,
what exactly is a header?


A header is an inclusion at the beginning (head) of your source file.
A header partially compensates for the lack of a true module interface
in the C and C++ programming languages.
A well designed header file is both self sufficient and idempotent.
A header file contains declarations and definitions
that are (or could be) common to two or more source files.
A header file should contain no source code that, by itself,
causes the compiler to emit object code.


I had not noticed this reply until earlier today. That last point gives me a
bit of pause. Does it suggests I should never have a selfcontained class
definition in a header? Or will it only generate object code if it has an
instance defined? Can you clarify for me your reasoning for this rule?

Something occurred to me regarding headers. If I'm not mistaken, a header
exhibits an IS-A nature. If so, how could the abstract concept of a header
be represented as a class? When I tried to consider that question, I
realized it only seems to have meaning in the context of a source file.
That leads me to ask the same question of a source file.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #23
E. Robert Tisdale wrote:
Steven T. Hatton wrote:
If a header is not necessarily a source file, and the sequences delimited
by < and > in header names aren't necessarily valid source file names,
what exactly is a header?


A header is an inclusion at the beginning (head) of your source file.
A header partially compensates for the lack of a true module interface
in the C and C++ programming languages.
A well designed header file is both self sufficient and idempotent.
A header file contains declarations and definitions
that are (or could be) common to two or more source files.
A header file should contain no source code that, by itself,
causes the compiler to emit object code.


I had not noticed this reply until earlier today. That last point gives me a
bit of pause. Does it suggests I should never have a selfcontained class
definition in a header? Or will it only generate object code if it has an
instance defined? Can you clarify for me your reasoning for this rule?

Something occurred to me regarding headers. If I'm not mistaken, a header
exhibits an IS-A nature. If so, how could the abstract concept of a header
be represented as a class? When I tried to consider that question, I
realized it only seems to have meaning in the context of a source file.
That leads me to ask the same question of a source file.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #24
Steven T. Hatton wrote:
E. Robert Tisdale wrote:
A header is an inclusion at the beginning (head) of your source file.
A header partially compensates for the lack of a true module interface
in the C and C++ programming languages.
A well designed header file is both self sufficient and idempotent.
A header file contains declarations and definitions
that are (or could be) common to two or more source files.
A header file should contain no source code that, by itself,
causes the compiler to emit object code.
I had not noticed this reply until earlier today.
That last point gives me a bit of pause. Does it suggest [that]
I should never have a selfcontained class definition in a header?
Or will it only generate object code if it has an
instance defined? Can you clarify for me your reasoning for this rule?
Something occurred to me regarding headers.
If I'm not mistaken, a header exhibits an IS-A nature. If so,
how could the abstract concept of a header be represented as a class?
When I tried to consider that question, I realized [that]
it only seems to have meaning in the context of a source file.
That leads me to ask the same question of a source file.


A header file contains the *interface*
cat file.hpp #ifndef GUARD_FILE_HPP
#define GUARD_FILE_HPP 1
void f(void); // function declaration
#endif//GUARD_FILE_HPP

A source file contains the implementation
cat file.cpp

#include "file.hpp"
void f(void) { // function definition
// ...
}

The header file is included near the head (top)
of a source file (or another header file).
The function declaration does not by itself
cause the compiler to emit any [object] code.
If you include the function definition in multiple
source files and attempt to link the resulting objects together,
the link editor will complain about multiple definitions.

A class definition, by itself, does not cause the compiler
to emit any source code because all of the function definitions
within the class definition are inline by default.
Any external class member function definitions
should be sequestered in a separate source file
which can be compiled and linked into your application.

Jul 22 '05 #25
Steven T. Hatton wrote:
E. Robert Tisdale wrote:
A header is an inclusion at the beginning (head) of your source file.
A header partially compensates for the lack of a true module interface
in the C and C++ programming languages.
A well designed header file is both self sufficient and idempotent.
A header file contains declarations and definitions
that are (or could be) common to two or more source files.
A header file should contain no source code that, by itself,
causes the compiler to emit object code.
I had not noticed this reply until earlier today.
That last point gives me a bit of pause. Does it suggest [that]
I should never have a selfcontained class definition in a header?
Or will it only generate object code if it has an
instance defined? Can you clarify for me your reasoning for this rule?
Something occurred to me regarding headers.
If I'm not mistaken, a header exhibits an IS-A nature. If so,
how could the abstract concept of a header be represented as a class?
When I tried to consider that question, I realized [that]
it only seems to have meaning in the context of a source file.
That leads me to ask the same question of a source file.


A header file contains the *interface*
cat file.hpp #ifndef GUARD_FILE_HPP
#define GUARD_FILE_HPP 1
void f(void); // function declaration
#endif//GUARD_FILE_HPP

A source file contains the implementation
cat file.cpp

#include "file.hpp"
void f(void) { // function definition
// ...
}

The header file is included near the head (top)
of a source file (or another header file).
The function declaration does not by itself
cause the compiler to emit any [object] code.
If you include the function definition in multiple
source files and attempt to link the resulting objects together,
the link editor will complain about multiple definitions.

A class definition, by itself, does not cause the compiler
to emit any source code because all of the function definitions
within the class definition are inline by default.
Any external class member function definitions
should be sequestered in a separate source file
which can be compiled and linked into your application.

Jul 22 '05 #26
E. Robert Tisdale wrote:
Steven T. Hatton wrote:
[snip]
A header file contains the *interface*
That part I accept as a laudable goal. I've seen header files that look
more like the following, than they do like an interface:

#ifndef _STLP_STRING
# define _STLP_STRING

# ifndef _STLP_OUTERMOST_HEADER_ID
# define _STLP_OUTERMOST_HEADER_ID 0x68
# include <stl/_prolog.h>
# endif

# ifdef _STLP_PRAGMA_ONCE
# pragma once
# endif

#if defined (_STLP_USE_NATIVE_STRING)

// as part of compiled runtime library depends on it.

# if defined (_STLP_MSVC)
# include <streambuf>
# include <istream>
# endif

# include _STLP_NATIVE_HEADER(string)

# endif /* _STLP_USE_NATIVE_STRING */

# if !defined (_STLP_USE_NATIVE_STRING) || defined (_STLP_USE_OWN_NAMESPACE)
# include <stl/_string.h>
# else
# include <stl/_string_hash.h>
# endif /*_STLP_USE_NATIVE_STRING */

// cleanup

# if (_STLP_OUTERMOST_HEADER_ID == 0x68)
# include <stl/_epilog.h>
# undef _STLP_OUTERMOST_HEADER_ID
# endif

#endif /* _STLP_STRING */

// Local Variables:
// mode:C++
// End:
I understand this is all preprocessed to render the actual header that goes
into the file where it's included. It just doesn't seem to be serving one
commonly advertised purpose of an *interface*, i.e., readability.
cat file.hpp

#ifndef GUARD_FILE_HPP
#define GUARD_FILE_HPP 1
void f(void); // function declaration
#endif//GUARD_FILE_HPP

A source file contains the implementation
cat file.cpp

#include "file.hpp"
void f(void) { // function definition
// ...
}

The header file is included near the head (top)
of a source file (or another header file).


Assuming the headers are files. The Standard states the following:
"A header is not necessarily a source file, nor are the sequences delimited
by < and > in header names necessarily valid source file names (16.2)."

Is any file that is #included a header file? For example:

http://doc.trolltech.com/3.3/moc.html#moc
"If the class declaration above is found in the file myclass.cpp, the moc
output should be put in a file called myclass.moc. This file should be
#included in the implementation file, i.e. myclass.cpp should contain the
line

#include "myclass.moc"

at the end. This will cause the moc-generated code to be compiled and linked
together with the normal class definition in myclass.cpp, so it is not
necessary to compile and link it separately, as in Method A."

Is the myclass.moc a header file according to the specification? The
standard seems to allow for the inclusion of "source files" as well as
headers, but doesn't seem to provide a very clear definition of what that
means.
If you include the function definition in multiple
source files and attempt to link the resulting objects together,
the link editor will complain about multiple definitions.
The ODR.
A class definition, by itself, does not cause the compiler
to emit any source code because all of the function definitions
within the class definition are inline by default.
I'm confident you are describing the behavior of any reasonable compiler
implementation, but I wonder if this is actually specified.
Any external class member function definitions
should be sequestered in a separate source file
which can be compiled and linked into your application.


I agree.

I also asked the following, which I would also like to find a reasonable
answer for:
If I'm not mistaken, a header exhibits an IS-A nature. If so,
how could the abstract concept of a header be represented as a class?
When I tried to consider that question, I realized [that]
it only seems to have meaning in the context of a source file.
That leads me to ask the same question of a source file.


I have the sense there are many terms and assumptions used in the Standard
which are not defined, but are fairly specific to the subject. "Header" is
a good example, I use "header" in many different ways in different
contexts, but the specific meaning in a C++ context seems to be assumed
without significant clarification.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #27
E. Robert Tisdale wrote:
Steven T. Hatton wrote:
[snip]
A header file contains the *interface*
That part I accept as a laudable goal. I've seen header files that look
more like the following, than they do like an interface:

#ifndef _STLP_STRING
# define _STLP_STRING

# ifndef _STLP_OUTERMOST_HEADER_ID
# define _STLP_OUTERMOST_HEADER_ID 0x68
# include <stl/_prolog.h>
# endif

# ifdef _STLP_PRAGMA_ONCE
# pragma once
# endif

#if defined (_STLP_USE_NATIVE_STRING)

// as part of compiled runtime library depends on it.

# if defined (_STLP_MSVC)
# include <streambuf>
# include <istream>
# endif

# include _STLP_NATIVE_HEADER(string)

# endif /* _STLP_USE_NATIVE_STRING */

# if !defined (_STLP_USE_NATIVE_STRING) || defined (_STLP_USE_OWN_NAMESPACE)
# include <stl/_string.h>
# else
# include <stl/_string_hash.h>
# endif /*_STLP_USE_NATIVE_STRING */

// cleanup

# if (_STLP_OUTERMOST_HEADER_ID == 0x68)
# include <stl/_epilog.h>
# undef _STLP_OUTERMOST_HEADER_ID
# endif

#endif /* _STLP_STRING */

// Local Variables:
// mode:C++
// End:
I understand this is all preprocessed to render the actual header that goes
into the file where it's included. It just doesn't seem to be serving one
commonly advertised purpose of an *interface*, i.e., readability.
cat file.hpp

#ifndef GUARD_FILE_HPP
#define GUARD_FILE_HPP 1
void f(void); // function declaration
#endif//GUARD_FILE_HPP

A source file contains the implementation
cat file.cpp

#include "file.hpp"
void f(void) { // function definition
// ...
}

The header file is included near the head (top)
of a source file (or another header file).


Assuming the headers are files. The Standard states the following:
"A header is not necessarily a source file, nor are the sequences delimited
by < and > in header names necessarily valid source file names (16.2)."

Is any file that is #included a header file? For example:

http://doc.trolltech.com/3.3/moc.html#moc
"If the class declaration above is found in the file myclass.cpp, the moc
output should be put in a file called myclass.moc. This file should be
#included in the implementation file, i.e. myclass.cpp should contain the
line

#include "myclass.moc"

at the end. This will cause the moc-generated code to be compiled and linked
together with the normal class definition in myclass.cpp, so it is not
necessary to compile and link it separately, as in Method A."

Is the myclass.moc a header file according to the specification? The
standard seems to allow for the inclusion of "source files" as well as
headers, but doesn't seem to provide a very clear definition of what that
means.
If you include the function definition in multiple
source files and attempt to link the resulting objects together,
the link editor will complain about multiple definitions.
The ODR.
A class definition, by itself, does not cause the compiler
to emit any source code because all of the function definitions
within the class definition are inline by default.
I'm confident you are describing the behavior of any reasonable compiler
implementation, but I wonder if this is actually specified.
Any external class member function definitions
should be sequestered in a separate source file
which can be compiled and linked into your application.


I agree.

I also asked the following, which I would also like to find a reasonable
answer for:
If I'm not mistaken, a header exhibits an IS-A nature. If so,
how could the abstract concept of a header be represented as a class?
When I tried to consider that question, I realized [that]
it only seems to have meaning in the context of a source file.
That leads me to ask the same question of a source file.


I have the sense there are many terms and assumptions used in the Standard
which are not defined, but are fairly specific to the subject. "Header" is
a good example, I use "header" in many different ways in different
contexts, but the specific meaning in a C++ context seems to be assumed
without significant clarification.
--
p->m == (*p).m == p[0].m
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.org
Jul 22 '05 #28
Steven T. Hatton wrote:
I have the sense there are many terms and assumptions used in the Standard
which are not defined, but are fairly specific to the subject.
"Header" is a good example, I use "header" in many different ways
in different contexts, but the specific meaning in a C++ context
seems to be assumed without significant clarification.


All "header" really means is that it is included
near the head of a source file or another header.
C doesn't support module interfaces explicitly
so headers were used to *improvise*
without ever acknowledging this deficiency in the language.

Jul 22 '05 #29
Steven T. Hatton wrote:
I have the sense there are many terms and assumptions used in the Standard
which are not defined, but are fairly specific to the subject.
"Header" is a good example, I use "header" in many different ways
in different contexts, but the specific meaning in a C++ context
seems to be assumed without significant clarification.


All "header" really means is that it is included
near the head of a source file or another header.
C doesn't support module interfaces explicitly
so headers were used to *improvise*
without ever acknowledging this deficiency in the language.

Jul 22 '05 #30
E. Robert Tisdale wrote:
All "header" really means is that it is included
near the head of a source file or another header.
C doesn't support module interfaces explicitly
so headers were used to *improvise*
without ever acknowledging this deficiency in the language.

"I'd like to see Cpp abolished." - Bjarne Stroustrup

So why does it survive? My suspicion is that everybody thinks the other guy
knows how it's defined, and how it works. People think it's sacrosanct and
not subject to question or challenge. The ugly truth is, nobody knows how
it is defined other than 'poorly'.

--
STH
Hatton's Law: "There is only One inviolable Law"
KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
Mozilla: http://www.mozilla.org
Jul 22 '05 #31
"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message
news:a7********************@speakeasy.net...
E. Robert Tisdale wrote:
All "header" really means is that it is included
near the head of a source file or another header.
C doesn't support module interfaces explicitly
so headers were used to *improvise*
without ever acknowledging this deficiency in the language.

"I'd like to see Cpp abolished." - Bjarne Stroustrup

So why does it survive? My suspicion is that everybody thinks the

other guy knows how it's defined, and how it works. People think it's sacrosanct and not subject to question or challenge. The ugly truth is, nobody knows how it is defined other than 'poorly'.


Nonsense. Headers were used to simulate COBOL copybooks. Since
everyone knew how THEY worked (in 1964) it all made perfectly good
sense. With file type associations, I half-like cpp as an extention
that launches my preferred compiler. It would be nice to have cp1,
cp2, etc. for launching different compilers.
Hey! I can do that for myself! The trouble is it ain't portable and my
files may eventually get used by another programmer at work. The real
movement to guard against is people who suggest using the same file
type for generic identification (.src for all source, .doc for all
documents, .txt for all text, etc.).
--
Gary
Jul 22 '05 #32

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

Similar topics

6
by: Zhang Weiwu | last post by:
Hello. I am working with a php software project, in it (www.egroupware.org) Chinese simplified locate is "zh" while Traditional Chinese "tw". I wish to send correct language attribute in http...
31
by: Steven T. Hatton | last post by:
If a header is not necessarily a source file, and the sequences delimited by < and > in header names aren't necessarily valid source file names, what exactly is a header? -- p->m == (*p).m == p.m...
3
by: Peter Oliphant | last post by:
I know that 'stdafx.h' has to do with pre-compiled headers. However, it seem weird that it is a required 'include' in any CPP file, especially since the file itself has no code in it! I know...
4
by: Kunle Odutola | last post by:
I'm trying to understand where the information in the META.INF directory including MANIFEST.MF etc is to be found for .NET assemblies. Also some projects such as Eclipse's OSGi kernel stores...
24
by: ypjofficial | last post by:
Hello all, I have written a class with many private data members.and i am putting it in a separate dll file. Now when i link that file while writing my main program module,natuarally i have to...
82
by: quiberon2 | last post by:
Hi, Sorry if it might be a stupid question but what should returns malloc(0) ? void *ptr = malloc(0); I am running gcc 3.3.5 and a non-null address is returned. ( in the compiler that I am...
6
by: DaTurk | last post by:
Hi, I'm a bit rusty with the wonderful language of c++. I worked with it, maybe 6 or 7 years ago and now I need to knock the dust off. But I was perusing some code when I noticed that this one...
8
by: The Cool Giraffe | last post by:
One thing i do know for sure. When one creates a CPP file, one needs to include the H file. Now, having said that, i wonder if there are some general hints, requirements or standard guide lines on...
4
by: andre rodier | last post by:
Hello, I need to display or propose a jpeg image on a web page. When I need to display the image, I use this code : header("Content-Length: $fileSize") ; header("Content-Type: $type") ;...
9
by: xiao | last post by:
It always dumped when I tried to run it... But it compiles OK. What I want to do is to do a test: Read information from a .dat file and then write it to another file. The original DAT file is...
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...
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...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
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: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
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

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.