Re: Standard header format.

[Dhruv Matani <dhruvbird at gmx dot net>]

On Wed, 2004-06-09 at 09:03, Steven T. Hatton wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Tuesday 08 June 2004 23:19, Dhruv Matani wrote:
> > Hi,
> > 	Well there's not much I can say, but just that the standard does not
> > even require the standard headers to be files or any such remotely
> > *parsable* (one that can be parsed by a parser) entity. For all you
> > know, it can be compiled files, and the compiler may take care of the
> > the instantiation using some complex machinery.
> > 	Or the standard headers may even be code compiled directly into the
> > compiler proper, and the #include is just a hint to the compiler, and
> > maybe the preprocessor has nothing to do with
> > #include<some_standard_header_name>. I'm not 100% sure about the
> > technical correctness of the above statement, but it seems quite
> > possible from my reading of the standard. There is nothing that says
> > that #include<> directives may be ignored by the pre-processor, and that
> > the compiler can interpret them as long as the user gets a runnable
> > binary/object file.
> >
> > -Dhruv.
> 
> 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. 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.

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.
	2. Your parsing code will work for all code, not only library code.
	3. You can expose any non-standard interfaces to the user that the
library provides.

The disadvantages are:

1. Nightmare for the library maintainers.
	1. They work part-time and for free, so, nothing can be imposed upon
them.
	2. They do a damn good job of:
		a. Keeping the library standard-compliant.
		b. Making sure that there are no performance regressions.
		c. Making sure that the runtime speed of the library components is
optimal in the general case.
	3. The library as it stands right now is is good shape from whatever
limited knowledge that I have.

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

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



-Dhruv.






> Well...yes.
> 
> - -- 
> Regards,
> Steven
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
> 
> iD8DBQFAxoUnwX61+IL0QsMRAr9uAKDeSnlVQSIxjjefPUXqkKKcwAL0BwCfc8hL
> cNVhOxSw0Cs2cll13VFCgoM=
> =G7eq
> -----END PGP SIGNATURE-----
-- 
        -Dhruv Matani.
http://www.geocities.com/dhruvbird/

Proud to be a Vegetarian.
http://www.vegetarianstarterkit.com/
http://www.vegkids.com/vegkids/index.html