I have built a simple Win32 console application that writes some data into a root file and then reads the file back and displays the data. I was ucessfull in running the read (ReadTree) and write (WriteTree) methods of my code (the script I use is PureCppCode\TTreeTest.cpp) through CINT, the data file is creted correctly and the ReadTree method reads everything just fine.
When I run the exact same code in the Win32 environement the WriteTree method works as usual however ReadTree crashes with a very strange error :
This happens at the line where I call the GetEntry methof of TTree:
for(int e=0;e<ntries ;e++)
test_tree->GetEntry(e) //this line crashes the program
The root files created by the code are also different. When the code is run through CINT the created file can be opened by the object browser normaly. When I run the same code as a Win32 app the object browser crashes when I try to look at the DoubleVector branch that contains vector values.
I have uploaded my aplication. Please note that the project file is VS2010 based(see: RootTestCode.zip (11.8 KB))
I managed to run this code after all. I had set up the project to run in Debug configuration whereas my ROOT installation was in Release thsu causing a serious error. After switching my project to Release mode the code runs as expected. It was rather unexpected for me to run into such serious memory issues and I’ll keep this in mind for my future projects.
Good to see you solved your problem. I was about to tell you to use the same configuration (Debug vs Release) than ROOT. This is required by the C++ runtime libraries (MSVCRT) on Windows…
The problem is the STL mostly - MS adds a bunch of debugging and run-time checks in the debug version of the STL which change their binary API’s (but not the source code ones). The result is you can’t have a debug STL container sent to a bit of release code.
There is an easy fix, however.
-> Make sure to always include w32pragma.h in every file (I generally just tell the compiler on the command line to force-include everything).
-> Define the same set of C++ macros in the release profile in the debug profile, and undefined the debug ones. This will generate a warning, but that warning can be ignored.