[Bf-committers] Sharp/Flat selections
cwant at ualberta.ca
Wed Dec 28 22:48:19 CET 2005
Ken Hughes wrote:
> Tom M wrote:
>>> One thing I don't like about this code (and this certainly
>>> isn't the only place in the code this happens), is that
>>> it uses the fact that the (short int) edge flags eed->f1
>>> and eed->f2 are consecutive, and casts that storage to
>>> be a long int.
>> Is that safe for 64 bit systems too? Also are compilers allowed to
>> reorder stuff in structs at high optimization levels? Also would
>> making it a true long int and having the old f1 and f2 accessed via a
>> bitmask method work?
> It would be problematic on 64-bit machines anyway. Isn't a short int
> should 16-bits but on 64-bit machines (except WinXP) a long would be
> 64-bits? Or is a long int the same as an int?
I think you're right, at least according to
the data models presented on this page:
What it boils down to is that I need at least
a 32 bit integer (it is unlikely we will see
meshes with more than 2 billion edges for some
time). I think Ton says he would like to adopt
the LP64 standard (with typedef's for windows),
so it seems that an 'int' would be a better choice there.
An int causes problems with the LP32 standard though,
so maybe an #ifdef is needed to do the right thing (long
for 32 bits, int for 64 bits). Best of all worlds though
would be to have a flag that is a long.
Btw, does anybody have any comments on the functionality
of the patch that aren't related to the abuse of flags?
More information about the Bf-committers