Hi Robert,
the target is cintdlls NOT cintddls
-- Fons
On Mon, Aug 06, 2001 at 05:45:15PM -0700, Robert Hatcher wrote:
> 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
--
Org: CERN, European Laboratory for Particle Physics.
Mail: 1211 Geneve 23, Switzerland
E-Mail: Fons.Rademakers@cern.ch Phone: +41 22 7679248
WWW: http://root.cern.ch/~rdm/ Fax: +41 22 7677910
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:56 MET