Re: func return question
On Jun 30, 9:17 pm, Pete Becker <p...@versatilecoding.com> wrote:
On 2010-06-30 15:57:44 -0400, mzdude said:
On Jun 30, 10:50 am, Pete Becker <p...@versatilecoding.com> wrote:
Exception specifications are deprecated in C++0x. That
doesn't mean that their meaning has changed, nor that you
shouldn't use them. It's a warning that in some future
standard they might be removed.
Which to most people means don't use them, since they could
go away at any time.
Well, yes, if "any time" means "maybe after publication of a
later standard". Certainly not for at least five years.
More than that, actually. I don't think that the committee can
begin considering a new version of the standard before five
years after the previous version has been published. Which
hasn't happened yet.
In theory, "deprecated" is little more than a statement of
intent. If even that. The committee *could* change any major
language feature, deprecated or not. (If I'm not mistaken, the
current draft removes "export", even though it was never
deprecated. But keeps [io]strstream, even though that was
deprecated.)
In practice, at least in other languages, deprecated features
don't disappear from the standard for at least 20 years. And
implementors don't actually remove them for a long time after
that. (I seem to recall reading that Fortran 66 deprecated
"EQUIVALENCE", but I'm willing to bet that most, if not all
Fortran compilers today still support it.) Generally speaking:
if the deprecation is because the feature wasn't generally
supported anyway, or wasn't considered useful, and there is no
good replacement, I'd avoid it. Otherwise, for things like an
empty exception specification, or auto_ptr, I wouldn't hesitate
using it in new code, since my compilers don't support the
replacement, and knowing that I'll probably have to modify it
sometime in the next fourty or fifty years.
--
James Kanze