Christoph,
I will answer your question about supporting STL containers.
I agree with your point. From ordinary programmer's point of view, it is
quite rational to support STL. However, there are deep complications.
1) Instantiated template classes can be precompled, but template itself
can not. Polymorphic containers can be precompiled. In this sense STL
containers are less generic in CINT environment. I know ,
of course , STL containers are more generic in ordinary programming
environment.
2) Difficulty of supporting STL container is extraordinary. I'm trying to
support following precompiled containers using VC++.
vector<int> vector<long> vector<double> vector<void*> vector<char*>
list<int> list<long> list<double> list<void*> list<char*>
basic_string<char> == string
map<string,int> map<string,double> map<string,string>
The library can be built and works in very limited cases. These containers
are not good enough for public use.
3) The difficulty of STL torture major compiler makers too. Non of the
major compilers are 100% compliant to the standard yet. They have some
dialects. This makes extremely difficult for ROOT/CINT framework to
provide platform independent computing environment.
It is possible to provide template based container library. But. it is
a different story making it generic. I agree with Rene's recommendation
that polymorphic containers are more generic in ROOT/CINT.
Masaharu Goto
----------------------------------------------------------------------
On Fri, 23 Oct 1998, Rene Brun wrote:
[...]
> Obviously, we could extend the size of these tables. It is my
> understanding that Masa is working in replacing his static tables
> by dynamic tables. However, I cannot resist in making the following
> remark:
> Why do you use templates at all to solve this trivial problem?
> It would be so much simpler to replace your tables (I assume it is
> Adamo) by a simple TObjArray of TObject derived objects.
> You will gain in all possible aspects:
> - simplicity
> - portability
> - performance
> - functionality (possibility to inspect/Dump/Browse)
Hello Rene,
maybe I did not describe the trivial problem correctly: The FORTRAN stuff
runs at the same time and moves the objects in memory (ZEBRA) and in C++
you have to match the FORTRAN memory layout. But that was not my point, as
there may be not too many ROOT users with the same problem and so that my
solutions may not be of common interest.
But how is the discussion status of container models? The ROOT containers
implement the pure polymorphic version. My experience shows, that the vast
majority of containers for physics applications (in contrast to pads etc)
just store objects of the same types. For example, I currently deal with
an ObjArray of reconstructed tracks, and want to fit vertices. Since I
know, I have stored only reconstructed tracks, I just do downcasting. I
assume, everyone elso does the same without the InheritsFrom-check. In my
opinion, it would increase the safety, if it would be possible to declare
containers for certain types. This would still allow polymorphic
structures on more than Draw, Print, and Dump functions.
A templated container with STL compatible iterators would also be a great
improvement for certain applications in compiled code. We have, for
example, certain STL maps and sets for some channel information, which up
to now is very separated from the ROOT containers. If one could use the
STL algorithms to interface these, we would gain a lot. This does not
mean, that I would like to see the value-based concept of STL in the ROOT
containers, the typedefs would be enough.
How big will be the interest in the ROOT community in this? I have written
a templated wrapper for TObjArray, which provides STL compatible
iterators. I have used the Rtypes.h adaption of Stefan Kluth for templated
ClassDefs and ClassImps. If there is some interest in it, I could extract
this for the contrib directory. We have to be aware, that this does not
work with gcc 2.7, which does not provide static template members (fgIsA).
What do you think? Should this discussion go to roottalk?
Kind regards
Christoph Borgmeier
--
Christoph Borgmeier Mail: DESY F15/HERA-B, Geb. 61/117
Notkestr. 85, 22607 Hamburg
Humboldt Univ Berlin Phone: +49 40 8998 4850
Email: Christoph.Borgmeier@desy.de
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:34:39 MET