Re: [boost] Re: minor scoped_ptr/scoped_array feature request

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2002-11-17 14:42:32

I'll respond to all 3 messages by this.

----- Original Message -----
From: "Gennaro Prota" <gennaro_prota_at_[hidden]>

> On Sun, 17 Nov 2002 18:22:20 +0100, Thorsten Ottosen
> <nesotto_at_[hidden]> wrote:
>
> >Yes, but note that having both is less fortunate. Either we agree that
> >library writers check preconditions and then
> >clients don't or we agree that clients check preconditions and library
> >writers don't.  One reason that C is such
> >a pain in the *** to use is because its the cliets responsibility to
check
> >conditions , e.g.
> >
> >int * i = malloc( sizeof( i ) );
> >assert( i );
>
> Well, apart from the C-style void*->int* conversion and the curious
> sizeof(i) instead of sizeof(int), weren't you speaking of
> preconditions? :-)

Well, my point is that if you put the check in the library, then you do it
once; if you
don't put it there, then you do it n times. It does not matter what the
check is.

> Anyhow one of the reasons why C++ (or C if you want to talk about it)
> is the way we all know is that it does its best to avoid unnecessary
> costs: "you do not pay for what you don't use". In a situation where
> you are absolutely sure that no precondition is violated you don't
> want the library to check that for you. C++ programmers are not the
> kind of guys who like range-checking on vector::operator[] when they
> have something like:
>
>   for (std::size_t i = 0; i < v.size(); ++i)
>       std::cout << vect[i] << '\n';

Maybe we just don't understand each other. It would still be useful to
have a range check in the debug version. Maybe I have misunderstood
something
about the stanard, but
shouldn't assert( i < size ) be compiled away in a release version? It will
still
catch bugs while you're developing and give no overhead otherwise. Don't
you think debug iterators is better than a core dump?

On Sun, 17 Nov 2002 12:53:52 -0500, David Abrahams
<dave_at_[hidden]> wrote:
>Not all preconditions are effectively checkable

then how should the client check them? I assume the client cannot check the
preconditions any better than the library.

>However, there's no way to take away checking if it gets put in
>the library, and there's no way to change the response in case of a
>failed check if it's not the response you need.

----- Original Message -----
From: "Gennaro Prota" <gennaro_prota_at_[hidden]>
> For asserts, since
> they "go away" with the "official program" (when NDEBUG is defined)
> the official version of the function has still preconditions in the
> meaning you give to the word.

Maybe we have talked enough without understanding what each other is saying?
It seems to me that assertions are exactly what we need when there must be
no
overhead. They are still better put into the library. That is why I think
boost::array should
do range check with an assert for oprator[]; it won't hurd to put it there
and it might save
somebody a lot of trouple figuring out what was wrong with the program after
a crash.

regards

Thorsten