Problem wit TGenericTable

Hi,

I’m trying to store TGenericTable as an object in a root file. Root version 5.34.01, inside a compiled code. I roughly follow the example from here: root.cern.ch/root/html534/TGenericTable.html

struct imageData_t {
Int_t npiX;
};

imageData_t idata;
TGenericTable *idataTable = new TGenericTable(“imageData_t”,2);
idata.npiX=100;
idataTable->AddAt(&idata);

and I get error during compilation:
undefined reference to TGenericTable::TGenericTable(char const*, int)

of course I have #include “TGenericTable.h”

what may I do wrong?

Cheers,  Mariusz

Try to add “-lTable” to your linker command line.

Thanks, that helps.
But I have runtime error now:

static TTableDescriptor* TTableDescriptor::MakeDescriptor(const char *): Assertion cl!=0 failed.

what could it be?

Mariusz

Have you generated (and linked it with your executable) a (ROOT-)CINT dictionary for your 'imageData_t" class/structure?
That’s a purely rhetorical question, of course. :wink: :mrgreen:

[quote=“Wile E. Coyote”]Have you generated (and linked it with your executable) a (ROOT-)CINT dictionary for your 'imageData_t" class/structure?
That’s a purely rhetorical question, of course. :wink: :mrgreen:[/quote]
One may not create the dict for the C struct.
Try

[code]root [0]
root [0] gSystem->Load(“libTable”)
(int)0
root [1] gROOT->ProcessLine(" struct imageData_t {Int_t npiX;}; TDataSet *idataTable = new TGenericTable(“imageData_t”,2);TDataSet::GetMainSet().Add(idataTable)")
(Long_t)0
root [2] TDataSetIter next(TDataSet::GetMainSet())
root [3] TTable *t = (TTable *)next()
root [4] t.Print(0)


DSMAIN/TGenericTable Allocated rows: 2 Used rows: 0 Row size: 4 bytes

There is NO filled row in this table

(const Char_t*)0x0

[/code]
This should work from the compiled code too. This way the TROOT::ProcessLine creates the ROOT Dictionary for the 'imageData_t" with no extra build step.

I would rather discourage people from using Valeri’s trick.
Even if it works in some simple cases, it may easily fail in more complex ones, especially when mixing compiled and interpreted code (or when an “interpreted class” inherits from a “pre-compiled one”).
Dictionaries should (always) be built by compiled code (i.e. by the compiler), not interpreted one (i.e. CINT).
Only this approach ensures proper “data alignment” / “structure padding”, so that the structure (or class) will be seen in exactly the same way in compiled and in interpreted code.
For more precise informations -> ask Philippe. :mrgreen:

[quote=“Wile E. Coyote”]I would rather discourage people from using Valeri’s trick…[/quote]No, It is not a trick and it will be working always as soon as TGenericTable class is concern,[quote=“Wile E. Coyote”] Even if it works in some simple cases, it may easily fail in more complex ones, [/quote]Yes, I agree.
However, the class in question is dedicated to those “simple cases”. Check the root.cern.ch/root/html534/TTable.html It says, [quote]. . . Wraps the array of the plain C-structures (one C-structure per element) . . . [/quote][quote=“Wile E. Coyote”]especially when mixing compiled and interpreted code (or when an “interpreted class” inherits from a “pre-compiled one”)…[/quote] What do you mean speaking “more complex” one? The class in question,namely TGenericTable is derived from TTable . The later is dedicated for the simple C struct ONLY. For the rest, “more complex” cases, one should use TObjArray / TTree anything but TGenericTable .[quote=“Wile E. Coyote”]Dictionaries should (always) be built by compiled code (i.e. by the compiler), not interpreted one (i.e. CINT).[/quote]Well, STAR exp at RHIC has been working with TGenericTable for 15 years soon. So far so good. [quote=“Wile E. Coyote”]Only this approach ensures proper “data alignment” / “structure padding”, so that the structure will be seen in exactly the same way in compiled and in interpreted code.[/quote] Yes, I agree that the compiled code should be used to calculate the alignment. Pay your attention TGenericTable / TTable codes are loaded from the shared library. It is the compiled code, It does calculate the alignment correctly. Please, file the bug report as soon as you find the issue to fix.

Thank you