Re: Re: [AD] About create_bitmap

[Chris <chris.kcat@xxxxxxxxxx>]

On Thu, 04 Nov 2004 13:12:16 +0100, Elias Pschernig <elias@xxxxxxxxxx> wrote:
> Yes. Maybe I'm just used to handle all of this with ASSERT. My main
> concern is, why then not have if (bmp == NULL) in putpixel?

It doesn't have that? Well, the only logical reason I can think of to
not have a bitmap check is that bitmaps need to be checked when
they're created (or else you can't use them for anything), so there's
no use to check again (and again and again..).

> You can
> never tell which functions are time critical enough to not have such a
> check. blit() certainly wouldn't be affected by a single if. Allegro's
> way was to use ASSERT for every parameter checking, which is a simple
> and effective way in my opinion.

I agree, except where it creates inconsistencies. If a function has a
way to fail (ie. return NULL with create_bitmap), and the docs don't
specificly mention what parameters will cause a function to crash
(negative or 0 size), it should cleanly fail. That's the whole reason
for allowing functions to fail.. to inform the user/programmer that
the request was invalid.

> >
> > Besides, letting a function crash can wreak havoc on the rest of the
> > system (for certain systems), and I think we should avoid that when
> > possible. The docs say that the functions return NULL if the bitmap
> > can't be made, but say nothing about crashing/asserting on negative or
> > 0 values (where one would logically assume the function would just
> > return NULL because a bitmap of such a size can't be made).
> >
> 
> That's why we have ASSERT.

Which is only useful for debugging. Here's a good policy I tend to
follow.. if there's something you would ASSERT, and the function is
not used for time-sensitive code, use an if() and make the function
fail instead.

Though actually I do the opposite. Start with a function that always
checks, and fail when caught, and later on when optimizing for speed,
replace the checks with ASSERT where such gains an advantage. IMHO,
create_bitmap gains no advantage by ASSERT()ing over if()'ing. Using
an if() wouldn't prevent the programmer for checking and detecting bad
params, but using an ASSERT() makes it sloppier to handle invalid
parameters in a similar manner as other failures to the same function.


On Thu, 4 Nov 2004 09:38:24 -0600 (CST), allegrovp@xxxxxxxxxx
<allegrovp@xxxxxxxxxx> wrote:
> To me, a BITMAP with zero area (zero w, h, or both) makes perfect sense. If you think about it in terms of a window on a screen, say, it just corresponds to a window which is resized down up to the limit. This is still a window, you can still draw stuff on it, but it is just that, zero size.
> It's quite useful to have zero sized BITMAPs for GUIs. I have one, in which widgets are sub BITMAPs of their parent. In this case, I have a few cases where a zero area BITMAP makes sense. However, negative sizes do not make sense to me.

I think 0-sized and negative-sized bitmaps should be treated the same.
What can you do with a 0-sized bitmap? You can't write to it and you
can't read from it. A bitmap is defined by the pixels it contains, so
when it has no width or height (and thus no pixels) it's just like a
NULL-bitmap; it doesn't exist. If you could dynamiclky resize a bitmap
it'd be different, but you can't.. you'd have to destroy it and
recreate it.