C++: String data type

[Newsnet Customer]

Hi,

Which system header file do I unclude in order to use the new string data
type?
KJ

[Jon Bell]

In article <3f********@news.iprimus.com.au>,
Newsnet Customer <ni********@iprimus.com.au> wrote:

2) I assume system header files provides implementations unlike user-defined
header files, which are just interfaces.

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 <jt*******@presby.edu> Presbyterian College
Dept. of Physics and Computer Science Clinton, South Carolina USA

[Mike Wahler]

Newsnet Customer <ni********@iprimus.com.au> wrote in message
news:3f********@news.iprimus.com.au...

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, 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.

if string is not a filename then what file is it actually including in

this case? an object string?

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

[Ron Natalie]

"Mike Wahler" <mk******@mkwahler.net> wrote in message news:5tq2b.2599

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.

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).

[Michiel Salters]

"Newsnet Customer" <ni********@iprimus.com.au> wrote in message news:<3f********@news.iprimus.com.au>...

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, 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.

if string is not a filename then what file is it actually including in this
case? an object string?

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.

HTH,
--
Michiel Salters

[Michiel Salters]

Buster Copley <bu****@none.com> wrote in message news:<bi*********@news8.svr.pol.co.uk>...

0Newsnet Customer wrote: ,snip>

2) I assume system header files provides implementations unlike user-defined
header files, which are just interfaces.

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.

<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.

Regards,
--
Michiel Salters

[Kevin Goodsell]

Newsnet Customer wrote:

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?

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_string), 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.

[Newsnet Customer]

> 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, 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.

if string is not a filename then what file is it actually including in

this

case? an object string?

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.

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.
kdf

[Sam Holden]

On Tue, 26 Aug 2003 16:24:03 +0930,
Newsnet Customer <ni********@iprimus.com.au> wrote:

> > > 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, 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.
>
>
> if string is not a filename then what file is it actually including in

this

> case? an object string?

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.

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.

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>.

--
Sam Holden