This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: gcc 3.0 cannot compile pooma
- To: Gabriel Dos Reis <gdr at codesourcery dot com>
- Subject: Re: gcc 3.0 cannot compile pooma
- From: "Zack Weinberg" <zackw at stanford dot edu>
- Date: Tue, 5 Jun 2001 21:56:02 -0700
- Cc: Jeffrey Oldham <oldham at codesourcery dot com>, Peter Schmid <schmid at snake dot iap dot physik dot tu-darmstadt dot de>, gcc at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org, pedwards at disaster dot jaj dot com
On Wed, Jun 06, 2001 at 06:28:44AM +0200, Gabriel Dos Reis wrote:
> Jeffrey Oldham <oldham@codesourcery.com> writes:
>
> | 2) Create a separate <string.h> file.
> |
> | <string.h> = <cstring>
> | using std::size_t;
> | using std::memcpy;
> | // ...
> |
> | <cstring> = namespace std {
> | #include "/usr/include/string.h" /* fully-qualified path */
> | }
> |
> | <cstring> must use a fully-qualified path rather than <string.h> to
> | avoid infinite recursion.
> |
> | The latter comes closer to the standard but requires some additional
> | work during creation to resolve the fully-qualified path.
>
> On some plateforms (Robert Lipe could provide data) the actual paths
> depends on the `-ansi -pedantic' or something like that.
>
> Creating <string.h> in terms of <cstring> is what we're supposed to do
> but...
This is exactly what #include_next is for.
But I kind-of think that there's more to it than that. Isn't this
what the c_shadow headers are supposed to be doing, and they don't
work right at the moment?
zw