On Thu, 2 Aug 2001, Philippe Canal wrote:
> On Thu, 02 Aug 2001, Radovan CHYTRACEK wrote:
> > Robert Hatcher wrote:
> > >
> > > My system: ROOT 3.01/06+ (CVS as of Jul 27), Linux RH6.2
> > > (attempted with different machines having egcs and gcc2.95)
> > >
> > > I have some compiled classes that use STL strings as args and return
> > > values. I'd like to interact with these from within a CINT macro.
> > > But neither of these seems to work. In passing a CINT string
> > > to a compiled routine it complains about a signature mismatch.
> > > In the reverse it tends to fill the CINT string with garbage
> > > that generally leads to unhappiness (SEGV or random characters
> > > that change the terminal's character set).
> > >
> > > ... snipped
> >
> > I think problem is due to CINT's own version of STL containers.
Yes, that was my diagnosis. But identifying the problem doesn't fix it --
thus my query.
> > In order to succefully pass a data between CINT and compiled code you can
> > try the
> >
> > const char*
> > const char*& or const char**
> >
> > depending on what you want to do. Inside the functions I expect one must
> > be able to initialize STL strings with these char pointers.
When I wrote I had already done such wrappering for the particular
cases I needed immediately. The problem is that this is both ugly
and problematic in cases where I shouldn't be mucking with interfaces
of a class. In this case I could get away with it (even though it
wasn't a class I wrote), but in general that isn't the case -- in
such cases one is forced to subclass and add such an interface.
In terms of the returning of a string one has to introduce a different
interface altogether (ie. one can't overload a method name, as return
type isn't part of the method signature).
> > I remember from Gaudi-ROOT excercises that the pointer reference ( e.g.
> > const void*& ) had some problem in CINT but I think it has been fixed
> > since the time.
> As pointed out by Radovan, the problem is one of mismatch between the
> interpreted version of std::string and the compiled version.
> You might want to try building the cintdlls (gmake cintdlls) and try
> again (on most platform the cintdlls will exposed a compiled version
> of the std::string to the interpreter).
This suggestion I don't understand at all.
ROOT_CVS/root> gmake cintddls
gmake: *** No rule to make target `cintddls'. Stop.
There doesn't seem to be _any_ reference to "cintddls" anywhere in any file:
ROOT_CVS/root> find . -type f -exec grep -l cintddl {} \;
ROOT_CVS/root>
Is this something that is not part of the CVS version of ROOT?
Also, if such exists why isn't it a standard part of the ROOT building
process? Does that mean that collaborators could never freeze out
using a binary distribution, but would always be required to build
this for themselves? The point is users of ROOT would naturally
expect seamless integration across this CINT/compiled boundary and
are suprised by such cases where it isn't there (in this case STL
strings).
> > > My system: ROOT 3.01/06+ (CVS as of Jul 27), Linux RH6.2
> > > (attempted with different machines having egcs and gcc2.95)
-robert
Robert W. Hatcher | rhatcher@slac.stanford.edu
Research Associate | 650.926.3171 [FAX 4001 or 3587]
Stanford University | PO Box 4349, MS #63, Stanford CA 94309
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:56 MET