Thorsten Ottosen wrote:

> Assume we change exception specs to mean nothing, but require them to
be
> syntactically correct. Then I see these consequences
>
> case 1: BEFORE: the exception-handler calls a user-defined
unexpected() or
> terminate(); AFTER: stack-unwinding + possible terminate()
> case 2: BEFORE: the right exceptions are thrown + perhaps handled;
AFTER: no
> difference.

void foo() throw(bad_alloc, bad_exception){ throw 3.14159; }

case 3: BEFORE: the right exceptions are thrown + perhaps handled;
AFTER: the wrong exceptions are thrown.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Wade wrote:

| Thorsten Ottosen wrote:
|
| > Assume we change exception specs to mean nothing, but require them to
| be
| > syntactically correct. Then I see these consequences
| >
| > case 1: BEFORE: the exception-handler calls a user-defined
| unexpected() or
| > terminate(); AFTER: stack-unwinding + possible terminate()
| > case 2: BEFORE: the right exceptions are thrown + perhaps handled;
| AFTER: no
| > difference.
|
| void foo() throw(bad_alloc, bad_exception){ throw 3.14159; }
|
| case 3: BEFORE: the right exceptions are thrown + perhaps handled;
| AFTER: the wrong exceptions are thrown.

This is really a weird case, isn't it? Anyway, AFAICT, you would
do as follows:

Before:
call unexpected --> which calls terminate()

After:
throw the float exception.

That's a pretty good change in my view.

-Thorsten

--
Thorsten Ottosen
----------------------------
Dezide Aps -- Intelligent Customer Support:
www.dezide.com

Aalborg University --- Decision Support Systems:
http://www.cs.aau.dk/index2.php?content=Research/bss

C++ Boost:
www.boost.org

C++ Standard:
http://www.open-std.org/JTC1/SC22/WG21/



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Peter Dimov wrote:
> stephan.bergmann@sun.com (Stephan Bergmann) wrote in message news:<co44qf$ntc$1@new-usenet.uk.sun.com>...
>
>>Thorsten Ottosen wrote:
>>[...]
>>
>>>Here's a related question: what percentage of the people using exception specs
>>>know they risk to crash the program at runtime?
>>
>>You can also ask the other way round:  What percentage of the people
>>omitting exception specs know they riks to crash the program at runtime?
>>  (Instead of going the safe terminate() route, those parts of the
>>program that do not expect a given exception to pass through them might
>>start to behave unexpectedly.)
>
>
> The parts of the program that expect an exception to pass through them
> (most of the code nowadays) should function correctly regardless of
> the type of the exception.

The problem is with maintaining legacy applications or using legacy
libraries.  I have no idea whether "most of the code nowadays" is robust
enough that any exception might pass through it without problem.  From
my (surely limited) real world experience, I humbly doubt it, however.

-Stephan

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Stephan Bergmann" <stephan.bergmann@sun.com> wrote in message
news:coen8t$nq$1@new-usenet.uk.sun.com...
| Peter Dimov wrote:
| > stephan.bergmann@sun.com (Stephan Bergmann) wrote in message
news:<co44qf$ntc$1@new-usenet.uk.sun.com>...

| > The parts of the program that expect an exception to pass through them
| > (most of the code nowadays) should function correctly regardless of
| > the type of the exception.
|
| The problem is with maintaining legacy applications or using legacy
| libraries.

yes, that is where potential problems could arise if we changed the language.

|  I have no idea whether "most of the code nowadays" is robust
| enough that any exception might pass through it without problem.
| From
| my (surely limited) real world experience, I humbly doubt it, however.

there are two cases here (and it applies to new as well as old code):

1. code is robust and can tolerate any exception.
    ok, no problem, a change in seception specs has no effect

2. code is not robust and cannot tolerate any exception
    you are probably in deep **** then; just consider that operator new
    can throw and you quickly see that most functions can throw. If you
    inspected those functions, would you see that they had
throw(std::bad_alloc)?
    probably not.


-Thorsten


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:

> Ron Natalie wrote:
>
>> John Nagle wrote:
>>
>>> James Dennett wrote:
>>>
>>>> If NDEBUG is defined, the asserts disappear.
>>>
>>>
>>>
>>>
>>>    Is NDEBUG in the standard?
>>
>>
>>
>> Yes.   19.2 of the C++ standard which derives from the C 7.2
>> standard.
>>
>>>
>>>    Some years back, there was a discussion as to whether the
>>> standard allows the compiler to rely on expressions in
>>> "assert" being true, and the consensus was that it does.
>>
>>
>>
>> If disabled via NDEBUG, it must be a void expression statement.
>> Otherwise it's required to do some implementation defined diagnostic
>> and then abort().   I don't think there's any thing that applies
>> specific knowledge about assert, but the compilers can probably
>> assume that abort() and exit() would never return.
>
>
>     I'd regard that as an error in the standard.  Requiring
> execution to continue after passing through a failed "assert()"
> is inappropriate.  At best, it should be undefined behavior.

It's unfortunate, but not as unfortunate as some other examples
such as one ASSERT macro which allows flow to continue even in
debug builds if the user so chooses.

We can't change it now without breaking backwards compatibility
with too much code.  We could add an alternative facility if
there were an acceptable proposal; assert in its current form
is not without problems, though it's still a useful tool.

-- James

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

stephan.bergmann@sun.com (Stephan Bergmann) wrote in message news:<coen8t$nq$1@new-usenet.uk.sun.com>...
> Peter Dimov wrote:
> > stephan.bergmann@sun.com (Stephan Bergmann) wrote in message news:<co44qf$ntc$1@new-usenet.uk.sun.com>...
> >
> >>Thorsten Ottosen wrote:
> >>[...]
> >>
> >>>Here's a related question: what percentage of the people using exception specs
> >>>know they risk to crash the program at runtime?
> >>
> >>You can also ask the other way round:  What percentage of the people
> >>omitting exception specs know they riks to crash the program at runtime?
> >>  (Instead of going the safe terminate() route, those parts of the
> >>program that do not expect a given exception to pass through them might
> >>start to behave unexpectedly.)
> >
> >
> > The parts of the program that expect an exception to pass through them
> > (most of the code nowadays) should function correctly regardless of
> > the type of the exception.
>
> The problem is with maintaining legacy applications or using legacy
> libraries.  I have no idea whether "most of the code nowadays" is robust
> enough that any exception might pass through it without problem.  From
> my (surely limited) real world experience, I humbly doubt it, however.

My point is that if exception type X can pass through code section A
without problems, then exception type Y can do the same.

One situation where the type of the exception matters is when the code
section catches X and assumes that this catch clause makes it nothrow.
In this case, however, the proper exception specification is not
throw(X) on the low-level function, but throw() on the higher level
function, the one making that assumption.

catch(X)+rethrow for cleanup is another possibility, but using
throw(X) specs can only further encourage this style of "programming".

A legacy library that wants a callback that is required to only throw
an exception of type X can be a legitimate example for using an
exception specification on the callback implementation, but I'm not
sure how important is this case in practice. I've never used such a
library.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

If you are going to fiddle with assert, please look at the assert2/assertstr
and verify/verify2/verifystr thread in comp.std.c.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:

>
>     I'd regard that as an error in the standard.  Requiring
> execution to continue after passing through a failed "assert()"
> is inappropriate.  At best, it should be undefined behavior.
>

I don't agree.   The standard for C and C++ clearly states that
NDEBUG disables (and even exlicitly shows the null statement) the
assertion both the test and the abort().   People rely on this.

While one use (the one you're envisioning) for assert is to provide
consistancy checks for "can't happen" conditions that are too expensive
to be left in the production code, there are others as well.

One is to trigger breakpoints.   Abort() raises a signal, which
can be caught or traced in many impelementations.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

stephan.bergmann@sun.com (Stephan Bergmann) wrote in message news:<co44qf$ntc$1@new-usenet.uk.sun.com>...
> Thorsten Ottosen wrote:
> [...]
> > Here's a related question: what percentage of the people using exception specs
> > know they risk to crash the program at runtime?
>
> You can also ask the other way round:  What percentage of the people
> omitting exception specs know they riks to crash the program at runtime?
>   (Instead of going the safe terminate() route, those parts of the
> program that do not expect a given exception to pass through them might
> start to behave unexpectedly.)

The parts of the program that expect an exception to pass through them
(most of the code nowadays) should function correctly regardless of
the type of the exception.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Stephan Bergmann" <stephan.bergmann@sun.com> wrote in message
news:co44qf$ntc$1@new-usenet.uk.sun.com...
| Thorsten Ottosen wrote:
| [...]
| > Here's a related question: what percentage of the people using exception
specs
| > know they risk to crash the program at runtime?
|
| You can also ask the other way round:  What percentage of the people
| omitting exception specs know they riks to crash the program at runtime?
|   (Instead of going the safe terminate() route,

you mean "safe" :-)

| those parts of the
| program that do not expect a given exception to pass through them might
| start to behave unexpectedly.)

exceptions are pervasive in C++ and code should always behave correctly in
their presence.

anyway, I'd be interested in knowinf if anybody relies on these properties. My
feeling is that the mechanism is
generally poorly understood in the rare cases where it is actually known.

-Thorsten


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
> James Dennett wrote:
>
>> If NDEBUG is defined, the asserts disappear.
>
>
>    Is NDEBUG in the standard?

Yes.   19.2 of the C++ standard which derives from the C 7.2
standard.

>
>    Some years back, there was a discussion as to whether the
> standard allows the compiler to rely on expressions in
> "assert" being true, and the consensus was that it does.

If disabled via NDEBUG, it must be a void expression statement.
Otherwise it's required to do some implementation defined diagnostic
and then abort().   I don't think there's any thing that applies
specific knowledge about assert, but the compilers can probably
assume that abort() and exit() would never return.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Ron Natalie wrote:

> John Nagle wrote:
>
>> James Dennett wrote:
>>
>>> If NDEBUG is defined, the asserts disappear.
>>
>>
>>
>>    Is NDEBUG in the standard?
>
>
> Yes.   19.2 of the C++ standard which derives from the C 7.2
> standard.
>
>>
>>    Some years back, there was a discussion as to whether the
>> standard allows the compiler to rely on expressions in
>> "assert" being true, and the consensus was that it does.
>
>
> If disabled via NDEBUG, it must be a void expression statement.
> Otherwise it's required to do some implementation defined diagnostic
> and then abort().   I don't think there's any thing that applies
> specific knowledge about assert, but the compilers can probably
> assume that abort() and exit() would never return.

     I'd regard that as an error in the standard.  Requiring
execution to continue after passing through a failed "assert()"
is inappropriate.  At best, it should be undefined behavior.

    John Nagle
    Animats

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Hi all,

There's a proposal at the standards site, "Toward Improved Optimization
Opportunities in C++0X"
(http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1664.pdf). I
found it interesting, but I had some concerns, so I mailed the authors about
them, but has got no response. Therefore, I thought I'd might raise them,
here, instead, and invite comments on this.

The proposal is about compiler-checked annotation on functions, describing
any side effects they may have. This may enable better optimisation, similar
to that which might be achieved if the compiler knows there's no aliasing of
pointers. Especially the part about the compiler being able to check the
specifications I found appealing.

However, one thing kept nagging me throughout the proposal - the same issue
that is a problem with the throw-specifications: How to deal with templates?

To take a simple example:

template<class T>
void f(T object) // What specifiers here?
{
  object.g();
}

Maybe something like:

template<class T>
void f(T object) reading(T::g()) writing(T::g()) throwing(T::g())

meaning that f() would have the same specifiers as g(). However, this could
quickly become quite complex, for more complex functions.

Furthermore, what about template specialisations:

template<class T>
void may_or_may_not_throw(); // What specifiers?

template<>
void may_or_may_not_throw<int>() { throw int; } // Throws

template<>
void may_or_may_not_throw<double>() {} // Doesn't throw

This may not be as "easy" as it seems...

Regards,

Terje



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Terje Sletteb   " <tslettebo@hotmail.com> wrote in message
news:419f64c7$1@news.broadpark.no...
|
| The proposal is about compiler-checked annotation on functions, describing
| any side effects they may have. This may enable better optimisation, similar
| to that which might be achieved if the compiler knows there's no aliasing of
| pointers. Especially the part about the compiler being able to check the
| specifications I found appealing.

yes, in theory that is a good thing.

| However, one thing kept nagging me throughout the proposal - the same issue
| that is a problem with the throw-specifications: How to deal with templates?
|
| To take a simple example:
|
| template<class T>
| void f(T object) // What specifiers here?
| {
|   object.g();
| }

one way to deal with the template problem would be not to have all these extra
specifiers.
If C++0x has a module system, the properties of functions could be put in the
module file
so other TU can take advantage of it for optimization.

yes, it will not give us compiler enforcement, but do we really want to write

| template<class T>
| void f(T object) reading(T::g()) writing(T::g()) throwing(T::g())

in soo many functions?

-Thorsten



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message
news:41a0ee77$0$33743$14726298@news.sunsite.dk...
 >
 > "Terje Sletteb   " <tslettebo@hotmail.com> wrote in message
 > news:419f64c7$1@news.broadpark.no...
 >
 > | However, one thing kept nagging me throughout the proposal - the same
issue
 > | that is a problem with the throw-specifications: How to deal with
templates?
 > |
 > | To take a simple example:
 > |
 > | template<class T>
 > | void f(T object) // What specifiers here?
 > | {
 > |   object.g();
 > | }
 >
 > one way to deal with the template problem would be not to have all these
extra
 > specifiers.
 > If C++0x has a module system, the properties of functions could be put in
the
 > module file
 > so other TU can take advantage of it for optimization.

That might be an idea.

 > yes, it will not give us compiler enforcement, but do we really want to
write
 >
 > | template<class T>
 > | void f(T object) reading(T::g()) writing(T::g()) throwing(T::g())
 >
 > in soo many functions?

Exactly. And what about if you have more complex functions, with more
template parameters, associated types, etc.?

It does look like a "welcome back" to the exception specifications that we
all "love"...

(By the way, for a case against checked exceptions: "Exceptional Java"
(http://www.octopull.demon.co.uk/java/ExceptionalJava.html))

Regards,

Terje



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <41a26594$1@news.broadpark.no>, Terje
=?UNKNOWN?Q?Sletteb=F8?= <tslettebo@hotmail.com> writes
>It does look like a "welcome back" to the exception specifications that we
>all "love"...

I think you need to look more closely. One problem with exception
specifications is exactly that they are not statically checkable. The
authors of this paper (much more considered than my own on the same
subject) have tried to address the issue.

Daveed raised the point that the compiler can deduce such things as
nothrow and pure. But that is to miss the point, it cannot. There are
times that the programmer can know things that are not knowable to the
compiler. Part of the proposal is a first step towards addressing that
issue.

For example, given

double d1;
// code initialising d1

double d2 = sqrt(d1);


must be treated by the compiler as potentially a problem because d1
might be negative. However the programmer may well know that this is
actually impossible for the program concerned.



--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Terje wrote:
> Hi all,
>
> There's a proposal at the standards site, "Toward Improved Optimization
> Opportunities in C++0X"

    Much of this can be done with existing C++ syntax.

Aliasing:

 using namespace std;
 void arraymult(vector<float>& out,
  const vector<float>& in1,
  const vector<float>& in2)
 {  assert(&out != &in1); // disjoint
    assert(&out != &in2);
    assert(in1.size() == in2.size()); // same size
    assert(out.size() == in1.size());
    for (int i=0; i<in1.size; i++)
    ....
         }

If the compiler knows that object of type std::vector are disjoint
if the base object is disjoint, then the "assert" statements
above are enough to convey lack of aliasing to the compiler.
The implication here is that the compiler needs some additional
information about the standard containers.  But ordinary
"assert" conveys the user-level constraints.

Thus, no new syntax is needed.

    John Nagle
    Animats

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Terje Sletteb   " <tslettebo@hotmail.com> wrote in message
news:41a26594$1@news.broadpark.no...

| It does look like a "welcome back" to the exception specifications that we
| all "love"...
|
| (By the way, for a case against checked exceptions: "Exceptional Java"
| (http://www.octopull.demon.co.uk/java/ExceptionalJava.html))

IMO it would actually be useful to change the meaning of exception specs to
mean nothing so they became a
documentation thing, nothing else.

-Thorsten



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Thorsten Ottosen wrote:
 > "Terje Sletteb   " <tslettebo@hotmail.com> wrote in message
 > news:41a26594$1@news.broadpark.no...
 >
 > | It does look like a "welcome back" to the exception specifications that we
 > | all "love"...
 > |
 > | (By the way, for a case against checked exceptions: "Exceptional Java"
 > | (http://www.octopull.demon.co.uk/java/ExceptionalJava.html))
 >
 > IMO it would actually be useful to change the meaning of exception specs to
 > mean nothing so they became a
 > documentation thing, nothing else.
 >

Unfortunatly, there are too many people who are actually using exception
specs to simply remove them. There are some programs in which such
things are useful. If you don't want to use them, simply don't. If you
simply want to have a comment, then put in a comment :)

Chris

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow <francis@robinton.demon.co.uk> wrote:
[...]
 > Daveed raised the point that the compiler can deduce such things as
 > nothrow and pure. But that is to miss the point, it cannot.

I disagree: In the model of the proposal, it can.

 > There are
 > times that the programmer can know things that are not knowable to the
 > compiler. Part of the proposal is a first step towards addressing that
 > issue.

I'm pretty sure that that's not the direction of the proposal
in N1664: It requires the implementation to diagnose
violations of the annotations.  In other words, the compiler
must deduce the property and then ensure it matches the
declaration (or do something equivalent in any case).

 > For example, given
 >
 > double d1;
 > // code initialising d1
 >
 > double d2 = sqrt(d1);
 >
 >
 > must be treated by the compiler as potentially a problem because d1
 > might be negative.

And the proposal also requires that the compiler assumes
it be a problem and issue an error.  So there is no difference
in that respect.  Here is an example straight from the paper:

   // Listing 24
   float hypotenuse( float s1, float s2 ) writing() {
     return sqrt( s1*s1 + s2*s2 ); // error; sqrt writes to errno 4
   }

In a discovery-based system you'd deduce that the "writing()"
annotation is invalid and hence not add it.

 > However the programmer may well know that this is
 > actually impossible for the program concerned.

The proposal (N1664 still) also proposes a construct that's
orthogonal to the annotation vs. discovery issue and that
permits the programmer to explicitly say "I know what I'm
doing; ignore the potential ill behaviors in this block".
However, that's not part of the entity declaration: It can
work both with explicit annotation and with module-
encapsulated discovery (the discovery process can trivially
incorporate the assertion).

         Daveed

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:

 > Terje wrote:
 >
 >>Hi all,
 >>
 >>There's a proposal at the standards site, "Toward Improved Optimization
 >>Opportunities in C++0X"
 >
 >
 >     Much of this can be done with existing C++ syntax.
 >
 > Aliasing:
 >
 >       using namespace std;
 >       void arraymult(vector<float>& out,
 >               const vector<float>& in1,
 >               const vector<float>& in2)
 >       {  assert(&out != &in1); // disjoint
 >          assert(&out != &in2);
 >          assert(in1.size() == in2.size()); // same size
 >          assert(out.size() == in1.size());
 >          for (int i=0; i<in1.size; i++)
 >          ....
 >          }
 >
 > If the compiler knows that object of type std::vector are disjoint
 > if the base object is disjoint, then the "assert" statements
 > above are enough to convey lack of aliasing to the compiler.
 > The implication here is that the compiler needs some additional
 > information about the standard containers.  But ordinary
 > "assert" conveys the user-level constraints.
 >
 > Thus, no new syntax is needed.

If NDEBUG is defined, the asserts disappear.  If it is not,
they have defined behaviour which must be respected.

-- James

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Thorsten Ottosen <nesotto@cs.auc.dk> wrote:
[...]
 > IMO it would actually be useful to change the meaning of exception specs to
 > mean nothing so they became a documentation thing, nothing else.

If backward compatibility were not an issue, maybe.  However,
at this point I don't think that would be a reasonable thing to
do.

         Daveed

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"James Dennett" <jdennett@acm.org> wrote in message
news:4lVod.168883$hj.59959@fed1read07...
|
| John Nagle wrote:

|  > Aliasing:
|  >
|  >       using namespace std;
|  >       void arraymult(vector<float>& out,
|  >               const vector<float>& in1,
|  >               const vector<float>& in2)
|  >       {  assert(&out != &in1); // disjoint
|  >          assert(&out != &in2);
|  >          assert(in1.size() == in2.size()); // same size
|  >          assert(out.size() == in1.size());
|  >          for (int i=0; i<in1.size; i++)
|  >          ....
|  >          }
|  >
|  > If the compiler knows that object of type std::vector are disjoint
|  > if the base object is disjoint, then the "assert" statements
|  > above are enough to convey lack of aliasing to the compiler.
|  > The implication here is that the compiler needs some additional
|  > information about the standard containers.  But ordinary
|  > "assert" conveys the user-level constraints.
|  >
|  > Thus, no new syntax is needed.
|
| If NDEBUG is defined, the asserts disappear.  If it is not,
| they have defined behaviour which must be respected.

We discussed this briefly at the last C++ meeting. I was arguing that aliasing
could be specified with contract programming, a bit like
John did above. My example was a copy algoithm that dispatched to memcopy
(see
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1669.html#restrict-replacement-example-hpp)
 However, other people said that

1. it would be incredible hard for the compiler to figure out that "no
aliasing" was the propety being described in the precondition
2. we might as well do the check at runtime and dispatch to the right code.

I guess (2) is not a valid criticism when it comes to loops that can take
advantage of aliasing properties.So (1) is the main problem.

-Thorsten




      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"chris" <caj@cs.york.ac.uk> wrote in message
news:41A39017.7010201@cs.york.ac.uk...
|
| Thorsten Ottosen wrote:

|  > IMO it would actually be useful to change the meaning of exception specs
to
|  > mean nothing so they became a
|  > documentation thing, nothing else.
|  >
|
| Unfortunatly, there are too many people who are actually using exception
| specs to simply remove them. There are some programs in which such
| things are useful. If you don't want to use them, simply don't. If you
| simply want to have a comment, then put in a comment :)


"Daveed Vandevoorde" <google@vandevoorde.com> wrote in message
news:52f2f9cd.0411231446.682df9e6@posting.google.com...
|
| If backward compatibility were not an issue, maybe.  However,
| at this point I don't think that would be a reasonable thing to
| do.

I must be missing some crusial infomation.

Assume we change exception specs to mean nothing, but require them to be
syntactically correct. Then I see these consequences

case 1: BEFORE: the exception-handler calls a user-defined unexpected() or
terminate(); AFTER: stack-unwinding + possible terminate()
case 2: BEFORE: the right exceptions are thrown + perhaps handled; AFTER: no
difference.

Here's a related question: what percentage of the people using exception specs
know they risk to crash the program at runtime?

Unless I'm missing something, then changing the behavior should actually make
programs more robust. So I must be missing something :-)

-Thorsten



      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

James Dennett wrote:

> If NDEBUG is defined, the asserts disappear.

    Is NDEBUG in the standard?

    Some years back, there was a discussion as to whether the
standard allows the compiler to rely on expressions in
"assert" being true, and the consensus was that it does.
The argument is that, while the semantics of "assert"
failure aren't well defined, they definitely don't include
continued legal execution.  So proceeding through a false
but disabled "assert" results in undefined behavior.
Therefore, the compiler can rely on the truth of expressions
in an "assert".

    John Nagle
    Animats

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
> James Dennett wrote:
>
>> If NDEBUG is defined, the asserts disappear.
>
>
>    Is NDEBUG in the standard?

Absolutely.  I don't have C90 around, but C99 says much
the same thing:

"... If NDEBUG is defined as a macro name at the
point in the source file where <assert.h> is included,
the assert macro is defined simply as
   #define assert(ignore) ((void)0)"

>    Some years back, there was a discussion as to whether the
> standard allows the compiler to rely on expressions in
> "assert" being true, and the consensus was that it does.

The consensus would appear to be unfortunately wrong.

> The argument is that, while the semantics of "assert"
> failure aren't well defined, they definitely don't include
> continued legal execution.

The semantics of assert are fairly clearly defined; it
tests the condition, and if the condition is false then
it writes a message to standard error and calls abort.

> So proceeding through a false
> but disabled "assert" results in undefined behavior.

I believe the behaviour is not undefined.

> Therefore, the compiler can rely on the truth of expressions
> in an "assert".

That would follow if the assumption that violating an assertion
resulted in undefined behaviour were true, but that assumption
does not hold.

There have been discussions in the past of alternative macros
such as things along the lines of (untested):

#define ASSUME(x) ((void)(((bool)x) || (1/0)))

which have the properties you've assumed hold for assert (i.e.,
do nothing if the condition is true, and give undefined results
otherwise).  I don't recall them getting as far as determining
whether current real-world compilers would make use of the
information presented to them via the ASSUME macro (which may
well have gone by other names in past threads, in case anyone
is googling).

-- James

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Thorsten Ottosen wrote:
[...]
> Here's a related question: what percentage of the people using exception specs
> know they risk to crash the program at runtime?

You can also ask the other way round:  What percentage of the people
omitting exception specs know they riks to crash the program at runtime?
  (Instead of going the safe terminate() route, those parts of the
program that do not expect a given exception to pass through them might
start to behave unexpectedly.)

-Stephan

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]