[Bf-committers] 64 bits coding
Brecht Van Lommel
brechtvanlommel at pandora.be
Sun Apr 29 14:53:44 CEST 2007
Hi,
Ton Roosendaal wrote:
> ------------ Subsurf code ------------
>
> blenkernel, subsurf_ccg.c
>
> - void pointers (like CCGFaceHDL) are mixed up with indices.
> It seems the vert/edge/face 'HDL' variables are always indices, not
> pointers ever. Very confusing...
Maybe these handles could be typedef'd as long instead of void*? The
reason to have these handles is to have a generic hashable value to
refer to a vertex/edge/face, which could be an integer or a pointer.
It would work in gcc at least, don't know about others.
> - struct UvMapVert has a mysterious element 'f' which is an index but
> also being multiplied with 4...?
>
> - strange index multiplications you find all over in this file (*4)
These are the indices for the vertices/edges for one vertex/edge in
the uv map. Each face has 4 uv vertices, so *4. I don't think this is
an issue any more than totvert or totedge being an int, since the
resulting mesh after subsurf can have that many vertices/edges.
> -------------- Hash tables -----------
>
> blenlib, BLI_ghash.c edgehash.c, BLI_heap.c
>
> - make API wrappers for int index hashes? Will solve plenty of warnings
If casting to long works on all platforms, long could be used here as
well? Otherwise I think it would be good to have a typedef for an
integer type that can be cast to a pointer and vice versa, which would
be long on gcc and something else on other platforms.
Brecht.
More information about the Bf-committers
mailing list