2007-10-18 Benjamin Kosnik <[EMAIL PROTECTED]>
Removal of pre-ISO C++ items from include/backwards.
* include/Makefile.am (backward_headers): Remove all but
strstream,
backward_warning.h.
* include/Makefile.in: Regenerate.
* include/backward
Richard Guenther wrote:
> 2007-10-18 Benjamin Kosnik <[EMAIL PROTECTED]>
>
> Removal of pre-ISO C++ items from include/backwards.
> * include/Makefile.am (backward_headers): Remove all but
> strstream,
> backward_warning.h.
> * incl
On Wed, Oct 24, 2007 at 05:32:12PM -0700, Mark Mitchell wrote:
> Richard Guenther wrote:
> > 2007-10-18 Benjamin Kosnik <[EMAIL PROTECTED]>
> >
> > Removal of pre-ISO C++ items from include/backwards.
> > * include/Makefile.am (backward_header
Joe Buck <[EMAIL PROTECTED]> writes:
| On Wed, Oct 24, 2007 at 05:32:12PM -0700, Mark Mitchell wrote:
| > Richard Guenther wrote:
| > > 2007-10-18 Benjamin Kosnik <[EMAIL PROTECTED]>
| > >
| > > Removal of pre-ISO C++ items from include/backwards.
|
On Thu, 2007-10-25 at 07:59 -0500, Gabriel Dos Reis wrote:
> 'deprecated' in the standard does not carry much semantics weight,
> unless the feature is also removed. But, even then we would have to
> worry about existing codes that were written using the feature. That
> is one of the reasons wh
skaller wrote:
I think this is the wrong idea. Deprecated does carry a lot
of weight. It allows a new compiler without a legacy
to elide the feature and specify it is ISO compliant
'minus' the deprecated features, which is quite different
from 'non-compliant'.
are you sure? I thought conforman
On Thu, 2007-10-25 at 11:37 -0400, Robert Dewar wrote:
> skaller wrote:
>
> > I think this is the wrong idea. Deprecated does carry a lot
> > of weight. It allows a new compiler without a legacy
> > to elide the feature and specify it is ISO compliant
> > 'minus' the deprecated features, which is
On Fri, 26 Oct 2007, skaller wrote:
|
| On Thu, 2007-10-25 at 07:59 -0500, Gabriel Dos Reis wrote:
|
| > 'deprecated' in the standard does not carry much semantics weight,
| > unless the feature is also removed. But, even then we would have to
| > worry about existing codes that were written us
On Fri, 26 Oct 2007, skaller wrote:
|
| On Thu, 2007-10-25 at 11:37 -0400, Robert Dewar wrote:
| > skaller wrote:
| >
| > > I think this is the wrong idea. Deprecated does carry a lot
| > > of weight. It allows a new compiler without a legacy
| > > to elide the feature and specify it is ISO comp
On Thu, 2007-10-25 at 12:40 -0500, Gabriel Dos Reis wrote:
> | I think this is the wrong idea. Deprecated does carry a lot
> | of weight. It allows a new compiler without a legacy
> | to elide the feature and specify it is ISO compliant
> | 'minus' the deprecated features, which is quite differen
On Fri, 26 Oct 2007, skaller wrote:
|
| On Thu, 2007-10-25 at 12:40 -0500, Gabriel Dos Reis wrote:
|
| > | I think this is the wrong idea. Deprecated does carry a lot
| > | of weight. It allows a new compiler without a legacy
| > | to elide the feature and specify it is ISO compliant
| > | 'minu
On Thu, 2007-10-25 at 13:41 -0500, Gabriel Dos Reis wrote:
> On Fri, 26 Oct 2007, skaller wrote:
>
> |
> | On Thu, 2007-10-25 at 12:40 -0500, Gabriel Dos Reis wrote:
> |
> | > | I think this is the wrong idea. Deprecated does carry a lot
> | > | of weight. It allows a new compiler without a leg
On Thu, 25 Oct 2007, Gabriel Dos Reis wrote:
> 'deprecated' in the standard does not carry much semantics weight,
> unless the feature is also removed. But, even then we would have to
> worry about existing codes that were written using the feature.
I have to admit I am also surprised about the u
On 10/25/07, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> I have to admit I am also surprised about the use of "deprecated" in
> the context of removing these headers. My previous understanding was
> that we'd announce deprecation (and issue warnings) for at least one
> major release before actuall
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: wha
Gerald Pfeifer 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.
>
> S
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
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'
On Thu, Oct 25, 2007 at 02:48:09PM -0700, Mark Mitchell wrote:
> Gerald Pfeifer 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 s
On Thu, 2007-10-25 at 22:56 +0100, Jonathan Wakely wrote:
> On 25/10/2007, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> The plan is to also move auto_ptr and the old bind1st/bind2nd function
> binders to backward, if/when they are deprecated in C++0x, which would
> give them the same status as (d
On Thu, 2007-10-25 at 15:49 -0700, Joe Buck wrote:
> People that put out distributions are rightly irritated when we pull stuff
> like this. It's not even good enough to change "ext" to "backward", now
> you need an autoconf test to find the fine header, so your program
> compiles with both olde
On Fri, 26 Oct 2007, skaller wrote:
| I should point out retaining 'old' features can create a
| significant maintenance burden for gcc developers,
In this specific case, what are they?
-- Gaby
Gabriel Dos Reis wrote:
> On Fri, 26 Oct 2007, skaller wrote:
>
> | I should point out retaining 'old' features can create a
> | significant maintenance burden for gcc developers,
>
> In this specific case, what are they?
The maintenance burden argument always used to remove stuff. I've used
it
On Thu, 2007-10-25 at 20:34 -0500, Gabriel Dos Reis wrote:
> On Fri, 26 Oct 2007, skaller wrote:
>
> | I should point out retaining 'old' features can create a
> | significant maintenance burden for gcc developers,
>
> In this specific case, what are they?
You're in a better position than me to
On Thu, Oct 25, 2007 at 08:17:58PM -0700, Mark Mitchell wrote:
> The maintenance burden argument always used to remove stuff. I've used
> it myself plenty of times. Sometimes, it really is too painful. But,
> sometimes -- and, again, I consider myself guilty -- we've ripped things
> out under th
On Fri, Oct 26, 2007 at 11:06:43AM +1000, skaller wrote:
> The compiler is expected to conform to the specified standard
> and the standard libraries are an intrinsic part of the
> standard, and IMHO it would be good practice to allow
> 'strict' conformance to an older standard, whilst still
> reje
On Thu, 25 Oct 2007, Joe Buck wrote:
> Has anyone checked yet on the impact on a Debian distribution of
> these proposed changes (and even for things that are checked in,
> they should only be thought of as "proposed" at this point)?
I re-built openSUSE with both changes and the ext/ stuff causes
On Fri, 26 Oct 2007, skaller wrote:
|
| On Thu, 2007-10-25 at 20:34 -0500, Gabriel Dos Reis wrote:
| > On Fri, 26 Oct 2007, skaller wrote:
| >
| > | I should point out retaining 'old' features can create a
| > | significant maintenance burden for gcc developers,
| >
| > In this specific case, w
On Thu, 25 Oct 2007, Joe Buck wrote:
> > Has anyone checked yet on the impact on a Debian distribution of
> > these proposed changes (and even for things that are checked in,
> > they should only be thought of as "proposed" at this point)?
On Fri, Oct 26, 2007 at 10:21:57AM +0200, Richard Guenthe
On 26/10/2007, skaller <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-10-25 at 22:56 +0100, Jonathan Wakely wrote:
> > The plan is to also move auto_ptr and the old bind1st/bind2nd function
> > binders to backward, if/when they are deprecated in C++0x, which would
> > give them the same status as (depr
On Fri, 2007-10-26 at 19:41 +0100, Jonathan Wakely wrote:
> On 26/10/2007, skaller <[EMAIL PROTECTED]> wrote:
> > This would not be correct. When you deprecate C++2000 features,
> > you should retain them in such a way that a compiler switch
> > such as --std=C++2000 will ensure they're visible i
31 matches
Mail list logo
