Re: Standard header format.

["Steven T. Hatton" <hattons at globalsymmetry dot com>]

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

On Wednesday 09 June 2004 00:47, Dhruv Matani wrote:
> On Wed, 2004-06-09 at 09:03, Steven T. Hatton wrote:

> > There is a catch all "as if" rule.  That is 1.9 paragraph 1, and footnote
> > 5. You  are correct about the requirements of the Standard. I do not
> > claim libstdc++ is not conforming to the Standard.  Am I suggesting the
> > Standard /should/ require the Standard Headers should be self-describing?
>
> 1. Why do you want the header files to be self-describing apart from the
> fact that probably you like me do not own a library reference, and have
> learned most of it by looking at the library code.

I do happen to own Josuttis's  _The C++ Standard Library - A Tutorial and 
Reference_, as well as TC++PL(SE), with its lengthy treatment of the Standard 
Library.  Additionally, I have the actual ISO/IEC 14882:2003(E) which serves 
as my primary reference.

I /do/ believe a presentation of the interface to libstdc++ in the form 
presented in the Standard would be useful as a human readable resource.  But, 
as I've stated before, that is a minor issue.

> Ok, library code 
> examination is very helpful, at least it was for me, when I first
> satrted out. It helped me not only get the interfaces right, but also a
> *possible* real-world impl.

I've looked at it several times, and it has helped me become familiar with the 
use of templates, and has also given me an idea of the interface it is 
actually providing.  I have to agree with the person who argued that it is 
probably unintelligible to the uninitiated. There are parts of the 
implementation that are clearly not an immediate representation of an 
interface useful to me.

> 2. You want to implement auto-completion in some editor, and you want to
> parse the headers. This approach has 3 advantages:
> 	1. No hard work on your part to get each interface function and
> hard-code it.

It's not just me.  I'm not likely to be the person doing that actual 
implementation.  I just think it would make the task easier for anyone trying 
to implement such a feature.  It also goes beyond code completion.

> 	2. Your parsing code will work for all code, not only library code.

The parsing code /does/ work for other libraries.  But you have hit a 
philosophical issue that I believe is worth addressing.  I believe the 
Standard Library implementation should be as much like any other library 
implementation as as possible.  Indeed, it should stand as an example, rather 
than an exception.  I know this is far easier said than done.

> 	3. You can expose any non-standard interfaces to the user that the
> library provides.

Add to that the idiosyncracies of the implementation in places where the 
standard forces implementations to find their own solution.  There may also 
be some minor deviation from the standard due difficulties in implementing 
every feature.
 
> The disadvantages are:
>
> 1. Nightmare for the library maintainers.

One might argue that it would actually lead to a more coherent architecture.  
But that is only an intuitive inclination of mine, not a rational conclusion.

>1. They work part-time and for free, so, nothing can be imposed upon
> them.

I don't know the whole picture, or who is or isn't getting paid.  IBM 
supposedly put $1,000,000,000 behind Linux, and open source.  Where did it 
all go? Advertising? I'm certainly not getting paid for what I've been doing.

> 2. the header parsing thingy doesn't quite work well, but it has been
> down by doxygen!

If it can be done by doxygen, it can be done.  As I've said, I don't care if 
it is presented as actual files or 'as if' it were actual files.  I've built 
the doxygen docs, and I know what you mean.

> So, probably, the advantages < disadvantages, so the approach has gained
> acceptance.

I am more than willing to accept the answer that it presents more of a 
challenge than can be met by available resources.


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

iD8DBQFAx07SwX61+IL0QsMRAhSjAJwNJXgXrmGvqACikAAofGE29nTcLgCg8YvM
7Yp6gFyds+i2snyDEhCXrY0=
=RQ00
-----END PGP SIGNATURE-----