[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
George Foot <gfoot@xxxxxxxxxx> writes:
> Casting away constness is very bad though -- the compiler can
> make optimisations assuming the pointed-to data does not change,
> when in fact you're altering it. Acquiring the surface is
> changing the data pointed to (several levels of indirection
> further down), so the function should not take a const
> parameter.
>
> I can't think of any bitmap operations for which it *would* be
> appropriate to have a const parameter. Any drawing operation
> modifies the content, and even reading operations may involve a
> bank switch. That's true in all platforms, not just Windows.
I've got a patch for Peter Puck that fixes const related warning by
casting away const. I will not apply it yet, until we decide what
should be done.
As George said different platforms use different tricks to emulate
video BITMAPs with behaviour similar to video BITMAPs in DJGPP. These
tricks may change some BITMAP fields.
On the other hand, we can use const for BITMAPs that can only be
source memory bitmaps, like source bitmap in stretch_blit. In other
words, if read_bitmap_line or similar is not used in function, we can
make parameter const. But we should think twice if function is used
in vtable, or there is some kind of indirection in function call.
--
Michael Bukin