In article <3f487be2_1@new s.iprimus.com.a u>,
Newsnet Customer <nistygravy@ipr imus.com.au> wrote:[color=blue]
>
>2) I assume system header files provides implementations unlike user-defined
>header files, which are just interfaces.[/color]
No, the system header files are generally just interfaces also. An
exception may be the header files that declare template classes, because
many or most compilers don't support separate compilation of templates.
The implementations are usually in a compiled library file that your
compiler automatically links to your compiled code.
--
Jon Bell <jtbellap8@pres by.edu> Presbyterian College
Dept. of Physics and Computer Science Clinton, South Carolina USA
Newsnet Customer <nistygravy@ipr imus.com.au> wrote in message
news:3f49bfad_1 @news.iprimus.c om.au...[color=blue]
>[color=green][color=darkred]
> > > 2) I assume system header files provides implementations unlike[/color][/color]
> user-defined[color=green][color=darkred]
> > > header files, which are just interfaces.[/color]
> >
> > That's not a question. As an assumption, it's incorrect. For a start, in
> > the statement '#include <string>', the word 'string' is not a filename.
> > The necessary declarations, etc., may or may not be stored in a file.[/color]
>
>
> if string is not a filename then what file is it actually including in[/color]
this[color=blue]
> case? an object string?[/color]
The name of the *header* is <string>. The statement:
#include <string>
Is simply required to cause the compiler to provide
all declarations the language specifies it must, at
the scope where the #include directive appears.
A compiler is free to provide these delcarations any
way at all, e.g. via a file, 'hard coded' into the
compiler, or any other way at all. It's very common
for standard headers to be represented with files,
but not at all required.
"Mike Wahler" <mkwahler@mkwah ler.net> wrote in message news:5tq2b.2599[color=blue]
>
> A compiler is free to provide these delcarations any
> way at all, e.g. via a file, 'hard coded' into the
> compiler, or any other way at all. It's very common
> for standard headers to be represented with files,
> but not at all required.[/color]
Not exactly right. The section header for #include
says "SOURCE FILE INCLUSION." The input units of C++ programs
are defined as SOURCE FILES in the standard. Of course, the C++
notion of source file may be different than what any particular
operating system's idea of a file is. As far as C++ is concerned
a source file is just a stream of implentation defined characters
that subsequently get processed into the source character set and then
into tokens.
Using a system that just uses a database of declarations does not meet
the C++ model (as those who were unfortunate enough to use IBM's attempt
at doing C++ that way found out).
"Newsnet Customer" <nistygravy@ipr imus.com.au> wrote in message news:<3f49bfad_ 1@news.iprimus. com.au>...[color=blue][color=green][color=darkred]
> > > 2) I assume system header files provides implementations unlike[/color][/color]
> user-defined[color=green][color=darkred]
> > > header files, which are just interfaces.[/color]
> >
> > That's not a question. As an assumption, it's incorrect. For a start, in
> > the statement '#include <string>', the word 'string' is not a filename.
> > The necessary declarations, etc., may or may not be stored in a file.[/color]
>
>
> if string is not a filename then what file is it actually including in this
> case? an object string?[/color]
Or a precompiled version that does exactly what the file would have done.
Or any other representation that makes the implementation behave as if
a file containg the definitions was included.
Buster Copley <buster@none.co m> wrote in message news:<biab35$f5 $1@news8.svr.po l.co.uk>...[color=blue]
> 0Newsnet Customer wrote:[/color]
,snip>
[color=blue][color=green]
> > 2) I assume system header files provides implementations unlike user-defined
> > header files, which are just interfaces.[/color][/color]
[color=blue]
> That said, in many cases there will be a header file called 'string'.
> And because separate compilation of templates is so tricky, the chances
> are most of the implementation will be available just from including the
> appropriate header. User header files may also include templates and
> inline functions.[/color]
<string> is special, because in 99,x% of the cases it is instantiated on
either char or wchar_t, so for these two cases an implementation may very
have a separation of interface and implementation. In addition, this can
be achieved in non-portable ways, because the <string> implementation
is a compiler-specific header.
Newsnet Customer wrote:
[color=blue]
>
> Right, so your saying that by including:
>
> #include <string>
>
> the compiler's preprocessor will include the contents of the <string> header
> file into the source, then compile the entire source file, and then link it
> with whatever file it neeeds (in this case, string.cpp). Is this what you
> mean?
>[/color]
It is very unlikely that this is what happens. Looking at it abstractly,
the implementation may not include a file called 'string'. It may not
have such a file at all. It's possible that it uses some magic to
replace the #include directive with the right stuff. It's also possible
that it doesn't do anything except set some kind of flag in the
compiler. "Header file" is not the right term, since it may or may not
be an actual file. The term is simply "header".
In most real implementations , 'string' is the name of a real file, and
the contents of that file are inserted into the source file at the point
of the #include directive. However, it's extremely unlikely that there
would be a 'string.cpp' file that the compiler would link in, for
several reasons.
First, compiler libraries are usually .lib or .obj files, and they
usually don't have one for every header. So it would be more likely to
have something like cppstd.lib that contains all or most of the standard
library (except for templates).
Second, std::string is a specialization of a template
(std::basic_str ing), and templates cannot be separately compiled in most
implementations . So 'string.cpp' wouldn't work. It's more likely that
the entire implementation of the basic_string template is in the
<string> header.
But basically you are asking hypothetical questions that don't have any
single answer and don't affect language usage anyway. So why bother
worrying about them?
-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
[color=blue][color=green][color=darkred]
> > > > 2) I assume system header files provides implementations unlike[/color]
> > user-defined[color=darkred]
> > > > header files, which are just interfaces.
> > >
> > > That's not a question. As an assumption, it's incorrect. For a start,[/color][/color][/color]
in[color=blue][color=green][color=darkred]
> > > the statement '#include <string>', the word 'string' is not a[/color][/color][/color]
filename.[color=blue][color=green][color=darkred]
> > > The necessary declarations, etc., may or may not be stored in a file.[/color]
> >
> >
> > if string is not a filename then what file is it actually including in[/color]
> this[color=green]
> > case? an object string?[/color]
>
> The name of the *header* is <string>. The statement:
>
> #include <string>
>
> Is simply required to cause the compiler to provide
> all declarations the language specifies it must, at
> the scope where the #include directive appears.
>
> A compiler is free to provide these delcarations any
> way at all, e.g. via a file, 'hard coded' into the
> compiler, or any other way at all. It's very common
> for standard headers to be represented with files,
> but not at all required.[/color]
I asummed that if the header does not have an extension associated with it
then it's not a file, which leaves me thinking what <string> represents. I
don't think you have exactly told me that, but it appears that it could be
'hard-coded' into the compiler.
On Tue, 26 Aug 2003 16:24:03 +0930,
Newsnet Customer <nistygravy@ipr imus.com.au> wrote:[color=blue]
>[color=green][color=darkred]
>> > > > 2) I assume system header files provides implementations unlike
>> > user-defined
>> > > > header files, which are just interfaces.
>> > >
>> > > That's not a question. As an assumption, it's incorrect. For a start,[/color][/color]
> in[color=green][color=darkred]
>> > > the statement '#include <string>', the word 'string' is not a[/color][/color]
> filename.[color=green][color=darkred]
>> > > The necessary declarations, etc., may or may not be stored in a file.
>> >
>> >
>> > if string is not a filename then what file is it actually including in[/color]
>> this[color=darkred]
>> > case? an object string?[/color]
>>
>> The name of the *header* is <string>. The statement:
>>
>> #include <string>
>>
>> Is simply required to cause the compiler to provide
>> all declarations the language specifies it must, at
>> the scope where the #include directive appears.
>>
>> A compiler is free to provide these delcarations any
>> way at all, e.g. via a file, 'hard coded' into the
>> compiler, or any other way at all. It's very common
>> for standard headers to be represented with files,
>> but not at all required.[/color]
>
> I asummed that if the header does not have an extension associated with it
> then it's not a file, which leaves me thinking what <string> represents. I
> don't think you have exactly told me that, but it appears that it could be
> 'hard-coded' into the compiler.[/color]
Your assumption is incorrect. The header could be implemented as a file,
or it could just set a flag in the compiler, or whatever.
As a counter example to your assumption:
$ ls -l /gnu/usr/include/g++-3/string
-rw-rw-r-- 1 bin bin 238 Nov 18 1999 /gnu/usr/include/g++-3/string
That compiler/library combination implementation uses a file named 'string' to
perform #include <string>.
Comment