On 03/18/2011 05:34 PM, lenochware wrote:
Hello, I have array of type vertex_t vertices[] where vertex_t is:
struct vertex_t {
float[3] xyz;
ubyte[4] color;
...
}
Now, I would like use instead of array "float[3] xyz" "vec3f xyz", where vec3f
is:
struct vec3f {
float x, y, z;
...some functions...
}
where I have defined some operators for adding and multipliing vectors etc.
Is it possible? "xyz" must be exactly 3 floats in memory because I am sending
vertices array pointer into OpenGL rendering pipeline.
I think --but not 100% sure-- you can count on having no diff in terms of
memory layout.
The gain in terms of code legibility is well worth it:
vec.z vs vs[2]
color.R vs color[0]
Side-note: in the D community a coding style in starting to spread in which
type names are capitalised: thus, would be Vertex instead of vertex_t, and
Vec3f instead of vec3f. (This is for public code, indeed; I just inform.)
Will be struct vec3f represented just like 3 floats - aren't here some
additional metadata - because structure contains also some functions?
Since struct member functions/methods are static, their calls are translated at
compile time. There should thus be no diff with an external, "free", function
having a struct object as first argument. This is the main low-level diff with
dynamic ("virtual") methods. But don't take my words for sure information, I'd
like someone to confirm this.
My additional question: What about effectivity? I would like keep struct
vertex_t as simple as possible, because I need do calculations fast. Will have
replacing float array to structure some impact on speed?
There should be no sensible difference noticeable. On modern architectures,
pointer deref, array lookup and (static) member access are about the same
speed. (Compared to speed of code that operates on data accessed that way). In
fact, at a lower level, static member access is the same thing as array lookup
(deref at base_pointer+offset). You may notice some difference on artificiallly
"empty" benchmarks (doing nothing but accessing the data), but it's not
representative.
Denis
--
_________________
vita es estrany
spir.wikidot.com
