Fri Jan 4 23:40:00 GMT 2002
On Sat, Jan 05, 2002 at 06:57:18AM +0100, Gabriel Dos Reis wrote:
> Phil Edwards <email@example.com> writes:
> | On Fri, Jan 04, 2002 at 09:56:45PM +0000, Nathan Myers wrote:
> | > The committee's political hackery certainly didn't touch on why
> | > they are needed. (Anyway the discussion at the time assumed that
> | > the actual filenames would continue to be extended; the canonical
> | > comment was that "they are header names, not files; it's the
> | > implementation's job to provide a set of declarations when it sees
> | > include <foo>, and it's none of our business how".)
> | Here's a simple proposal to make everyone happy:
> | 1) Leave the standard headers where they are (in std not bits), and
> | rename them in place from foo to std_foo.h. Essentially moving
> | std_foo.h from bits to std, just spread out over a couple of days.
> | 2) Change include/Makefile.am to that when the staging headers are
> | created, they are done with standard names:
> | include/foo -> ...../include/std/std_foo.h
> What type of problems is that supposed to solve? I've heard of syntax
> highlighting, that argument isn't one since .h files are interpreted
> as C header files, not C++ one. Find? if all standard headers follow
> the same policy, that doesn't make any difference whether they are
> extensionless or not.
I agree that Phil's suggestion doesn't help to solve the problems I'm
The problem is the proliferation of extensionless names. Can I count
on anybody to keep up-to-date a complete list of all the sources and
their types in conveniently machine-readable form? The filename
extensions had done that for us, and for our tools, automatically.
> Since this list has seen unnecessary inflammatory rhetorics on that
> issue, I would like to see at least one compelling reason justifying
> those inflammatory rhetorics.
The long-standing written policy is to maintain filename extensions.
It seems to me that the burden of proof should be upon those arguing
to abandon this industry-wide organizational tool.
So far I have only seen vague remarks about "elegance" and
"consistency". Nobody has offered any examples of how those claimed
qualities lead to any good practical consequence. Nobody has offered
any comprehensive substitute for the mechanism we have used. All we
get are idiosyncratic, incomplete workarounds for each problem as it
Think: why have the none of the Linux, XFree86, BSD, Apache, Perl,
Mozilla, Gnome, Emacs, Glibc -- or even Gcc -- projects abandoned
these archaic, inelegant filename extensions? Does anyone imagine
any of them following our lead?
We already have a comprehensive solution, and we we need only avoid
abandoning it. It is all too easy for a big project like libstdc++
to turn into unmaintainable mush; it happens one little mistaken
choice at a time.
ncm at cantrip dot org
More information about the Libstdc++