Re: [boost] More "any" remarks

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-11-12 17:03:05

----- Original Message -----
From: "Ed Brey" <brey_at_[hidden]>

> From: "David Abrahams" <abrahams_at_[hidden]>
> >
> > > and I cannot see what inadvertent implications you are referring to --
> >
> > For example, that other boost classes are not exception-safe.
> >
> > > all members satisfy the strong or no throw gtee (this might be worth
> > > documenting).
> >
> > Yes! That at least has some value as information, wheras the statement
> that
> > it is exception-safe has (almost) none.
>
> This discussion seems to be pointing to a need for a top-level "library
> invariants" page that would list guarantees that are made for all boost
> libraries.  Then each library would not need to repeat this information in
> its page.  In this case, the invariant is that all libraries are exception
> safe. The page could describe the meaning of this and provide a definition
> of the minimum weak guarantee

"basic", not "weak", please!

> that all boost libraries offer.

If we're going to say that, it's cleaner to say "all library operations
satisfy at least the basic guarantee that...<definition of basic
guarantee>". If you mention the ill-defined term "exception-safe" you risk
confusing people. Many people think "exception-safe" means "gives the strong
guarantee". It's better not to get involved with the term "exception-safe".

>  It can also
> define the stronger guarantees so that individual libraries that offer
> stronger guarantees can specify so in just a few words linked back to a
full
> definition of the guarantee.

That's a great idea.

> If we don't have a centralized source on exception guarantees, the
> alternatives are (1) potential duplicate descriptions of exception safety
in
> various libraries, (2) confusing end users who are not familiar with
> exception safety, or (3) cross-referencing a description of exceptions
> safety such as http://www.research.att.com/~bs/3rd_safe.pdf.

There's no reason we can't publish my paper, as long as we also provide the
link to the proceedings publication.

> Nothing is coming to mind at the moment as far as other library invariants
> go, but I suspect that they exist.  The "library invariant" concept is
> similar to the existing Library Requirements and Guidelines, but with
> different focus.  The Requirements are aimed at library developers,
whereas
> I'm proposing something directly geared towards end users in the form of
> documentation common to all libraries.

I think the proposed list would be useful to developers, also.

-Dave