Looking at the noexcept proposal for exception safety, my questions
are:

Why use noexcept? I know it's not totally backwards compatible, but I
think it would
be better to make statically checked the exception specifications as
they are today.
I mean:

1) void myfunc() throw()

should be statically checked.

2) int myfunc() throw(std::badalloc) should only throw std::bad_alloc
and nothing else.

I think it wouldn't be a problem since there are very few uses of the
second kind, so there would be
no problem.

The compiler would issue an error in the case it checks statically
something which is wrong, which is
GOOD to correct code that is already written to avoid problems.

The default would be to throw any exception, to preserve more
compatibility, if there is no
exception specification (I'm not sure about this).

Another thing I don't like about the proposal is that it uses noexcept
for not throwing exceptions, which
is used like this:

noexcept void f();

But to specify that any exception is thrown, it is done like this:

void f() throw(...)

Which is counterintuitive because in the first case it is specified
before the return type and in the second
one after it.

The paper says that exception specifications are a kind of broken
feature, because they have the gotcha
that people expect them to be statically checked. So my proposal would
be to extend the syntax with

throw(...) and leave everything else like it is, but to check
everything statically (just like java does).

And for concepts, I would allow to specify exceptions too, with the
original syntax.

What do you think? Is this possible to achieve?

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

> What do you think? Is this possible to achieve?

Hi, you might be interested in reading this thread:
http://groups.google.co.uk/group/comp.std.c++/browse_thread/thread/135e3ebc5a6658cc

Regards,
&rzej

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

On 18 juin, 04:10, german diago <germandi...@gmail.com> wrote:

> I
> think it would
> be better to make statically checked the exception specifications as
> they are today.
>
> I mean:
>
> 1) void myfunc() throw()
>
> should be statically checked.

So basically you're saying we should change the semantics of throw()
to be that of noexcept, instead of keeping things as they are and
introducing noexcept?

I don't think that's gonna happen.


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

I mean in C++03, throw() means that the function does not throw, but
it's
not statically checked. I would see as a good thing to change this to
be
statically checked because, anyway, if some programs don't compile
anymore,
they were broken anyway, because they were assuming that a function
does not throw when it does exactly the opposite, indeed.
The code could be
corrected and made safer.

So, I know it's an incompatible change, but I think it would be a good
place to make
this little cleanup in exchange of some benefit (no duplication of
techniques to do the same thing,
one of them broken).

I know you can catch std::unexpected exceptions, but this is a broken
thing from
my point of view. Exception specifications should work more like the
java ones.

 Just an opinion.


> So basically you're saying we should change the semantics of throw()
> to be that of noexcept, instead of keeping things as they are and
> introducing noexcept?
>
> I don't think that's gonna happen.
>


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

On 19 jun, 02:24, Mathias Gaunard <loufo...@gmail.com> wrote:
> On 18 juin, 04:10, german diago <germandi...@gmail.com> wrote:
>
> > I
> > think it would
> > be better to make statically checked the exception specifications as
> > they are today.
>
> > I mean:
>
> > 1) void myfunc() throw()
>
> > should be statically checked.
>
> So basically you're saying we should change the semantics of throw()
> to be that of noexcept, instead of keeping things as they are and
> introducing noexcept?
>
> I don't think that's gonna happen.


Maybe another way would be to deprecate throw() and to use throws()
exactly
as C++03 does but with statically checked exceptions. No learning
curve and
inmediatly useful. So thorws() means don't throw anything, throws
(runtime_error)
would mean just runtime_errors and throws (...) would mean throw
anything.

What do you think?

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

german diago wrote:
> I mean in C++03, throw() means that the function does not throw, but
> it's
> not statically checked. I would see as a good thing to change this to
> be
> statically checked because, anyway, if some programs don't compile
> anymore,
> they were broken anyway, because they were assuming that a function
> does not throw when it does exactly the opposite, indeed.
> The code could be
> corrected and made safer.
>
> So, I know it's an incompatible change, but I think it would be a good
> place to make
> this little cleanup in exchange of some benefit (no duplication of
> techniques to do the same thing,
> one of them broken).
>
> I know you can catch std::unexpected exceptions, but this is a broken
> thing from
> my point of view. Exception specifications should work more like the
> java ones.
>
>  Just an opinion.
>
>
>> So basically you're saying we should change the semantics of throw()
>> to be that of noexcept, instead of keeping things as they are and
>> introducing noexcept?
>>
>> I don't think that's gonna happen.
>>
>

You do not get it do you? Example:

double sqroot(double d){
     if(d<0) throw bad_data();
     double s;
     // compute s as the positive square root of d
     return s;
}

(and yes, of course I know there is a library function for square roots)

Now imagine that there are a zillion lines of code that ignore the
possible exception. Among those a very large number have been written by
competent programmers who ensure that the argument they pass is
non-negative.
Yes, sqroot() can throw, and yes it should do something to protect
against a bad argument. However your proposal means that every piece of
code that calls sqroot() must either handle the exception (if for
example it wants a throw() specification or let it pass through.

The horse bolted more than a decade ago. Experience suggests that the
only possibly beneficial case is to identify functions that do not throw
and do so in a way that leaves existing code alone.

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

german diago wrote:
> I mean in C++03, throw() means that the function does not throw, but
> it's
> not statically checked. I would see as a good thing to change this
> to be
> statically checked because, anyway, if some programs don't compile
> anymore,
> they were broken anyway, because they were assuming that a function
> does not throw when it does exactly the opposite, indeed.

There is code out there that is correct, but will be rejected by a
static check.

Suppose my code calls a function that might throw
std::invalid_argument in some very rare cases. What if I make sure
that all the calls are made with valid arguments? Perhaps my value
domain is such that an invalid call can never happen.

Should I not be allowed to have a throw() on my function, even though
I know it will never throw anything?


Bo Persson



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