Re: [Patch] Fix ac_c99_complex configury

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Paolo Carlini <pcarlini@suse.de> writes:

| Gabriel Dos Reis wrote:
| 
| >| Means adding "old iostreams members", *members*, *not headers*: that is,
| >| the various typedefs in D.6/1, stossc() in /7, etc., etc. Really, I
| >| think you are forcing the text to say *much* more than it says.
| >
| >But just look at what other implementers do.  If you believe this is
| >my invention, why don't you ask on the -lib reflector for existing
| >practice?
| >
| We are talking about the standard, not the other implementations, here.

Yes, but the standard does not exist in the void.  
<iostream.h> predates the standard and establishes existing semantics,
sufficiently high enough to warrant a compatibility appendice.

Many C++ programmers out there expect <iostream.h> to come with a
usable C++ implementation, whether you like it or not.  Just google
for the recuring questions about <iostream.h> on C++ newsgroups to find
out people expectations.  There are still software out there that uses
<iostream.h> and for several reasons, you cannot expect them to be
changed in that respect -- that is part of living with history.  The 
<iostream.h> case is very pecular in the sense that, long before we
ever got a standard library, it was the only one (assuming we don't
back enough to hit <stream.h> ;-)) -- presumably with <iomanip.h> and
friends -- that were described consistently in almost all books on
C++.  It is not a random header.  Lots of software are written against
it -- and interestingly enough (and to my surprise), most of them are
still working untouched.  It does not seem to pose any maintainance
burden (like the ones you mind in the compiler front-end).
I don't think it is reasonable to go and remove it, just because you
think the standard does not thalk about it. 
I wish the world is perfect and or we had a time travel machine, but
realistically we don't and the world probably isn't.

The reason I suggested asking on the -lib reflector for existing
practice is precisely because you get most if not all of library
implementers there. 

| If you want to get directions from the standard about this matter, the

It is not getting directions from the stdnard, but getting feedback
from the standard library implementers.  Do you know of a better forum
to find them?

| standard is defective, we don't need to ask the reflector about this.
| Also, we don't need to ask the reflector or elsewhere, about other
| implementations, because *I* told you about ICC/Dinkum. But this is
| another side, which brings us to...

but ICC/Dinkum is not the only one outside GCC.

and if you look at Sun CC, you'll get to <iostream.h>. Because
Dinkumware is not the only other standard library implementer you have
out there, it makes the most sense to ask on a forum where you find
the library implementors.  -lib is certainly a natural place.  If you
know of any other place please let me know.

| >| I can give you any answer, and of course I agree that there are
| >| currently problems in this area. A *completely* different issue,
| >| however, is whether the proper fix involves removing a subset of the
| >| backward headers. As already mentioned, that choice is only *a* choice,
| >| not the only possible choice, as a matter of fact.
| >
| > What problems do you see with the other headers? 
| >  
| >
| ... Dinkum provides the complete set, including <complex.h> and
| everything. Either we pay attention to the actual practice outside of
| GCC or not. Before deciding unilaterally to do something different and
| not regulated by the standard I'm asking that we explore thoroughly the
| other options.

I'm not suggesting we do not explore other options.  You suggested
removing other files.  The question I asked was very simple: What
problem that does solution/option solve?  Tellign me it is another
option does not give a clue of the problem it solves.  

-- Gaby