RE: [ROOT] STL strings at the CINT / Compiled code boundary

From: Philippe Canal (pcanal@fnal.gov)
Date: Thu Aug 02 2001 - 16:39:54 MEST


Hi Robert,

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).

Cheers,
Philippe.

-----Original Message-----
From: owner-roottalk@pcroot.cern.ch
[mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Radovan CHYTRACEK
Sent: Thursday, August 02, 2001 4:47 AM
Cc: roottalk@pcroot.cern.ch
Subject: Re: [ROOT] STL strings at the CINT / Compiled code boundary


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.
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.

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.

Good luck

Radovan



This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:50:54 MET