MakeProxy generates bad code in 5/18?

ROOT
1

Hi,
I use MakeProxy to generate a header file for 5.18. I then use rootcint to create the dictionary for the proxy with the following command line:

And when I try to compile the code I get the following errors from gcc 3.4:

lectionTreeProxy_Dict.cpp -c -o CollectionTreeProcessing/CollectionTreeProxy_Dict.o CollectionTreeProcessing/CollectionTreeProxy_Dict.cpp: In member function `ROOT::TBranchProxy& ROOT::TBranchProxy::operator=(const ROOT::TBranchProxy&)': CollectionTreeProcessing/CollectionTreeProxy_Dict.cpp:1924: error: non-static const member `const TString ROOT::TBranchProxy::fBranchName', can't use default assignment operator CollectionTreeProcessing/CollectionTreeProxy_Dict.cpp:1924: error: non-static const member `const TString ROOT::TBranchProxy::fDataMember', can't use default assignment operator CollectionTreeProcessing/CollectionTreeProxy_Dict.cpp:1924: error: non-static const member `const Bool_t ROOT::TBranchProxy::fIsMember', can't use default assignment operator

The error first occurs on the second of the two following lines of code:

CollectionTreeProxy::TPx_vector_vector_double__* dest = (CollectionTreeProxy::TPx_vector_vector_double__*) G__getstructoffset(); *dest = *(CollectionTreeProxy::TPx_vector_vector_double__*) libp->para[0].ref;

This is in a generated proxy object for a vector<vector >.

Am I doing something wrong, or has ROOT really done this?

Many thanks! Cheers, Gordon.

2

Hi Gordon,

What does your CollectionTreeProxy_LinkDef.h contains?

Cheers,
Philippe.

3

Hi,
It contains:

#ifdef __CINT__

#pragma link off all globals;
#pragma link off all classes;
#pragma link off all functions;

#pragma link C++ class CollectionTreeProxy;

#endif

Cheers,
Gordon.

4

Hi Gordon,

My apologies, I still can not reproduce the problem. Could you send me your
files: CollectionTreeProxy.h, CollectionTreeProxy_Dict.cpp as well as the user file that included by CollectionTreeProxy.h.

Thanks,
Philippe.

5

Hi Gordon,

One surprising thing is that in 5.18, I did not think MakeProxy was still generating a TPx_vector_vector_double__ (it should be TStl_…). If you did generate this header with 5.18, I would also need your ROOT file :slight_smile:

Thanks,
Philippe

6

It is getting even stranger. On Windows 5.18 generates a good C++ file - on Linux it generates a bad one. The source code generated is different. Either I’m giving it different inputs (but I think they are all in cvs!!) or there is something bad about the build I’m using on Linux. I’ll investigate more - but at the moment I think this might be a configuration problem!

7

Well, that was a bit embarassing. When I has having all those troubles with root 5.14 and vector<vector> I apparently modified the local LinkDef file on Linux, and so it wasn’t updated out of cvs, and so it contained some (bad) test code. Fixed that and everything seems to build. Sorry!

8

I am glad it is fixed :slight_smile:

Cheers,
Philippe.

9

Hello Gordon and Phillipe,

I can report that MakeProxy is working for v518.00 under SL4 linux. The TStl_ vectors are generated properly. (BTW I’m also working on the TopView/EventView ntuples and I’m able to access the stl vectors and TVector3 contents.)

Best Regards,
Oliver

10

Oliver - you should thank Philippe for that, at the very last minute (before the 5.18 release) he did a lot of work with a top view-like ntuple to make sure that make proxy worked correctly.

11

Yes, I’ve noticed in the release notes and indeed I’m very grateful for that. This is also a good opportunity to thank not only Phillipe but also the whole Root team for their huge effort making Root such an fantastic framework and the long standing prompt and competent support they grant to us mortals.

I still have two questions about the code generated by MakeProxy(). Is there a special reason why the Init(), Process(), Term() etc. member functions are not declared virtual as in the TSelector class? Since I’m not using the macro features of the proxy but always inherit to my different analysis task classes, it won’t work.

Another thing I’ve noticed is that the generated code compiles with ACLIC, it fails however when I try to compile it by hand. I always got error messaes from the linker about multiple defintions of some member functions. It looks to me that the forward declarations clashes with the inline statements somehow. I can solve the problem by removing the inline declarations and splitting the code in a header file (.h) and a corresponding implementation file (.cxx) in which I’ve put all the implementation code of the (formerly inline declared) member functions.

Cheers,
Oliver

12

Hi,
Yeah - MakeProxy seems to have been designed for ACLIC and using it with TTree Draw. However, I also use it as you do.

Here is what I do, and this seems to work on both Windows and Linux (i.e. I don’t need to change the source code when I move between platforms): I create a header file called “doit.hpp” (yeah, I know) and it contains the following:

virtual inline double doit(void) { return 1.0;}
virtual inline void doit_Begin (TTree *t) {}
virtual inline void doit_Terminate (void) {}

And then I have my actual work-horse classes that inherrit from my proxy and override doit_Begin and doit_Terminate.

If you do declare the methods virtual then you will have to make sure to call the inherrited methods.

As for the link problem, I don’t think I’ve seen that. But I’ve not had to do a makeproxy in a few months now, so if I modified the code to remove some forward decl I’ve forgotten.

Cheers, Gordon.