[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> >>Attached is another patch. Many of my changes from `long' to `int'
> >>(e.g. for holding pixel values) were not really necessary so reverted
> >>those.
> >>
> >>
> >
> >Why?
> >
> >
>
> In some places, the change from long to int would have changed the API
> unnecessarily (I'm thinking of the blender functions, but maybe there
> were more).
True. I think a case could be made that those functions should really have
taken an int rather than a long, but that's beside the point since they
didn't.
Having int might be a good idea because compilers Allegro currently
supports (in Windows) do not agree on the size of a long, but they do agree
on the size of an int. At least as far as I know.
> In other places where it didn't really matter either way, I thought it
> would be best just to leave them alone. Then the assumption on the
> sizeof(int) can remain as it is now (somewhere between 16-bits and
> 32-bits) and long can continue to be used to hold values which need
> 32-bits. Is there any reason to prefer a 32-bit integer over a 64-bit
> integer on a 64-bit machine, e.g. to hold single pixel values?
I think there's performance reasons to prefer an int over any other integer
type if there are no other constraints on the datatype.
Evert