Hello,
I would like to create a dynamic struct:
struct reg[] =
{
That's an array, not a struct.
yep.
(a lot of what follows can be considered side-information, as it may not
be directly relevant to the OP, and may be biased slightly in favor of
writing interpreters...).
this is a sort of case though where I more commonly use a struct
containing parallel arrays.
one array can identify the fields, another struct can hold the values.
there are different ways to approach this sort of problem, but here is
one possibility (example):
struct FieldInfo_s {
char *name; //name
char *sig; //signature string (identifies field type)
int flags; //access modifiers, ...
....
};
union ValueInfo_s {
void *pv;
int32 i; //substitute appropriate types
int64 l;
float f;
double d;
};
struct DynamicObject_s
{
FieldInfo **vars; //array of field references
ValueInfo *vals; //array of values
int n_vars; //number of vars in object
int m_vars; //max vars in object
};
pros:
more per-field information can be held this way, usually because the
fields can be managed independently of the objects;
more members can be added without re-allocating the object;
....
cons:
if the layout is static or semi-static, there are more efficient approaches;
using a union for the values, makes the union be the size of the biggest
possible value (larger value types may then require pointers, or may
otherwise waste lots of memory);
the little detail of "signature strings" (*1);
....
*1: side-note, on signatures and types:
a signature string, for example, basically being an ASCII string, with
various letters or letter-pairs indicating types.
for example (a small part of my notation):
'i'=int(32-bit), 'j'=uint, 'l'=long(64-bits), 'm'=ulong(64-bits),
'c'=char(8 bit), 'h'=byte, 's'=short, 't'=ushort, 'f'=float, 'd'=double,
'Cd'=complex-double,'Gd'=imaginary-double,
'r'=variant (dynamically-typed-reference, *2),
....
'P'=pointer, ex: "Pi"="int*", "PPv"="void **",
'A256;i'=int[256], "Qd"=double[],
'U<name>;'=user (named) type,
'X<name>;'=struct/union/value-class type,
'L<name>;'=reference class/interface type,
....
with "(...)..." basically giving the syntax for functions/methods.
"(Pcd)i" meaning "int _(char *, double);".
sadly, there is a bit more notation than this...
an advantage of ASCII here is "human readable" signature strings, vs say
using a binary representation and displaying them as hex, which is much
less readable.
note that signature strings may be orthogonal to the use of
"type-names", or basically, a higher-level name used to describe a type.
it is also generally more flexible and versatile than another
potentially tempting strategy: bit-packing all of the type information
into a 32 bit integer (say, with various internal bit fields giving the
type, size for small arrays, ...).
it may seem at first like 32-bits is plenty, but soon enough it gets to
be an ugly mess (with lots of conditionally-existent fields and flags, ...).
another case is using a struct.
structs may have the advantage of being faster and easier to work with
in many cases, but with drawbacks as well. hence, it may make sense to
use structs for some uses internally, but leave signature strings mostly
as the "canonical" representation for serialized types.
*2: dynamic types
usually, these take an entirely different approach.
fairly common is to by some means either encode the type into the
pointer/reference, or within the pointed-to object.
one popular option here is the use of "tag bits", where the low 3 or 4
bits or so of a pointer is used to encode parts of the type. a downside
though is that this forces any such pointers to be aligned (and also
typically involves bit-twiddly on the pointers).
another strategy (the one I am using), was to have special "magic"
address ranges (generally outside usable parts of the address space)
which encode certain types (such as small integers held in pointers).
this doesn't require any particular alignment for general pointers, but
may reduce the number of bits available for "special" types (for
example, only 28-bits for a "fixnum" type, rather than 30 bits, ...).
another minor advantage is that it doesn't require bit-twiddly on the
pointers (a person instead checks ranges and adds/subtracts a base address).
with most everything else, the type can be determined by the pointed-to
object (say, using a memory manager which is able to remember the types
of objects, which may be given when the object is allocated).
typically, in my case, these objects are identified via a type-name
rather than via a signature. some people prefer magic type-numbers, but
a drawback here is that they need to be centrally assigned to avoid
clashes, whereas with a string it is much easier to avoid a clash (and
they can be mapped to integer values internally).
the usual downside of dynamic typing though is that dynamic
type-checking isn't free (so, usually, it is much more preferable to
find ways around having to check the type).
or such...
Thanks