31  2739 
"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
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
"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.
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
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.
"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.
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
* "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?
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
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
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
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
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
> 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.
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
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.
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
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
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
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.
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.
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
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
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.
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.
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
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
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.
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.
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
"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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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") ;...
|
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...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 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 a new...
| |
