Bill Baxter, el 29 de octubre a las 11:31 me escribiste:
> On Thu, Oct 29, 2009 at 11:16 AM, Leandro Lucarella <llu...@gmail.com> wrote:
> >> that's the overwhelmingly common case though, and if it's, say,
> >> about 50/50, then it's much more sensible to have a non-throwing
> >> primitive than a throwing one. And it looks like defining two
> >> primitives just to save a call to enforce is not a good design.
> >
> > This is one case where I think practicality beats purity, because the
> > whole point of throwing an exception is for the cases you don't expect it
> > to fail. Again, think of array bounds, you can force the programmer to add
> > lots of enforce() in the code and remove bound checking from the compiler.
>
> The problem with this argument (which I was also about to make) is
> that accessing an array out of bounds is almost never normal behavior.
> But for deleting things, it often is. Think also about delete
> itself. In C++ and D delete on a null pointer is fine, and is defined
> to be a no-op. This was done explicitly to avoid always having to do
> if(p) delete p; all the time. And really it works out just fine in
> practice. If we're going to keep arguing that remove() should throw,
> then really delete should too.
I don't think that's the case. If you have a wrong value in a pointer you
want to delete, you have 2 posibilities:
1) Is a valid pointer, in which case you are doomed, a wrong object would
be deleted and your program is fucked.
2) Is an invalid pointer, in which case the program could explode
inmediately. I don't know what happens right now, but an assertion in
this case sould be useful too.
NULL pointers are not a problem, because it rarely indicates an error in
the program. delete NULL is useful for things like:
T* x = null;
if (blah)
x = bleh();
foo(x);
delete x;
This might ever be a valid use case for AA too, and in that case I don't
really mind aa.remove(null) being a NOP.
The issue is with WRONG KEYS, not null ones. If you messed up with your
key (as well if you messed up with your pointer in delete), *bad* things
will happen, and even when it's not "memory corruption" per se (I think
the definition of SafeD is avoiding memory corruption only), it's close to
undefined behaviour, your program will start failing in very strange ways
and the bug will be too hard to track. It's basically the same problem
with dynamic languages that doesn't even need to "declare" a variable,
like perl or php.
So I think yes, remove should assert() if the key is not found (unless
you explicitly inform in some way that you don't want it to fail) and
delete should assert() if the pointer passed is not a pointer to a start
of a HEAP block. In either case is a bug, and I want to be notified about
it as soon as possible (at least in non-release mode).
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Sé que tu me miras, pero yo me juraría que, en esos ojos negros que
tenés, hay un indio sensible que piensa: "Qué bárbaro que este tipo
blanco esté tratando de comunicarse conmigo que soy un ser inferior en
la escala del homo sapiens". Por eso, querido indio, no puedo dejar de
mirarte como si fueras un cobayo de mierda al que puedo pisar cuando
quiera.
-- Ricardo Vaporeso. Carta a los aborígenes, ed. Gredos,
Barcelona, 1912, página 102.
