internal representation of struct

[spir]

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