[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