Hi Philippe, Wow, thanks for your quick reply! If I change in my STLClass.h file the vector<int,__malloc_alloc_template<0> > to just vector<int> in order to use the default STL allocator, then the rootcint generated STLClassdict.cc file fails to compile with a complaint that the allocators are mismatched. For example: In file included from STLClassdict.cc:111: /usr/include/g++-3/stl_pair.h: In method `pair<_T1, _T2>::pair (const pair<_U1, _U2> &) [with _U1 = int, _U2 = vector<int, __malloc_alloc_template<0> >, _T1 = const int, _T2 = VecInt]': /usr/include/g++-3/stl_map.h:162: instantiated from here /usr/include/g++-3/stl_pair.h:48: no matching function for call to `vector<int, allocator<int> >::vector (const vector<int, __malloc_alloc_template<0> > &)' Apparently the dictionary generator likes to use the __malloc_alloc_template<0> allocator, at least in my build of ROOT. Is this the problem that you just fixed? I had assumed that you guys were using the slower __malloc_alloc_template allocator for thread-safety. Thanks, Aaron On Wednesday 15 January 2003 05:38 pm, Philippe Canal wrote: > > (I have to use the malloc_alloc allocator here in order to get the Cint > > dictionary to compile. Is there some way to force the dictionary > > generator > > > to use the standard STL allocator by default? Or to force gcc 2.96 to > > use malloc_alloc by default?) > > Yes. Just use __tomorrow__'s CVS repository. (as it happens I just fixed > this problem a few minutes ago). > > > Are STL containers of containers not yet supported in ROOT or am I doing > > something wrong? > > Using __malloc_alloc_template instead of the default allocator, just serves > to confuse the STL library and/or the ROOT stl streamers. > > Cheers, > Philippe > > -----Original Message----- > From: owner-roottalk@pcroot.cern.ch > [mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Aaron Chou > Sent: Wednesday, January 15, 2003 4:42 PM > To: roottalk@pcroot.cern.ch > Subject: [ROOT] Objects containing STL map of vectors? > > > Hi, > > (Using Root 3.04.02 on RedHat Linux 7.3 with gcc 2.96). > > I'm having trouble filling a tree in which one of the branches is an > user-defined object containing a STL map like this: > > STLClass.h: > > #include <vector> > #include <map> > #include "TObject.h" > > typedef vector<int,__malloc_alloc_template<0> > VecInt; > > class STLClass : public TObject > { > private: > map<int, VecInt > A; > > public: > STLClass(); > ~STLClass() ; > void AddInt(int a,int b); > > friend ostream& operator<<(ostream&, const STLClass&); > ClassDef(STLClass,1) > }; > > > (I have to use the malloc_alloc allocator here in order to get the Cint > dictionary to compile. Is there some way to force the dictionary generator > to use the standard STL allocator by default? Or to force gcc 2.96 to use > malloc_alloc by default?) > > I use a Makefile to build the STLClass.so library and then use AClic to > compile and run a program called WriteSTL.cc to test it. > > WriteSTL.cc: > #include <iostream> > #include "STLClass.h" > #include "TROOT.h" > #include "TClassTable.h" > #include "TFile.h" > #include "TTree.h" > void WriteSTL() { > TFile tf("STLTest.root","recreate"); > TTree MyTree("STLTest","STL Test"); > > STLClass *MyClass = new STLClass(); > MyTree.Branch("STL_branch","STLClass",&MyClass); > for (int j=0;j<5;++j) { > for (int i=0;i<10;++i) { > MyClass->AddInt(i,i*j); > } > cout << "filling" << endl; > MyTree.Fill(); > cout << "filled" << endl; > } > cout << "writing" << endl; > tf.Write(); > tf.Close(); > } > > > Here is my ROOT command line input, and the segmentation fault that > results: > > root [0] .L STLClass.so > root [1] .x WriteSTL.cc++ > Info in <TUnixSystem::ACLiC>: creating shared library > /home/users/achou/programs/rootstuff/roottalk/./WriteSTL_cc.so > filling > > *** Break *** segmentation violation > Generating stack trace... > 0x401bc0af in TUnixSystem::StackTrace(void) + 0x25b from > /home/users/programs/root3_04_02/root/lib/libCore.so > 0x401bad2e in TUnixSystem::DispatchSignals(ESignals) + 0xb2 from > /home/users/programs/root3_04_02/root/lib/libCore.so > 0x401b9ed7 in <unknown> from > /home/users/programs/root3_04_02/root/lib/libCore.so > 0x401bd971 in <unknown> from > /home/users/programs/root3_04_02/root/lib/libCore.so > 0x40ccd307 in <unknown> from /lib/libpthread.so.0 > 0x40d65ef8 in <unknown> from /lib/libc.so.6 > 0x40184c81 in TClass::Streamer(void *, TBuffer &) + 0x21 from > /home/users/programs/root3_04_02/root/lib/libCore.so > 0x4010ad00 in TBuffer::StreamObject(void *, TClass *) + 0x24 from > /home/users/programs/root3_04_02/root/lib/libCore.so > 0x4149433d in R__STLClass_A__FR7TBufferPvi + 0x3b5 from > /home/users/achou/programs/rootstuff/roottalk/./STLClass.so > 0x401a60e9 in TStreamerInfo::WriteBuffer(TBuffer &, char *, int) + 0x1bc5 > from /home/users/programs/root3_04_02/root/lib/libCore.so > 0x40b5c54b in TBranchElement::FillLeaves(TBuffer &) + 0x34b from > /home/users/programs/root3_04_02/root/lib/libTree.so > 0x40b56b40 in TBranch::Fill(void) + 0x214 from > /home/users/programs/root3_04_02/root/lib/libTree.so > 0x40b5c18b in TBranchElement::Fill(void) + 0x117 from > /home/users/programs/root3_04_02/root/lib/libTree.so > 0x40b5c16d in TBranchElement::Fill(void) + 0xf9 from > /home/users/programs/root3_04_02/root/lib/libTree.so > 0x40b72794 in TTree::Fill(void) + 0x80 from > /home/users/programs/root3_04_02/root/lib/libTree.so > 0x40cbd828 in WriteSTL(void) + 0x108 from > /home/users/achou/programs/rootstuff/roottalk/./WriteSTL_cc.so > 0x40cbda57 in <unknown> from > /home/users/achou/programs/rootstuff/roottalk/./WriteSTL_cc.so > 0x405c35ab in G__call_cppfunc + 0x237 from > /home/users/programs/root3_04_02/root/lib/libCint.so > 0x405b2e3d in G__interpret_func + 0x895 from > /home/users/programs/root3_04_02/root/lib/libCint.so > 0x405995ec in G__getfunction + 0x1bb4 from > /home/users/programs/root3_04_02/root/lib/libCint.so > 0x40590f71 in G__getitem + 0x509 from > /home/users/programs/root3_04_02/root/lib/libCint.so > 0x4058f6ff in G__getexpr + 0x8c3f from > /home/users/programs/root3_04_02/root/lib/libCint.so > 0x405867a2 in G__calc_internal + 0x38e from > /home/users/programs/root3_04_02/root/lib/libCint.so > 0x405e718f in G__process_cmd + 0x23eb from > /home/users/programs/root3_04_02/root/lib/libCint.so > 0x4017a33a in TCint::ProcessLine(char const *, TInterpreter::EErrorCode *) > + > 0x9a from /home/users/programs/root3_04_02/root/lib/libCore.so > 0x4017a428 in TCint::ProcessLineSynch(char const *, > TInterpreter::EErrorCode > *) + 0x48 from /home/users/programs/root3_04_02/root/lib/libCore.so > 0x40102166 in TApplication::ProcessFile(char const *, int *) + 0x6e2 from > /home/users/programs/root3_04_02/root/lib/libCore.so > 0x401018d0 in TApplication::ProcessLine(char const *, bool, int *) + 0x4ec > from /home/users/programs/root3_04_02/root/lib/libCore.so > 0x40c9921b in TRint::HandleTermInput(void) + 0x127 from > /home/users/programs/root3_04_02/root/lib/libRint.so > 0x40c98540 in TTermInputHandler::Notify(void) + 0x28 from > /home/users/programs/root3_04_02/root/lib/libRint.so > 0x40c9987b in TTermInputHandler::ReadNotify(void) + 0x13 from > /home/users/programs/root3_04_02/root/lib/libRint.so > 0x401bb123 in TUnixSystem::CheckDescriptors(void) + 0x113 from > /home/users/programs/root3_04_02/root/lib/libCore.so > 0x401ba836 in TUnixSystem::DispatchOneEvent(bool) + 0x112 from > /home/users/programs/root3_04_02/root/lib/libCore.so > 0x4014cf8d in TSystem::InnerLoop(void) + 0x1d from > /home/users/programs/root3_04_02/root/lib/libCore.so > 0x4014cf22 in TSystem::Run(void) + 0x7e from > /home/users/programs/root3_04_02/root/lib/libCore.so > 0x401024dd in TApplication::Run(bool) + 0x31 from > /home/users/programs/root3_04_02/root/lib/libCore.so > 0x40c98d56 in TRint::Run(bool) + 0x2ba from > /home/users/programs/root3_04_02/root/lib/libRint.so > 0x08048792 in main + 0x52 from > /home/users/programs/root3_04_02/root/bin/root.exe > 0x40d551c4 in __libc_start_main + 0x90 from /lib/libc.so.6 > 0x08048661 in __register_frame_info + 0x35 from > /home/users/programs/root3_04_02/root/bin/root.exe > > As you can see, the segmentation violation occurs when I try to fill the > tree. > The same code works if I replace the map with: > > map<int, VectorWrapper> > > where VectorWrapper is just a wrapper class which stores the > vector<int,__malloc_alloc_template<0> > and does nothing else. > > Are STL containers of containers not yet supported in ROOT or am I doing > something wrong? I've included all code in an attached .tgz file. > > Many thanks, > > Aaron
This archive was generated by hypermail 2b29 : Thu Jan 01 2004 - 17:50:08 MET