RE: [AD] Why aren't BITMAP * parameters const where appropriate?

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


We just need to be careful about functions like blit and family, which
can overwrite the contents of the source bitmap (even if const) if the
same bitmap surface is used as both source and destination. 

-----Original Message-----
From: alleg-developers-admin@xxxxxxxxxx
[mailto:alleg-developers-admin@xxxxxxxxxx] On Behalf Of Elias
Pschernig
Sent: Sunday, January 09, 2005 5:26 AM
To: alleg-developers
Subject: RE: [AD] Why aren't BITMAP * parameters const where
appropriate?

> Arguably, Allegro should have const-cast'ed away the const for those 
> cases where the bitmap is logically const.

I wonder if casting away const wouldn't cause subtle side-effects in
some special cases though.

void test(BITMAP const a) {
    BITMAP b = a;
    c = getpixel(a,...);
    b = a;
    ... use b now ...

If the first parameter to getpixel is const, I guess, the optimizer
could just discard the second b = a, since it knows that a has not
changed (don't know though, but it always was my explanation why const
is useful). Of course, you can never use a BITMAP not created with
create_bitmap, so this is not a real example.

If it is safe to cast it away, I guess we could use const everywhere
where it makes sense. And else, things like get_bitmap_color_depth()
really could have a const parameter. Actually, all functions which don't
modify anything, and don't call a vtable function.

-- 
Elias Pschernig



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
-- 
https://lists.sourceforge.net/lists/listinfo/alleg-developers




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/