This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Standard header format.


"Steven T. Hatton" <hattons@globalsymmetry.com> writes:

| On Saturday 05 June 2004 13:47, Gabriel Dos Reis wrote:
| > "Steven T. Hatton" <hattons@globalsymmetry.com> writes:
| >
| > [...]
| >
| > | In TC++PL(SE) Stroustrup suggests I look at the standard headers for my
| > | C++ implementation to see the interface for the components of the
| > | Standard Library.
| >
| > Can you present full quote and context?
| 
| On such instance is here:
| 
| 17 Standard Containers
| 17.1 Standard Containers
| 17.1.1 Operations Summary
| "This section lists the common and almost common members of the standard 
| containers. Form more details, read your standard headers (<vector>, <list>, 
| <map>, etc., sect. 16.1.2)."

I do not take that meaning Stroustrup suggest people ruch looking
into the _files_ the compilers might provide.  Rather, I take that
to mean read the documentation of those standard headers, in
particular refer to §16.1.2 where he discusses the standard headers
orgnization.  Note that he carefully avoided to mention "header
files" (which you, Steven Hatton, are talking about).  Rather, he was
talking about the abstraction "standard header" -- which is not the same
as a header file.   Therefore, I think you're reading too much into
what he wrote, and specially he did not suggest you read the header
files provided by your compiler.

In particular, he went on saying (§16.1.2, page 434):

  For a standard library facility to be used its header must be
  included.  Writing out the relevant declarations yourself is /not/
  standard-conforming alternative. The reason is that some
  implementations optimize compilation   based on the standard header
  inclusion and others provide optimized   implementation of the
  standard library facilities triggered by the   headers.  In general,
  implementers use standard headers in ways   programmers cannot
  predict and shouldn't have to know about. 

Given the very last sentence, I don't see how you conclude that
Stroustrup suggest you look into files provided by your
implementation.  Rather, he was explicitly suggesting in that
paragraph that you stick to the standard abstract description of
standard headers. 

[...]

| I was not suggesting the Standard required this.  I was merely suggesting 
| there are likely significant advantages in having access to a clear 
| representation of the interface provided by the Standard Library. 

The clear representation of the interface provided by the standard
library is the description of the standard library in the standard.
Failing that, the documentation accompanying your implementation or a
good book on the standard library (there are many of them out there).

Looking underneath is definitely not.

| I am certain one of the most important roles Stroustrup believes header files 
Stroustrup did not speak of header files.  Please don't denature what
he was saying.

| should play is that of providing an interface to the user (or implementer) 
| for the items declared in the header. That means in a human readable form.  I 
| can provide quotes on this if it will help.  Chapter 9 is one place were he 
| expresses such ideas.

Section §9.3 talks about use of "header files".  This is directed at
*you* as a C++ user who organize your code or your library.  It is
not directed to implementations.  As I said, the standard header need
not be files.

| This is a concept held rather passionately by may participants of the 
| comp.lang.c++.  If you doubt this, try posting under an alias challenging the 
| notion.

I believe, I know what a header file is.  But, nothing you've said so
far supports what you stated.  I suspect a deep confusion on your part
about a standard header and a header file.  A standard header may be
implemented in terms of header files, but that is not a requirement.
And even if it is implemented in terms of header files, you have no
business in knowing how many of them (files) are used and in what
combination.  You're better served at sticking yourself at the
documented abstract level.

-- Gaby 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]