I’m not sure if this is possible to do. I am trying to generate an array of TStrings using calloc, and I’m running into segmentation violations (perhaps because of the variable size of the TStrings?). Here is the code:
TestClass::TestClass()
{
theString = (TString*)calloc(10,sizeof(TString));
for( Int_t i=0; i<10; i++ )
theString[i] = “”;
}
[/code]
And here are the commands I enter at the ROOT prompt:
Now I could probably use new instead of calloc, but here’s the rub: I’d like to be able to increase the size of this array if necessary, using realloc.
There might be one way around this, doing something like this:
and then keep on using the larger array s1. I’d like to avoid this method if I could, though, just because of the overhead in copying over all the existing TStrings. realloc seems to be a nicer approach, except for the segmentation violation.
The short answer is “don’t use calloc/realloc on C++ object”.
Instead, simply use a std::vector
Cheers,
Philippe
PS. More details:
[quote]Now I could probably use new instead of calloc, but here’s the rub: I’d like to be able to increase the size of this array if necessary, using realloc[/quote]In order for a C++ object to initialized properly, you must call one the operator new (so that the constructor is called correctly). You can properly pull this off, if add a loop to call the operator new with placement for each of the un-initialize array.
Using realloc on C++ object is in the general case (because some data member might point to some inner portion of the object themselves (for example with an implied linked list). However indeed, it should be save with a TString.
I created an extra step using an std::vector of TStrings, and once all the data was processed and I knew the final size of the array I wanted, I called new and transferred all the data to the array in a single loop.
[quote]Out of curiosity, why don’t use directly the vector of TStrings?
[/quote]
I am writing to a TTree, and I am running into difficulties accessing the TString information, let alone if there were a vector of TStrings in the output file.
For example, when I use a TBrowser to access the output file, the TStrings are represented as branches instead of leaves. If I navigate inside the branches, the TString methods are available, but they all have red exclamation points through them, with the only “normal” looking leaf being fData. Unfortunately, double-clicking of the fData leaf to see what’s in there returns this error:
Even when I open the file and use the TTree::MakeClass method, all the TStrings are left out.
Right now I am trying to figure out if my problem is with the LinkDef file I am using (using base/inc/LinkDef2.h as an example), but if you have any tips on where to look for my errors, I’d be happy to hear them.
[quote] but if you have any tips on where to look for my errors, I’d be happy to hear them.[/quote]I am unfortunately I ‘missed’ your lastest error message (so I have no clue what the issue might be . If you send me more details (like a fully working/failing example, I would be able to take a look).
[quote]Error in TBufferFile::CheckByteCount: object of class volume read too few bytes: 2 instead of 10[/quote]This is a bit strange. Can you provide an example.
The code is part of a geant simulation. If you wouldn’t mind reading past the geant code to see the ROOT part of what I’m doing, I’d be happy to upload a copy.
Oh, and when I said “look for my errors” in my previous post, I should have said, “look for my programming mistakes”. Sorry for the confusion.
[quote]This is a bit strange. Can you provide an example.
[/quote]
See my answer in root.cern.ch/phpBB2/posting.php? … ply&t=5377, I think the issue was that you were not using the new ROOT I/O hence not enabling the ability to read without you original shared library.
. If you send me more details (like a fully working/failing example, I would be able to take a look).