Recently asserted on the boost mailing list:
   "I think you misunderstand the standard. The presence of "throw()" on a
   signature in the standard does not actually imply that an
   exception-specification must be present. It is a shorthand way of saying
   "will not throw an exception". This is a confusing notation, but don't
blame
   me (please): I didn't invent it."


Is this true?  If so, can someone provide a citation?  Thanks...


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Jonathan H Lundquist" <jhl@sssonline.com> wrote in message
news:yHQX6.1$ps6.4373@news03.micron.net...
> Recently asserted on the boost mailing list:
>    "I think you misunderstand the standard. The presence of "throw()" on a
>    signature in the standard does not actually imply that an
>    exception-specification must be present. It is a shorthand way of
saying
>    "will not throw an exception". This is a confusing notation, but don't
> blame
>    me (please): I didn't invent it."
>
>
> Is this true?  If so, can someone provide a citation?  Thanks...

Well, you can't just do it by citation, because it isn't explicit in the
standard. Its one of those things you have to infer from what's missing. The
best I can do is 8.3.5:

The return type, the parameter type list and the cv-qualifier-seq, but not
the default argu-
ments (8.3.6) or the exception specification (15.4), are part of the
function type. [Note: function types are
checked during the assignments and initializations of pointer-to-functions,
reference-to-functions, and
pointer-to-member-functions. ]

The real issue is that there's no way for a conforming program to detect
whether the implementation has got the throw(). One of a few reasons is that
no functions decorated with throw() in the standard call any user-supplied
functions that are allowed to throw. So, by the AS-IF rule, the throw() is
not required.

-Dave


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

David Abrahams wrote in message <9gr6dk$8t5$1@bob.news.rcn.net>...
>
>"Jonathan H Lundquist" <jhl@sssonline.com> wrote in message
>news:yHQX6.1$ps6.4373@news03.micron.net...
>> Recently asserted on the boost mailing list:
>>    "I think you misunderstand the standard. The presence of "throw()" on
a
>>    signature in the standard does not actually imply that an
>>    exception-specification must be present. It is a shorthand way of
>saying
>>    "will not throw an exception". This is a confusing notation, but don't
>> blame
>>    me (please): I didn't invent it."
>>
>>
>> Is this true?  If so, can someone provide a citation?  Thanks...
>
>Well, you can't just do it by citation, because it isn't explicit in the
>standard.
[snip]
>The real issue is that there's no way for a conforming program to detect
>whether the implementation has got the throw(). One of a few reasons is
that
>no functions decorated with throw() in the standard call any user-supplied
>functions that are allowed to throw. So, by the AS-IF rule, the throw() is
>not required.

I agree, but think this is against the actual wording of the standard....
To quote:-
"[lib.res.on.exception.handling] 17.4.4.8 Restrictions on exception handling

1 Any of the functions defined in the C++ Standard Library can report a
 failure by throwing an exception of the type(s) described in their Throws:
 paragraph and/or their exception   specification (15.4). An implementation
 may strengthen the exception   specification for a function by removing
 listed exceptions.175)
__________________
175) That is, an implementation of the function will have an explicit
 exception   specification that lists fewer exceptions than those specified

 in this International Standard. It may not, however, change the types
 of exceptions listed in the exception   specificiation from those

 specified, nor add others."

I think _removing_ a throw() spec weakens the exception-specification.
Pehaps the case of the empty throw spec needs to be explicitly noted?

Roger Orr
--
MVP


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

David Abrahams wrote:

> "Jonathan H Lundquist" <jhl@sssonline.com> wrote in message
> news:yHQX6.1$ps6.4373@news03.micron.net...
> > Recently asserted on the boost mailing list:
> >    "I think you misunderstand the standard. The presence of "throw()" on a
> >    signature in the standard does not actually imply that an
> >    exception-specification must be present. It is a shorthand way of
> saying
> >    "will not throw an exception". This is a confusing notation, but don't
> > blame
> >    me (please): I didn't invent it."
> >
> >
> > Is this true?  If so, can someone provide a citation?  Thanks...
>
> Well, you can't just do it by citation, because it isn't explicit in the
> standard. Its one of those things you have to infer from what's missing.

It pretty much is explicit.
-----------------------------------------------------------------------------
15.4 Exception specification
1 A function declaration lists exceptions that its function might directly
  or indirectly throw by using exception-specification as a suffix of
  its declarator.

    exception-specification:
            throw ( type-id-list opt )

  [snip]

8 Whenever an exception is thrown and the search for a handler encounters
  the outermost block of a function with an excpetion-specification, the
  function unexpected() is called (15.5.2) if the exception-specification
  does not allow the exception.

  [snip]

11 A function with no exception-specification allows all exceptions. A
   function with an empty specification, throw(), does not allow any exception.
-----------------------------------------------------------------------------

Can not get more explicit then 11 ...

Matvei.


> The
> best I can do is 8.3.5:
>
> The return type, the parameter type list and the cv-qualifier-seq, but not
> the default argu-
> ments (8.3.6) or the exception specification (15.4), are part of the
> function type. [Note: function types are
> checked during the assignments and initializations of pointer-to-functions,
> reference-to-functions, and
> pointer-to-member-functions. ]
>
> The real issue is that there's no way for a conforming program to detect
> whether the implementation has got the throw(). One of a few reasons is that
> no functions decorated with throw() in the standard call any user-supplied
> functions that are allowed to throw. So, by the AS-IF rule, the throw() is
> not required.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"A function that will throw no exceptions can be declared with an empty
list:
    int g() thorw(); // no exception thrown"
p. 376 of C++ Programming Language, 3rd edition, by Bjarne Stroustrup.

regards,
Kurt

"Jonathan H Lundquist" <jhl@sssonline.com> wrote in message
news:yHQX6.1$ps6.4373@news03.micron.net...
> Recently asserted on the boost mailing list:
>    "I think you misunderstand the standard. The presence of "throw()" on a
>    signature in the standard does not actually imply that an
>    exception-specification must be present. It is a shorthand way of
saying
>    "will not throw an exception". This is a confusing notation, but don't
> blame
>    me (please): I didn't invent it."
>
>
> Is this true?  If so, can someone provide a citation?  Thanks...
>
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Roger Orr wrote:
...
> I think _removing_ a throw() spec weakens the exception-specification.

It does. However, can you show an way that legal code could detect that
removal for any of the relevant functions? If not, then it's covered by
the as-if rule.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Jonathan H Lundquist wrote:
>
> Recently asserted on the boost mailing list:
>    "I think you misunderstand the standard. The presence of "throw()" on a
>    signature in the standard does not actually imply that an
>    exception-specification must be present. It is a shorthand way of saying
>    "will not throw an exception". This is a confusing notation, but don't
> blame
>    me (please): I didn't invent it."
>
> Is this true?  If so, can someone provide a citation?  Thanks...

17.4.4.8: "Any of the functions defined in the C++ Standard Library can
report a failure by throwing an exception of the type(s) described in
their Throws: paragraph and/or their _exception-specification_ (15.4).
An implementation may strengthen the _exception-specification_ for a
function by removing listed exceptions. 175)"

Now, a missing exception-specification is weaker than any explicit
exception specification. Therefore, while the exception-specification
given in the standard is not necessarily the same as the actual
exception-specification, I don't see how it could be removed, except by
application of the as-if rule.

However, Johnathon Lundquist appears to be correct when he says that all
of the C++ standard library functions with "throw()" specifications seem
to be covered by that precisely that exception. The only functions that
have been given throw() specifications are precisely the ones that don't
need to protect against exceptions thrown by user-written code.
Therefore, there's no way to tell what their throw-specifications are.

The closest I came to finding one that wasn't was
std::auto_ptr::~auto_ptr(), which calls the pointed-at object's
destructor. However, 17.4.3.6 says that "... the effects are undefined
... if any ... destructor operation throws an exception ...", so no
legal code has any way to find out whether it has a throw specification.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Roger Orr" <rogero@howzatt.demon.co.uk> wrote in message
news:993077189.3470.0.nnrp-14.9e98aa01@news.demon.co.uk...
>
> David Abrahams wrote in message <9gr6dk$8t5$1@bob.news.rcn.net>...
> >
> >"Jonathan H Lundquist" <jhl@sssonline.com> wrote in message
> >news:yHQX6.1$ps6.4373@news03.micron.net...
> >> Recently asserted on the boost mailing list:
> >>    "I think you misunderstand the standard. The presence of "throw()"
on
> a
> >>    signature in the standard does not actually imply that an
> >>    exception-specification must be present. It is a shorthand way of
> >saying
> >>    "will not throw an exception". This is a confusing notation, but
don't
> >> blame
> >>    me (please): I didn't invent it."
> >>
> >>
> >> Is this true?  If so, can someone provide a citation?  Thanks...
> >
> >Well, you can't just do it by citation, because it isn't explicit in the
> >standard.
> [snip]
> >The real issue is that there's no way for a conforming program to detect
> >whether the implementation has got the throw(). One of a few reasons is
> that
> >no functions decorated with throw() in the standard call any
user-supplied
> >functions that are allowed to throw. So, by the AS-IF rule, the throw()
is
> >not required.
>
> I agree, but think this is against the actual wording of the standard....

<snip>
>
> I think _removing_ a throw() spec weakens the exception-specification.

Correct.

> Pehaps the case of the empty throw spec needs to be explicitly noted?

No, there is no special case. This is all covered by 1.9:

5 A conforming implementation executing a well-formed program shall produce
the same observable behav-
ior as one of the possible execution sequences of the corresponding instance
of the abstract machine with
the same program and the same input. However, if any such execution sequence
contains an undefined
operation, this International Standard places no requirement on the
implementation executing that program
__________________
5) This provision is sometimes called the ``as-if'' rule, because an
implementation is free to disregard any requirement of this Interna-
tional Standard as long as the result is as if the requirement had been
obeyed, as far as can be determined from the observable behavior
of the program. For instance, an actual implementation need not evaluate
part of an expression if it can deduce that its value is not used
and that no side effects affecting the observable behavior of the program
are produced.

So if you need a citation, there it is.

-Dave



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Matvei Brodski" <mbrodski@bear.com> wrote in message
news:3B3127A5.AE3BE3A1@bear.com...

> David Abrahams wrote:
>
> > "Jonathan H Lundquist" <jhl@sssonline.com> wrote in message
> > news:yHQX6.1$ps6.4373@news03.micron.net...
> > > Recently asserted on the boost mailing list:
> > >    "I think you misunderstand the standard. The presence of "throw()"
on a
> > >    signature in the standard does not actually imply that an
> > >    exception-specification must be present. It is a shorthand way of
> > saying
> > >    "will not throw an exception". This is a confusing notation, but
don't
> > > blame
> > >    me (please): I didn't invent it."
> > >
> > >
> > > Is this true?  If so, can someone provide a citation?  Thanks...
> >
> > Well, you can't just do it by citation, because it isn't explicit in the
> > standard. Its one of those things you have to infer from what's missing.
>
> It pretty much is explicit.

>   [snip]
>
> 11 A function with no exception-specification allows all exceptions. A
>    function with an empty specification, throw(), does not allow any
exception.
> --------------------------------------------------------------------------
---
>
> Can not get more explicit then 11 ...

And how does that address the OP's question?

-Dave


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

David Abrahams wrote:

> "Matvei Brodski" <mbrodski@bear.com> wrote in message
> news:3B3127A5.AE3BE3A1@bear.com...
>
> > David Abrahams wrote:
> >
> > > "Jonathan H Lundquist" <jhl@sssonline.com> wrote in message
> > > news:yHQX6.1$ps6.4373@news03.micron.net...
> > > > Recently asserted on the boost mailing list:
> > > >    "I think you misunderstand the standard. The presence of "throw()"
> on a
> > > >    signature in the standard does not actually imply that an
> > > >    exception-specification must be present. It is a shorthand way of
> > > saying
> > > >    "will not throw an exception". This is a confusing notation, but
> don't
> > > > blame
> > > >    me (please): I didn't invent it."
> > > >
> > > >
> > > > Is this true?  If so, can someone provide a citation?  Thanks...
> > >
> > > Well, you can't just do it by citation, because it isn't explicit in the
> > > standard. Its one of those things you have to infer from what's missing.
> >
> > It pretty much is explicit.
>
> >   [snip]
> >
> > 11 A function with no exception-specification allows all exceptions. A
> >    function with an empty specification, throw(), does not allow any
> exception.
> > --------------------------------------------------------------------------
> ---
> >
> > Can not get more explicit then 11 ...
>
> And how does that address the OP's question?

Directly, by giving an explicit and unambiguous definition of what throw()
means.
The question was "is that true that the presence of throw() on a signature in
the standard means that the function will ot throw an exception". The answer is
"yes, it does, on a signature in the standard and/or elsewhere".

That is unless we are to assume that some function definitions in the Standard
are
not following the grammar set by the Standard.

Matvei.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"James Kuyper Jr." wrote:
...
> However, Johnathon Lundquist appears to be correct when he says that all

Sorry - I misread the attributions - that should have referred to David
Abrahams.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Matvei Brodski" <mbrodski@bear.com> wrote in message
news:3B31FDF2.30CA6944@bear.com...
>
>
> David Abrahams wrote:

> > And how does that address the OP's question?
>
> Directly, by giving an explicit and unambiguous definition of what throw()
> means.
> The question was "is that true that the presence of throw() on a signature
in
> the standard means that the function will ot throw an exception".

I wasn't answering that question. The question I was answering was ``is it
really true that the presence of "throw()" on a signature in the standard
does not actually imply that an exception-specification must be present''. I
think if you reread the OP, you'll see that it is the same question that was
being asked.

-Dave


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

> Roger Orr wrote:
> > I think _removing_ a throw() spec weakens the exception-specification.

"James Kuyper Jr." <kuyper@wizard.net> writes:
> It does. However, can you show an way that legal code could detect that
> removal for any of the relevant functions? If not, then it's covered by
> the as-if rule.

#include <locale>

bool g(const std::locale &x) throw()
{
  using namespace std;
  bool (*h_facet)(const locale &) throw ();
  h_facet = &has_facet<ctype<char> >;
  return (*h_facet)(x);
}

Is this piece of code valid, if you remove the exception specification
from std::has_facet? The issue 92 of Core language issues list (at
least) appears to make the assignment invalid, if an implementation
removes an exception specification from std::has_facet. Therefore, I
think it's not conforming for an implementation to remove that
exception specification.
--
 Esa Pulkkinen                            | C++ programmers do it virtually
 E-Mail:  esa.pulkkinen@kotiposti.net     | everywhere with class, resulting
 WWW : http://sivut.koti.soon.fi/epulkkin | in multiple inheritance.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Esa Pulkkinen " wrote:
>
> > Roger Orr wrote:
> > > I think _removing_ a throw() spec weakens the exception-specification.
>
> "James Kuyper Jr." <kuyper@wizard.net> writes:
> > It does. However, can you show an way that legal code could detect that
> > removal for any of the relevant functions? If not, then it's covered by
> > the as-if rule.
>
> #include <locale>
>
> bool g(const std::locale &x) throw()
> {
>   using namespace std;
>   bool (*h_facet)(const locale &) throw ();
>   h_facet = &has_facet<ctype<char> >;
>   return (*h_facet)(x);
> }
>
> Is this piece of code valid, if you remove the exception specification
> from std::has_facet? The issue 92 of Core language issues list (at
> least) appears to make the assignment invalid, if an implementation
> removes an exception specification from std::has_facet. Therefore, I
> think it's not conforming for an implementation to remove that
> exception specification.

Issue 92 <http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#92>
is marked as having been tentatively agreed to. However, it's not yet
been made official, and given the use of "tentatively", there's a small
but non-negligible chance that it won't be. Talking strictly in terms of
the current standard, that's perfectly legal code, even if the exception
specification is missing, and therefore an implementation could be
perfectly conforming to the current standard even if it left it out, as
long as it doesn't actually throw anything.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

David Abrahams wrote:

> "Matvei Brodski" <mbrodski@bear.com> wrote in message
> news:3B31FDF2.30CA6944@bear.com...
> >
> >
> > David Abrahams wrote:
>
> > > And how does that address the OP's question?
> >
> > Directly, by giving an explicit and unambiguous definition of what throw()
> > means.
> > The question was "is that true that the presence of throw() on a signature
> in
> > the standard means that the function will ot throw an exception".
>
> I wasn't answering that question. The question I was answering was ``is it
> really true that the presence of "throw()" on a signature in the standard
> does not actually imply that an exception-specification must be present''. I
> think if you reread the OP, you'll see that it is the same question that was
> being asked.

Ok, apparently I am missing something here.
I kind of assumed that if anywhere in standard we see a description of some
function (for example: in 3.7.3, p2 "void operator delete(void*) throw();")
then this description follows grammar rules set by this Standard.
I.e., if standard says: "throw() means - no exceptions...", then that's it
and there can be no other implications. How can it "actually imply that
an exception-specification must be present" if Standard gives it precise
meaning that leaves no space for implications?

Matvei.





---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Matvei Brodski wrote:
>
> David Abrahams wrote:
>
> > "Matvei Brodski" <mbrodski@bear.com> wrote in message
> > news:3B31FDF2.30CA6944@bear.com...
> > >
> > >
> > > David Abrahams wrote:
> >
> > > > And how does that address the OP's question?
> > >
> > > Directly, by giving an explicit and unambiguous definition of what throw()
> > > means.
> > > The question was "is that true that the presence of throw() on a signature
> > in
> > > the standard means that the function will ot throw an exception".
> >
> > I wasn't answering that question. The question I was answering was ``is it
> > really true that the presence of "throw()" on a signature in the standard
> > does not actually imply that an exception-specification must be present''. I
> > think if you reread the OP, you'll see that it is the same question that was
> > being asked.
>
> Ok, apparently I am missing something here.
> I kind of assumed that if anywhere in standard we see a description of some
> function (for example: in 3.7.3, p2 "void operator delete(void*) throw();")
> then this description follows grammar rules set by this Standard.

You're basically correct; though with some modifications. For instance,
the header summaries for the standard containers often contain
"implementation defined" in contexts where strict application of the
grammar would require that phrase to be parsed as two identifiers.
What's clearly intended is that the precise contents of that section be
defined by the implementation.

> I.e., if standard says: "throw() means - no exceptions...", then that's it
> and there can be no other implications. ...

Correct. No one's debating what throw() means in actual code. What's
being debated is whether or not the presence of throw() in the exception
specification shown in the standard, means that there must be a throw()
in the actual declaration. The standard specifically states in 17.3.1.2
that "In some cases the semantic requirements are presented by C++ code.
Such code is intended as a specification of equivalence of a construct
to another construct, no necessarily the way the construct must be
implemented."

> ... How can it "actually imply that
> an exception-specification must be present" if Standard gives it precise
> meaning that leaves no space for implications?

When the standard does leave no space for implications, then no
implications may be drawn, but that's not the case here. Because of
17.3.1.2, there's the possibility that the actual code may be different
from the code provided in the standard. All that matters is that the
code have equivalent effect. If a function throws no exceptions of it's
own, and can't legally be forced to call user-defined code that does
throw an exception, there's no way to tell whether or not it has a
throw() exception-specification. Therefore, an implementor of the
standard library is entitled to leave out the throw().

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Matvei Brodski" <mbrodski@bear.com> wrote in message
news:3B3260E7.FAA32FB8@bear.com...
>
>
> David Abrahams wrote:

> > I wasn't answering that question. The question I was answering was ``is
it
> > really true that the presence of "throw()" on a signature in the
standard
> > does not actually imply that an exception-specification must be
present''. I
         ^^^
> > think if you reread the OP, you'll see that it is the same question that
was
> > being asked.
>
> Ok, apparently I am missing something here.
> I kind of assumed that if anywhere in standard we see a description of
some
> function (for example: in 3.7.3, p2 "void operator delete(void*)
throw();")
> then this description follows grammar rules set by this Standard.

Yes, it is grammatical C++

> I.e., if standard says: "throw() means - no exceptions...", then that's it

True.

> and there can be no other implications.

The standard says a whole bunch of other things about
exception-specifications (e.g. about unexpected handlers, termination, etc).
There could be other implications than simply that the library function
isn't allowed to throw, if for example, a user type was allowed to throw an
exception from within the library function. That would cause termination in
the throw() case.

> How can it "actually imply that
> an exception-specification must be present" if Standard gives it precise
> meaning that leaves no space for implications?

I was not arguing that the standard implies more than meets the eye, only
less. There is less implication than it might at first seem, here.

-Dave



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]