Hi,
With the new version of CINT just uploaded to the ROOT CVS repository, when compiled with gcc std::string::npos is now a size_t (Note that it actually does not matter that much anyway as pointed by Christian).
Cheers,
Philippe.
-----Original Message-----
From: owner-roottalk_at_pcroot.cern.ch [mailto:owner-roottalk_at_pcroot.cern.ch]
On Behalf Of Roland Kuhn
Sent: Thursday, September 21, 2006 3:12 AM
To: Christian Holm Christensen
Cc: Tobias Raufer; roottalk_at_cern.ch
Subject: Re: [ROOT] Problem with std::string::npos in CINT
Hi Christian!
On 21 Sep 2006, at 02:33, Christian Holm Christensen wrote:
> Hi Tobi,
>
> On Wed, 2006-09-20 at 12:23 -0500, Tobias Raufer wrote:
>> Hi RootTalk,
>>
>> I am using version 5.11/02 built from source on a Suse 10 system.
>>
>> I seem to have a problem when using STL strings in CINT. Consider the
>> following short macro:
> ...
>> string testString = "Hello";
>> cout << "Find x: " << testString.find("x") << endl;
>> cout << "string::npos: " << string::npos << endl;
> ...
>> root [0] .x test.C
>> Find x: 4294967295
>> string::npos: -1
>> root [1]
>
> Believe it or not, but 4294967295 and -1 are the same :) If you do
>
No, they ain't. CINT is incorrect in providing string::npos as signed
integer. It does not matter that the bits in the i386 representation
are the same, the types of string::npos and string::find() must be
identical because they're meant to be compared.
The STL takes care to get this right, so it must be a bug in CINT.
Ciao,
Roland
-- TU Muenchen, Physik-Department E18, James-Franck-Str., 85748 Garching Telefon 089/289-12575; Telefax 089/289-12570 -- CERN office: 892-1-D23 phone: +41 22 7676540 mobile: +41 76 487 4482 -- Any society that would give up a little liberty to gain a little security will deserve neither and lose both. - Benjamin Franklin -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GS/CS/M/MU d-(++) s:+ a-> C+++ UL++++ P+++ L+++ E(+) W+ !N K- w--- M + !V Y+ PGP++ t+(++) 5 R+ tv-- b+ DI++ e+++>++++ h---- y+++ ------END GEEK CODE BLOCK------Received on Fri Sep 22 2006 - 04:07:38 MEST
This archive was generated by hypermail 2.2.0 : Mon Jan 01 2007 - 16:32:01 MET