Persistant Custom Class with Pointers to ROOT Objects

Hi,
I’ve go two questions concerning a custom class which contains pointer to certain ROOT objects.

My class looks similar to this one:

class TMyContainer: public TNamed
{
public:
  TMyContainer() 
  {
    ...
  }

private:
  TMap * fMyMap;
  TH1F*  fMyHisto;

  ClassDef(TMyContainter,0)
};

ClassImp(TMyContainer)

The first question is related to the TMap pointer and to the constructor.
I would like to provide an empty map in the constructor by writing something like

  fMyMap = new TMap(...);

Would this leak memory, when i read a class which previously written to a file? If I understand ROOT correctly, for reading an object from a file a new instance of my class is created and then the “right” contents is filled by the streamers. In this case the space on heap, allocated by the new in the constructor would be lost.

The second question is related to the TH1F pointer. If I write an object of my class to disc the histogram, which my class points to seems to be written to disk in any case. In my case I always know, that the histogram is already written to the file. Is there a way to avoid duplicated copy of the histogram in the file?

Thanks in advance, J.

[quote]
Would this leak memory, when i read a class which previously written to a file?[/quote]No,  but do not forget to delete the TMap object in you destructor (i.e. ~TMyContainter).
[quote]
 In this case the space on heap, allocated by the new in the constructor would be lost.[/quote]No.  ROOT will delete the previous one.

[quote]In my case I always know, that the histogram is already written to the file. Is there a way to avoid duplicated copy of the histogram in the file? [/quote]Yes, mark the pointer as 'transient':[code]TH1F*  fMyHisto; //![/code]Then the I/O will no longer touch this pointer at all (neither read nor set it).

Cheers,
Philippe

[quote]
Would this leak memory, when i read a class which previously written to a file?[/quote]No, but do not forget to delete the TMap object in you destructor (i.e. ~TMyContainter).

[quote]
In this case the space on heap, allocated by the new in the constructor would be lost.[/quote]No. ROOT will delete the previous one.

[quote]In my case I always know, that the histogram is already written to the file. Is there a way to avoid duplicated copy of the histogram in the file? [/quote]Yes, mark the pointer as ‘transient’:TH1F* fMyHisto; //!Then the I/O will no longer touch this pointer at all (neither read nor set it).

Cheers,
Philippe

Thank you for your answer.

I already recognized this mistake, as you can read in a different thread :smiley:.

I think this is not exactly what I want. I want to use my class more or less as “lookup table” for histograms, which are stored in a file. For this the class member need to point to a histogram after I read back the class from the file. What I’ve observed is the fact, that writing my class to disk seems to save another copy of the histogram to disk, even, if it’s already written to the file. Can one avoid this duplication?

Cheers, J.

Hi,

[quote]I think this is not exactly what I want. I want to use my class more or less as “lookup table” for histograms, which are stored in a file. For this the class member need to point to a histogram after I read back the class from the file. What I’ve observed is the fact, that writing my class to disk seems to save another copy of the histogram to disk, even, if it’s already written to the file. Can one avoid this duplication? [/quote]The simpliest is probably to save the histogram only with your class (for this call myhiso->SetDirectory(0) and keep your previous syntax for the histogram pointer). Otherwise you would need to write a custom streamer that retrieve the histogram from the file.
Another alternative, is that you could keep the pointer transient and add a new data member holding the name of the histogram and implement a getter function that would do the fetch of the histogram from the TFile.

Cheers,
Philippe.

Thank you, the idea to use a map with the histogram names seems to be a pragmatical solution. I will try this.

Cheers, J.