Added back the code that set the offset of variables with the offsetof function. This
code is running by default. Any code that includes #ifndef TRICK_ICG in
classes/structures will want this on.
Added a flag to ICG that allows us to turn off writing of these lines. If the flag
is present, ICG may write out io_src code for private/protected variables that it could
not reach if an offsetof function was required. Code cannot have any #ifndef TRICK_ICG
present in classes/structures for this to work.
We need to exclude STL or other template io_src code being created with they use
a protected/private enumerations, just like classes. Also remove a check for
a static bitfield, because you can't have a static bitfield.
refs #218
Changed the storage of offsets from bytes to bits to better handle bitfields.
Added code to track classes that are defined within other classes and are
private/protected. These classes cannot be used in templates because our
io_src code declares variables outside of the class that would try and use
these private/protected variables. When a template is found to use a
private/protected class it is skipped.
refs #218
Removed the requirement of passing flags throughout ICG indicating if we are
in an inherited class or not. Removed the init_attr friends throughout
Trick core headers.
Moved field offset calculations for inherited classes to when the inherited
classes are processed. This removes the need to have to remember if fields
were inherited or not, the offset already reflects the correct offset.
refs #218
Mostly working. This removes the use of offsetof from all I/O code. This was
the only reason we needed friends. In it's place we put the offset value that
clang has calculated for the field. Still need to work on virtually inherited
classes and confirm bitfields.
refs #218
I found that in ICG I have access to the canonical type of a variable which
in most cases is the type I should process. Doing this eliminates the
need for some of the code that resolved typedefs because the canonical type
has already done that.
refs #200
When a template is in a namespace the type that is marked for the node containing
the full definition of the type is elaborated. We need to go into
the elaborated name and get the underlying type. Added code to do this
and tests to see if the type we are checking is itself a template or the
elaborated type is a template. Sorry, this probably only makes sense to me.
refs #124
