Re: [boost] Re: [string algo review] exception specification

From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-24 12:12:38

On Fri, Oct 24, 2003 at 08:30:57AM -0400, David Abrahams wrote:
> "David B. Held" <dheld_at_[hidden]> writes:

I think, I understand the exception guarantie levels and the asociated topic.
But I'm not able to express it formaly enough.

I'd like to ask you for help. I seems pointless, for me to writte many specifications
and explanations when I don't realy know what do you expect. 
So I will give you a brief description of the library and with the docs and 
sources you should be able to give and example how the specification 
should look like or write in full if it will not be very long.

Following list contains the properties of the library which are in
my opinion relevant for exception specification. If there is something missing,
just ask for it.

- No algorithm in the library throws an exception on its own
  (an exception can be throw indirectly by an used operation)

- No algorithm direcly modifies any global parameter in any way
  (global state san be modified indirectly by a used operation)

- No const or pass-by-value argument is directly modified
  (again, some operation can change them) 

- All algorithms use only following types of operations
  - basic iterator operations like ++, * and etc.
  - basic container operations like insert, erase, replace
  - container constructor taking a pair of iterators
  - copy construction
  - std::algorithms like copy, find_if and transform
  - std::back_inserter, this implies the use of container::push_back
  - std::locale classification 
  - basic operations on values from containers like == and =
  - char_traits::length operations for char* and wchar_t*

  - in addition to these, regex algorithms use the Boost.Regex library

- All algorithms are templated, template parameters include 
  - input containers/sequences
  - predicates
  - iterators
  - values

- There is no explicit exception handling implemented in the library
  (This is not something, that could not change. However I don't know
   about any place in the library where it would be useful)

So these are constraints. I don't know what kind of guarantie can be 
implicated from them, except for those claims that I have already stated.

Please help me out.

Regards,

Pavol

> > [...]
> > So this is the summary. It would be possible to specify for
> >> each algorithm a table with specific requirements to give the
> >> specific guarantie. It would be quite chalenging to do it
> >> properly,
> >
> > Indeed!
> >
> >> but the question is if it would be usable at all?
> >
> > Yes!  I think this type of rigor is increasingly important.
> 
> I agree.  It may not be neccessary to actually write a table for each
> and every function (something simpler may well suffice), but the way
> Pavol has formulated the foregoing material doesn't quite give me
> confidence that the appropriate rigor has been applied.
>