I’m actually not sure whether this is the right place for this, it might better go to Savannah right away. In any case, here is my problem:
I’m trying to do something very non-trivial. I don’t know how this design pattern would be called, but I’m creating a class that inherits from its template parameters. (In the actual code it does serve a purpose…) The template parameters inherit from TObject themselves, and I would like to create dictionaries for all the classes in question.
The design works perfectly as long as the templated class only inherits from one template parameter. If the class has two or more template parameters from which it inherits, the compilation of the generated dictionary fails with messages like:
no unique final overrider for ‘…’
I have no idea what this should mean. I tried searching the web for this kind of message, but to no avail. Does any one of you know what could cause this?
I attached a simplified version of what I’m trying to do.
Since this is quite a special case, I wouldn’t be surprised if the dictionary generation would get confused by my code and would generate faulty results, but it could still be that I’m doing something foolish that could easily be corrected on my part. (Apart from using a different design pattern. )
[quote]no unique final overrider for ‘…’ [/quote]This indicates that you inherit several times (indirectly) from the same class (problably TObject). This is not support by C++ unless you use virtual inheritance. Virtual inheritance is not yet well supported by the ROOT I/O subsystem.
I strongly recommend that, in your application, you reconsider using inheritance for this. Instead you might want to “contain” the template parameter (rather than derive from them).
The error messages indeed indicate what you describe. But I believe this is somehow due to the ClassDef macros not dealing correctly with the situation. I looked through all the macros defined in Rtypes.h trying to make the dictionary generation work with some combination of them, but I didn’t succeed yet.
Virtual inheritance shouldn’t be a problem per se, I’ve been using classes with “diamond shaped” inheritance graphs for a while now with ROOT. In fact I wanted to make one such class be a template class now as I wanted to extend its functionality. If I make the class inherit directly from its constituents, then everything works fine. If it inherits from them using this template method, then the dictionary can’t be compiled. (The “normal” ROOT code compiles without warnings.)
I suppose I can come up with another design for the problem, but it would’ve been much more elegant than anything I can think of right now.
[quote]But I believe this is somehow due to the ClassDef macros not dealing correctly with the situation. [/quote]Did you add a ClassDef in your templated class?
I think this is the way it should be done. At least it does work like that if my template class has only one template parameter. In case it has more, the rootcint generated code doesn’t compile.
In any case, the problem is solved now. Instead of using this design, I added a lot of interface classes to my code and my “super class” is constructed using those. (The “super class” can see functions of the other constituents through the pure virtual interfaces while the actual implementations for these functions are only added on the same level as the “super class”.)
But in general ROOT doesn’t seem to like templated classes too much. For instance I was using a template class with >4 template parameters a while ago for which it was also impossible to generate a dictionary. I guess I just try too extreme things…
[quote]
I think this is the way it should be done. At least it does work like that if my template class has only one template parameter. In case it has more, the rootcint generated code doesn’t compile.[/quote]Yes it is. It just sounded like you might not have.
[quote]But in general ROOT doesn’t seem to like templated classes too much. For instance I was using a template class with >4 template parameters a while ago for which it was also impossible to generate a dictionary.[/quote]Humm, I don’t remember this limitation … If you can reproduce it with a standalone example, please report it via Savannah so we can fix in Cint 7 (I.e. after the finalization of the Reflex/Cint merger).
)