I see. Since we're using V8 as a pure scripting language extension in conjunction with C++ I guess I'm not so fussy about the actual spec definition -- sounds perfectly reasonable though, and actually storing it as a double is now working fine for us (I added some clean .isInt64() discrimination to our C++ so we can no longer truncate accidentally)
Thanks for the explanation. On Jul 15, 8:16 pm, Anton Muhin <[email protected]> wrote: > Alexander, > > I think v8 just follows ECMAScript standard here, see section 8.5 The > Number Type, which imho means that you cannot precisely store integers > with more than 52 bits. Note as well that it singles out 32 bit > integers as an important case (e.g. indices of arrays). So API just > follows the spec here. > > yours, > anton. > > On Thu, Jul 15, 2010 at 1:17 PM, Alexander M Beedie <[email protected]> wrote: > > > Hi all, > > > Any chance of exposing a 64bit-friendly constructor for the v8 Integer > > class? We've just been hit with a problem that led to some bad numeric > > truncation -- looking through the v8.h header I can see that the > > return from Integer's 'Value()' member is already an int64_t, but the > > New construct forces you to instantiate with an int32_t or a uint32_t. > > > How about a NewFrom64 and a NewFromUnsigned64 to go alongside New and > > NewFromUnsigned? (Assuming the internal representation is already > > 64bit; if not, how about an explicit Integer64 class?) I don't really > > want to have to stash the value in a double/float and lose integer > > precision if it can possibly be avoided. > > > Many thanks, > > > -A > > > -- > > v8-users mailing list > > [email protected] > >http://groups.google.com/group/v8-users > > -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
