Simon Hill wrote: > http://gcc.gnu.org/onlinedocs/gccint/index.html. (Of course I was > horrified to see it's not written in C++, and it's loaded with macros > --- why??).
You seem to refer to g++ as if it's a separate program from gcc but it's really not. All of the middle- and back-end code is shared between the language front-ends, so if you introduce C++ there you now require a pre-existing C++ bootstrap compiler even for people that have no interest or need for C++ language support and are only building a C (or Fortran or Java or Ada) compiler. A lot of people have a problem with that because some systems may not have or even want anything more than a C compiler. You could of course limit use of C++ to the C++ frontend, similar to how the Ada frontend is written in Ada. But I don't think that would do much to alleviate the issue that you're complaining about because it would still have to use all the same macros to represent trees and types and so on to the language independent parts of the compiler. Nevertheless it's a topic that keeps coming up and there are a number of people that would like the advantages of better compile time type checking and so on. This debate always rages on because there is constant fear that it will open the door for the more exotic and unmaintainable C++ features to sneak in, in addition to the higher bootstrap requirements. At the moment there is slow progress in getting things to the point where gcc can at least be built with a C++ compiler. See also the gcc-in-cxx branch. > What I'd like to add is something that I've seen many people request, > and something I really want to use: > Adding a -W option to check that all function calls and throws comply > with the throw() clause of the function they are launched from. You really ought to read the past threads on this topic, for example: <http://gcc.gnu.org/ml/gcc/2007-01/threads.html#00499> <http://gcc.gnu.org/ml/gcc/2007-03/threads.html#01162> <http://gcc.gnu.org/ml/gcc/2007-04/threads.html#00024> <http://gcc.gnu.org/ml/gcc/2007-04/threads.html#00265> The general consensus is that doing this at compile time cannot give you anything useful, because the compiler can only see one compilation unit at a time and so the only thing it can know of all the downstream functions that are in other CUs is what is provided in the exception specifiers of the prototypes. You're essentially trusting that all exception specifiers for every function in the program and *all* library code are always present and always correct which is a huge leap of faith that I don't think is supported by reality. For example the Boost rationale basically says they are unusable in practical code except in special cases: <http://www.boost.org/development/requirements.html#Exception-specification>. > 1) Is my task a sensible one? Is there anything I have got fundamentally > wrong? > 2) Is there anyone currently doing this? I'd hate to simply duplicate > their effort. You should certainly look at EDoc++, mentioned in the above threads. > I can't find much readable documentation about the source. Does anyone > have any good documentation links about the overall program flow > through g++, files/functions etc? I need a primer. Don't neglect the wiki: <http://gcc.gnu.org/wiki/GettingStarted> > 7) To someone new to the g++ source the included documentation seems > pretty poor and cryptic. README mentions non-existant files, > INSTALL/README says it's obsolete and redirects to a file "index.html" > which doesn't yet exist. And why does the documentation have all these > .texi, .info and (unlinked) manpage .1/.7 files. What's wrong with > .txt, .html or similar? Shouldn't documentation be available from the > download instead of having to go online to actually find out how to > build and read the documentation itself - the documentation doesn't > really take up much space. In this age do manpages actually have any > advantages? The documentation's canonical form is texinfo, i.e. gcc/doc/*.texi. Everything else (HTML, PDF, DVI, .info, manpages) is auto-generated from the texinfo, e.g. "make html", "make pdf", etc. Whether the generated files are in your tree depends on whether you're working from a SVN checkout or a release tarball, but the texinfo sources are always there. Brian
