Michiel Salters<Michiel.Salters@cmg.nl> wrote
> In article <873f7ae8.0107090419.6405ff0f@posting.google.com>, Kiril Avdeiv
> says...
>
> >20.4.1 desribing the standard allocator "class allocator", which is
> >meant to satisfy the requirements laid out in 20.1.5, has a function
> >deallocate that has no exception-specification, thus allowing it
> >(according to chapter 17) to throw any exception. This means that the
> >standard makes all the implementors of the C++ standard library
> >implement the standard allocator in such a way that it doesn't fullfil
> >the requirements for allocators (Ha, bloody ha!)
>
> You're mistaken. First, you wouldn't notice if the deallocate() function
> has an empty throw-specification, so a library implementer can choose
> to do so, if it thinks that would be needed. But the standard doesn't
> require an empty throw-specification, it just requires that the
> deallocate fucntion never throws an exception.

I think it is you who is mistaken :) In describing the member function
"deallocate" of the default allocator "class allocator" the standard
assigns it no exception specification. The description of the member
function "deallocate" of the default allocator "class allocator" has
no "Throws:" paragraph. And 17.4.4.8/3 speaks that in such a case the
function can throw ANY exception that the library implementor deems
appropriate. And this contradicts the library-wide requirements on
allocators stated in 20.1.5 and saying that no allocator's
"deallocate" throws an exception.

I find this finding to be a defect report.

> Consider this function:
>
> int f () { return 7; }.
>
> Can it return a negative value? Does the return type allow a
> negative value? The interface of a function restricts what a function
> can do, but not all what is possible within limits will happen.
Wow, what has this got to do with my posting?

Kiril

---
[ 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                ]

In article <873f7ae8.0107090419.6405ff0f@posting.google.com>, Kiril Avdeiv
says...

>20.4.1 desribing the standard allocator "class allocator", which is
>meant to satisfy the requirements laid out in 20.1.5, has a function
>deallocate that has no exception-specification, thus allowing it
>(according to chapter 17) to throw any exception. This means that the
>standard makes all the implementors of the C++ standard library
>implement the standard allocator in such a way that it doesn't fullfil
>the requirements for allocators (Ha, bloody ha!)

You're mistaken. First, you wouldn't notice if the deallocate() function
has an empty throw-specification, so a library implementer can choose
to do so, if it thinks that would be needed. But the standard doesn't
require an empty throw-specification, it just requires that the
deallocate fucntion never throws an exception.

Consider this function:

int f () { return 7; }.

Can it return a negative value? Does the return type allow a
negative value? The interface of a function restricts what a function
can do, but not all what is possible within limits will happen.

Regards,
Michiel Salters

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel.Salters@cmg.nl

---
[ 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                ]

I really cannot figure out what all this mess means:

1. 3.7.3.1/3 says that if an allocation function with a non-empty
exception-specification fails to allocate the required storage, it
shall report the failure by thorwing an std::bad_alloc or a type
derived from it. On the other hand all the references to the standard
allocation functions in chapter 18.4.1 state in their "Required
behavior" clause that the functions can only throw std::bad_alloc (not
a class derived from it). However, the so-called "new_handler", which
all the non-placement standard allocation functions make use of, is
allowed to throw std::bad_alloc or a class derived from it, thus
making the corresponding allocation function throw an exception whose
type violates the allocation function's requred behavior.

Can anyone please make sense of this mess for me, why does 3.7.3.1/3
contradict 18.4.1? One more thing, the class derived from
std::bad_alloc that 3.7.3.1/3 and 18.4.1 mention, can it be a class
privately derived from std::bad_alloc? According to the standard it
can. Does it make sense? NO!!!

2. To add to this state of madness, the standard tries to make it
really hard to understand what an allocator's allocate and deallocate
can throw:
20.1.5 says that allocate may raise an appropriate exception, and that
deallocate doesn't throw an exception. Well, what is an appropriate
exception? Will the type "MyException" do? And what is this fancy term
"raises an exception" while the rest of the document speaks of
"throwing" and not raising an exception?

20.4.1 desribing the standard allocator "class allocator", which is
meant to satisfy the requirements laid out in 20.1.5, has a function
deallocate that has no exception-specification, thus allowing it
(according to chapter 17) to throw any exception. This means that the
standard makes all the implementors of the C++ standard library
implement the standard allocator in such a way that it doesn't fullfil
the requirements for allocators (Ha, bloody ha!)

Well, dear standardizers, can you account for the issues I've raised?

Kiril

---
[ 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                ]