On Thu, 25 Oct 2007, Jonathan Wakely wrote:
| On 25/10/2007, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
| > On Thu, 25 Oct 2007, Andrew Pinski wrote:
| > > Well technically these headers have been deprecated since at least 3.2
| > > (maybe even back in 3.0) with them producing a warning. So I don't
| > > know if we should move them or not but we have followed our own rules
| > > here.
| >
| > Sorry, I misread the Subject: what disappeared under my back, without any
| > warning nor deprecation period, actually was ext/hash_map and friends.
|
| http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#5_4
| The non-standard hash containers have been deprecated by moving them
| to the backward directory.
|
| The headers that were completely removed were iostream.h etc. (note
| the pre-standard .h extension) which had been in backward for years
| and gave a warning without -Wno-deprecated.
The .h headers are not part of the C++ standards. I don't think I'm
disputing that. My argument was more specific than that.
libstdc++ still supports <strstream>. However, the .h headers did
provide an API that I don't think we should remove. No matter how
long we have been emitting warnings. The reason is they don't pose
any signofocant maintainance problem, they don't interferre with our
supplying a standard conforming compiler. People interested in
compiling codes that don't rely on deprecated stuff know how to get
that. However, removing them only make users disappointed.
-- Gaby
Annex D
(normative)
Compatibility features
1 This clause describes features of the C++ Standard that are
specified for compatibility with existing implementations.
2 These are deprecated features, where deprecated is defined as:
Normative for the current edition of the Standard, but not
guaranteed to be part of the Standard in future revisions.
