Re: [eigen] a few things

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Benoît Jacob schrieb:
> Hi List
> 
> when a class has a "static const int" member, this member is actually stored 
> in memory somewhere in the program's memory space, while an "enum" is just 
> used by the compiler and not stored in the program's memory space. Right?

A enum is definitely not stored in memory. A enum is just like a name, a
placeholder for a number.

A static variable has to be somewhere as other objects might access it.
But it's only created once. It might stop compilers from optimizing
things away (that GCC and ICC do work doesn't say that it works for all
compilers...)


> Now, before going for enums, I have a few more questions.
> 
> 1) when the compiler sees something like
> enum MyType { First = 1, Second = 10000};
> the compiler may choose as underlying integer type for MyType any type that 
> can store the given values. In that case it might use "short int" 
> or "unsigned int" for example. The following example,
> enum MyType { First = 1, Second = -10000};
> is legal and the compiler is guaranteed to choose for MyType a signed type.
> [...]

See Stroustrup §4.8 Enumerations

Basicly:
The enum can hold the same values a int or unsigned int can hold
(depending if negative numbers are in the enumeration...)

> So I can always, regardless of the compiler, do:
> 
> enum Size { Dynamic = -1, Generic = -2 };
> 
> right?

Yes

> 2) Should my template parameters then be enums as well? Is this legal? Or 
> should I leave them as ints?

Leagal: I currently don't know
Usually they are ints. It doesn't create problems as templates are just
a crazy way of generating really complex class names (the process is
called name mangling and the compiler takes care of it...)

So these ints are just changing the name and are not generating any
memory or runtime overhead.

> 
> My concern here is the following. Suppose that at some point during 
> compilation, the compiler has decided that the underlying integer type 
> for "enum Size" is "char"  (this counts as an integer type, right?)
> 
> Suppose then (unlikely but possible) that later the compiler finds in the 
> source code an instanciation like
> 
> Matrix<float, 128, 1> myBigFixedSizeVector;
> 
> 128 doesn't fit into char so what happens?
> - compiler error?
> - integer overflow / undefined behavior?
> - or is the compiler so clever that it will first go through the whole source 
> code to see what integer type is really needed?

128 has to be of some type. If it's a enum then the enum at this
parameter position definitely has the right type - otherwise you
wouldn't be allowed to put that number there...

> Is it a good idea, to work around this issue, to declare enum Size as follows?
> enum Size { Dynamic = -1, Generic = -2, Dummy = INT_MAX };
> in order to ensure that the underlying type is "int" ?

You'd need something like that to be able to put that number there anyway.

enum flag { x=1, y=10 };  // create a enum of range 0:10
flag f1 = 5;          // error - 5 is not of type flag
flag f2 = flag(5);    // OK
flag f3 = flag(128);  // error, 128 is not in the range 0...10


=> my sugestion: use enum *in* the classes and int at "global" scope (=
the eigen namespace) and as template parameters

CU,
Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHhnmnoWM1JLkHou0RCCWxAKCFYmxduhJXm9qih77LdBS5wAD55ACglBt/
iowrrBqpKCaq2XLoozc1SAA=
=Qr1W
-----END PGP SIGNATURE-----



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/