This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [RFC] libstdc++/6720 and libstdc++/6671
Phil Edwards <phil@jaj.com> writes:
| On Tue, May 21, 2002 at 08:26:21PM +0200, Gabriel Dos Reis wrote:
| > Neil Booth <neil@daikokuya.demon.co.uk> writes:
| > |
| > | I don't agree with your solution of special-casing certain header names,
| >
| > It is not me who is special-casing certain header names. That special
| > meaning of certain headers are built into the language. Failure to
| > provide the expected meaning is failure to implement the language.
| > Actually, what I'm suggesting is not an invention in the area of
| > compiler builduing. Existing compilers do deliver that standard
| > meaning (actually, they have integrated meaning ofthe headers).
|
| I just had this conversation with another colleague yesterday; we agreed
| that a compiler would be Really Really Cool if it saw
|
| #include <vector>
|
| and then turned all std::vector operations into builtin array operations,
| i.e., with no actual .h files involved anywhere. Open-coding the entire
| vector class.
That is true and I agree that optimization might be useful (James Kanze
told me he worked in the past with a C or C++ compiler having similar
capabilities).
But that isn't really my primary concern here. I'm arguing that the
compiler should be robust and should deliver expected semantics.
There start to have been having lots of bits/*.h in unrelated
projects, and the compiler shouldn't be side-tracked by unfortunate
files and directory clashes.
On another level, we agreed that the std::rel_ops:: content should not
disturb the normal semantics, that is also true for standard headers.
| (We also decided that debugging this would be a PITA.)
Completely agreed. And I think the project would be involved :-)
-- Gaby