This is the mail archive of the
mailing list for the GCC project.
RE: V3 PATCH: Insert `typename' and `ios_base::' where required
- To: 'Gabriel Dos Reis' <gdr at codesourcery dot com>, Mark Mitchell <mark at codesourcery dot com>
- Subject: RE: V3 PATCH: Insert `typename' and `ios_base::' where required
- From: Greg Bumgardner <bumgard at roguewave dot com>
- Date: Thu, 15 Feb 2001 23:19:00 -0800
- Cc: rth at redhat dot com, gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
I submitted a flurry patches yesterday that addressed several of these
issues (including the typename and ios_base stuff). I've been compiling some
code on top of V3 for several days with -Wall -Werror and -pedantic and
submitted several bug reports for non-standard or invalid code. I've been
instantiating all of the _CharT related stuff using uint16_t as the
character type, using class of my own design for the _stateT type, and
custom specializations for char_traits and codecvt stuff. Since I was
forcing quite a few new instantiations I needed to include all of the .tcc
files, and even the c++io.cc in the platform-specific include directory.
Needless to say, this produced quite a few warnings and uncovered several
As for the variable length array stuff, I originally changed it to use
dynamic allocation (and still have that code in my local repository) but
instead opted to go the __extension__ route, not knowing that this would be
ignored during instantiation. I thought I had tested it, but I may have
dropped some of the warning options when I changed my builds options to
workaround a different problem in the compiler.
From: Gabriel Dos Reis [mailto:email@example.com]
Sent: Thursday, February 15, 2001 10:23 PM
To: Mark Mitchell
Cc: firstname.lastname@example.org; email@example.com; firstname.lastname@example.org;
Subject: Re: V3 PATCH: Insert `typename' and `ios_base::' where required
Mark Mitchell <email@example.com> writes:
| >>>>> "Gabriel" == Gabriel Dos Reis <firstname.lastname@example.org> writes:
| Gabriel> Yes, we do: CharT is a POD.
| Okie-dokie. I didn't know that. Where is that in the standard?
Most of the vocabulary used in the library is defined in section 17.1.
in clauses 21, 22 and 27, means any object which, when treated
sequentially, can represent text. The term not only mean `char' and
'wchar_t'; but any value that can be represented by a type that
provides the definitions specified in these clauses.
17.1.3 Character container type
a class or a type to represent a character (17.1.2). It is used for
one of the template parameters of the string and iostream class
template. A character container shall be a POD (3.9) type.
Later, 21/1 says:
This clause describes components for manipulating sequences of
"characters" where characters may be of any POD (3.9) type [...]
and so on...
CodeSourcery, LLC http://www.codesourcery.com