[Verse-dev] Numerical IDs [R4]

[Emil Brink]

> Hi, still at Siggraph, I have the OpenGL and verse BOF today.

Cool, I hope that went well!

> >I disagree. I find it very useful to be able to set an ID
> >variable (or structure field) to a known invalid value, to mark
> >that I am still waiting for the server to assign it.
>
> I agree it is usefull in your app, but not for the network protocol.

Well, I have to know that whatever ID I set my variable to cannot be
sent by a host of course, otherwise there is no point.

> Actiually not only wound the host never send you invalid values, it
> usualy even cant, since this triggers function aliases.

I know, that's the very idea behind knowing that one ID value is
reserved and cannot appear.

> >Such defines would have to include the type of value, which is not
> >very elegant, compared to just using zero.
>
> Yes, it would need to have types. (just a question: dont you have
> issiues against all nunbers typed in to the code that arent
> defines?)

Well... I do have such issues, but zero and one are rather okay to
use literally, I think. They are commonly used with variuos APIs
already.

> Ok Lets go beyond this and let me explain just how much this would
> break existing apps, and make them a hole more more complicated:
>
> The first main reason is that in C the first element of an array is
> numberd wero.

I know. :)

> Imagine that you allocate and array of vertexes, polygons, layers or
> buffers. Now either you dont use the first element and waist memory
> or you have to make lookups in to the array with ids minus one. This
> makes the code way more error prone.

Well.. That depends on how you organize your code, of course. If you
wrap the concept of "an array that has a different base than zero" in
a suitable data structure, the problem goes away.

> Next consider this, If i have a look-up in to a array i must always
> check for this. For example lets read out a vertex from a a polygon
> reference. this is how its done now:
>
> if(polygon[id * 4] < vertex_length && vertex[polygon[id * 4] * 3] !=
> E_REAL_MAX)
>
> this the same code if the zero is reserved:
>
> if(polygon[(id - 1) * 4] != 0 && polygon[(id - 1) * 4] <
> vertex_length && vertex[(polygon[(id - 1) * 4] - 1) * 3] !=
> E_REAL_MAX)

Heh. Of course, noone half sane would ever write code like that. In
stead, what you do is stick a simple id--; before the if(), to con-
vert the logical ID into a physical array index. Simple, and I dare
day the performance overhead is neglible, it should be on the order
of 1-3 instructions or something. The risk of forgetting to do this
is, again, removed by wrapping it.

> This extra test have to be done for every corner in the polygon and
> is just a hazzle. It compleatly breaks all my apps (in more then one
> place). and it is likely to introduse a lot of bugs even if fixed.

That's a problem, of course. But wouldn't the same places in the code
need to be looked over if there was some other reserved value?

> This doesnt just hurt polygon and vertex code, it require an extra
> test (and a subtract) for every, layer, fragment and buffer look up.
> Again breaking all apps and further complicate the apps.

Yeah, well, I'd argue that the extra subtract is very cheap indeed.
The test is not "extra", you need to test against whatever value is
reserved. Assuming it's the maximum and never happens isn't very
nice, imo.

> Yes the hole NULL-zero thing makes having zero be an invalid look
> nice. But thees are ids not pointers! And when it comes to array
> lookups, the id zero is about as valid as you can get. Making zero
> invalid will make so much code so much uglyer.

Yeah, well... It might be a point to keep the IDs zero-based just so
that they can be used to directly index arrays, I guess. It's just
too bad that it then requires a bunch of other uglyness, casts and/or
a set of macros to handle the reserved values.

We need to sketch out a solution for R4, I think.

/Emil