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.


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 05 June 2004 15:21, Gabriel Dos Reis wrote:
> "Steven T. Hatton" <hattons@globalsymmetry.com> writes:
[snip]
> 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.

Stroustrup did not say read the documentation of your standard headers.

> 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 really don't care how the interface is generated. Whether it is hard coded 
in actual header files, or generated by some kind of tool per request.

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

If I want to look at documentation that is exactly what I do.  What I am 
talking about is having it available in electronic form to be manipulated 
programmatically the in the way tools for Java (and, I believe C#) process 
electronically available declarations representing interfaces to resources 
such as the system, language defined libraries, or third party libraries. 

> Failing that, the documentation accompanying your implementation 
I'm using GCC, remember.

>or a good book on the standard library (there are many of them out there).

http://www.josuttis.com/libbook/index.html

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

I guess what you are suggesting is that
/home/hattons/opt/org/gnu/gcc-3.3.3/include/c++/3.3.3/vector
is not a header file. That doesn't change my reasoning.

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

No. I've read the Sections in the standard regarding whether the standard 
headers are actually header files or not. I know what it says.  What I am 
saying is that it is a mistake not to provide a representation of the 
interface to the Standard Library as part of the implementation.  Most C++ 
programmers I've been communicating with operate under the assumption that 
the Standard Headers are in fact header files.  Many have suggested looking 
at them to see the interface provided by the Standard Library.  Others have 
stated that they should be, and are, used by IDEs to provide such features as 
code completion, error detection, automatic inclusion of headers, etc.

Did you look at the example of using the facilies provided by Java to access 
interface information for libraries that I reference in my first message? 
I've included it below.  It demonstrates why creating IDEs for Java with the 
modern feature programmers expect is so easy.

/* excerpt form usenet post */
I know it can be unpopular to compare Java to C++, but there are certain
features of Java which C++ lacks, and which give the programmer significant
leverage to exploit available libraries.

I wrote the following bash for the sake of writing this response:

?#!/bin/bash

function jarlist() {
????for?j?in?${CLASSPATH//:/'?'};?do?
????????echo?$j;
????done?
}

function classlist() {
????for?j?in?${CLASSPATH//:/'?'};?do
????????jar?-tf?$j;
????done?
}

function jpgrep() {
????for?j?in?${CLASSPATH//:/'?'};?do
????????h="";
????????h=$(jar?-tf?$j?|?grep?.class$?|?grep?$1)
????????for?c?in?$h;do
?????????????echo?$c;
????????done
????done?
}

function jif() {
????for?j?in?${CLASSPATH//:/'?'};?do
????????h="";
????????h=$(jar?-tf?$j?|?grep?.class$?|?grep?$1)
????????for?c?in?$h;do
????????????test?-n?"$c"?&&?echo?$c?&&?javap?${c%%.class}
????????done
????done?
}
##################### EOF ###################################

If there is a Java class I wish to use in my code, I can put the code listed
above in a file called ~/bin/jq. Source it:
Fri Jun 04 11:45:51:> . jq

If I know the class contains the substring 'System' I type:
Fri Jun 04 11:45:51:> jpgrep System
org/apache/xml/utils/SystemIDResolver.class
org/apache/xpath/functions/FuncSystemProperty.class
org/apache/xmlrpc/SystemHandler.class
org/apache/xindice/core/MetaSystemCollection.class
org/apache/xindice/core/SystemCollection.class

If I want to see the interfaces for each of these, I enter:

org/apache/xml/utils/SystemIDResolver.class
Compiled from "SystemIDResolver.java"
public class org.apache.xml.utils.SystemIDResolver extends java.lang.Object{
????public?org.apache.xml.utils.SystemIDResolver();
????public?static?java.lang.String?getAbsoluteURI(java.lang.String);
???????throws?javax/xml/transform/TransformerException
????public?static?java.lang.String
getAbsoluteURIFromRelative(java.lang.String);
????public?static?java.lang.String
getAbsoluteURI(java.lang.String,java.lang.String);
???????throws?javax/xml/transform/TransformerException
}

org/apache/xpath/functions/FuncSystemProperty.class
Compiled from "FuncSystemProperty.java"
//...
}

org/apache/xmlrpc/SystemHandler.class
Compiled from "SystemHandler.java"
public class org.apache.xmlrpc.SystemHandler extends java.lang.Object
implements org.apache.xmlrpc.ContextXmlR
//..
execute(java.lang.String,java.util.Vector,org.apache.xmlrpc.XmlRpcContext);
???????throws?java/lang/Exception
}

org/apache/xindice/core/MetaSystemCollection.class
Compiled from "MetaSystemCollection.java"
public final class org.apache.xindice.core.MetaSystemCollection extends 
//...

Those results contain everything I need in order to have the class imported
into my current file and to get a pop-up menu of accessible method
invocations and fields, including a parameterlist.

- -- 
Regards,
Steven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFAwipdwX61+IL0QsMRAnAOAJ99vGaDuzcYWpf6SmdWRCpF4G8rdQCdGzb2
J6uHd1X5QlPBKjCaU70QbkE=
=Un7N
-----END PGP SIGNATURE-----


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