Re: [Crystal-cvs] SF.net SVN: crystal:[39466] CS/trunk/include/csutil/variant.h

On Mon, 2013-07-08 at 19:01 +0200, res wrote:
> On 08.07.2013 15:06, [email protected] wrote:
> > @@ -38,7 +38,7 @@
> >  /// Type of the values that can be contained within a csVariant.
> >  enum csVariantType
> >  {
> > -  // Signed 32-bit integer (long)
> > +  /// Signed 32-bit integer (long)
> >    CSVAR_LONG,
> 
> Hm, I probably would have rather chosen a name like CSVAR_INT32.
> Unless it's really a long, then the current name is appropriate.
> – The pitfall here is that “long” is _not_ consistently 32-bit… on Win64
> it is, but on Linux x86_64 it's 64-bit!

The 'CSVAR_LONG' name has been defined long time ago, a priori by Jorrit
back in 1998, within the file 'iutil/pluginconfig.h'. The description
has been changed recently though, although the previous one was better:
"Long type, obviously also valid for integers". And it's actually a
'long' variable that holds the value in the implementation.

About the 32/64 bits inconsistency, maybe we can introduce the explicit
types CSVAR_INT32 and CSVAR_INT64? Maybe also CSVAR_UINT32 and
CSVAR_UINT64? And we would deprecate CSVAR_LONG?


> >    /// csMatrix3 type
> > +  // TODO: quaternion instead?
> >    CSVAR_MATRIX3,
> 
> …I always though 3x3 matrices could represent more potential
> transformations than quaternions. (Aren't those limited to rotations? My
> knowledge is somewhat lacking here.)

Yes, quaternions are somehow limited to rotations only, and the comment
was actually about that question: "would we limit the 3x3 matrices
parameters to rotations only?"

A posteriori, I would say that a type for 3x3 matrices can be
interesting, and that we can either add another type for quaternions or
add utility methods to convert from a CSVAR_VECTOR4 to a quaternion.


> >    /// csTransform type
> > +  // TODO: remove?
> >    CSVAR_TRANSFORM,
> 
> Removal because (a) it doesn't really fit into the envisioned use
> case(s) for csVariant or (b) because you don't like csTransform?
> If it's (b), perhaps you'd like a 4x4 matrix more?

Here the question was whether or not limiting transforms to be
orthogonal. Most transforms in a rendering engine are a priori
orthogonal, but non-orthogonal transforms may also be interesting in
some specific contexts.

If we limit to only orthogonal transforms, then it becomes possible to
expose separately the rotations, translation and scale components of the
transform instead of the transform itself, and that type wouldn't be
needed anymore.

As for matrices, I would now say that a type for generic transforms
might be interesting too.


------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Crystal-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crystal-develop