Re: [ROOT] string in tree

From: Nicolas Produit (Nicolas.Produit@obs.unige.ch)
Date: Mon Mar 31 2003 - 09:04:10 MEST


Rene Brun wrote:
> Hi Nicolas,
> 
> You cannot assume that elements in a C struct are aligned.
> Use a class instead of a C-struct if the length of the struct members 
> are different. In case of a class the dictionary is used to return the 
> right offset of each member inside the class.
> Your example will work if you change the position of the element "t"
> 
>     typedef struct {
>       Float_t x,y,z;
>       Float_t t;
>       Char_t c[4];
>     } POINT;

Hi,

unfortunately this is not so simple.
In fact I m trying to write a program to transform an arbitrary FITS 
table in a ROOT tree.
(FITS is a astrophysical file storage standard)
In a FITS tables there can be many string columns and it is desirable to 
keep the original
order of the elements.
In fact I don't have a proper struct because each FITS file will 
correspond to another struct.
I must work with just a flat array of byte and I compute myself the 
offset in this array.
But I was never able to figure out how to compute offset for char strings.
The program I gave in the mail was just an example to demonstrate my 
problem.

My questions are:

1- does \C make sense or should be always give the maximal length of the 
string like \C20 for example.
The documentation seems to say that \C stand for any string but I cannot 
see how this is possible.
2- In case of a declaration of \C20 can we store a shorter string?
3- I don't understand the alignment problem, in my example I gave c[4] 
because I thought that 4 bytes
is always a safe number for memory alignment. Is it (or should I use 8)? 
I can instruct my program to create only
string column having a safe number of bytes if this will help.


Thanks

-- 
Nicolas Produit
INTEGRAL Science Data Center    Phone:  +41 22 950 91 40
16, Chemin d'Ecogia             Fax:    +41 22 950 91 33
CH-1290 Versoix                 www:    http://isdc.unige.ch/



This archive was generated by hypermail 2b29 : Thu Jan 01 2004 - 17:50:10 MET