|
|
|
Home » U++ Library support » U++ Core » FIX: UPP::Scan returns int64 for INT_V
|
|
|
|
| Re: FIX: UPP::Scan returns int64 for INT_V [message #32019 is a reply to message #31995] |
Sun, 17 April 2011 14:57   |
 |
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
could you provide the link to the thread? couldnt find it..
i understand, that for best/secure performance ConvertInt should be able to keep the *parsed* data type as complete as possible (int64, if enough info provided from string), even if 'later' in usage the int64 is downgraded to int.
but then, the problem should be solved in EditInt, because, at most, there, one could expect to have a true int value returned. but it is not easy, since EditInt is a EditMinMax<> typedef.
i took a look in the code again. the int64 seems to be there to be able to perform range test after conversion, and return ErrorValue. there is also the solution to the problem. if no error, the range is ok and an int can be generated.
Value ConvertInt::Scan(const Value& text) const {
Value v = UPP::Scan(INT_V, text);
if(IsError(v)) return v;
if(IsNull(v)) return notnull ? NotNullError() : v;
int64 m = v;
if(m >= minval && m <= maxval) return int(m);//v; <====
return ErrorValue(UPP::Format(t_("Number must be between %d and %d."), minval, maxval));
}
[Updated on: Sun, 17 April 2011 15:30] Report message to a moderator |
|
|
|
| Re: FIX: UPP::Scan returns int64 for INT_V [message #32021 is a reply to message #32019] |
Sun, 17 April 2011 21:23 |
 |
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| kohait00 wrote on Sun, 17 April 2011 08:57 |
but then, the problem should be solved in EditInt, because, at most, there, one could expect to have a true int value returned. but it is not easy, since EditInt is a EditMinMax<> typedef.
|
One should not. int/int64/double/bool are "poly" types, convertible one to each other. ValueTo is just implementation thing. You are expected to use automatic casts with Value wherever possible, not ValueTo. This is how things are designed, end of story. Coding is easier this way, as you do not have to care about exact type when not necessarry.
BTW, you have also to think about more complex context like Sql, where in fact the number type might not be known until the actual data is fetched from DB.
(Having said that, perhaps we would not really need both EditInt and EditInt64, but that is another story...)
|
|
|
|
| Re: FIX: UPP::Scan returns int64 for INT_V [message #32031 is a reply to message #32021] |
Mon, 18 April 2011 10:46 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
i'm actually not using ValueTo..
it was merely of logical convenience. the stuff i'm pointing to is what i stumble upon, while dealing with environments where the data type issue is still a matter. i'm not planning to change upp to my will, don't get me wrong here.
to have a 'predictable' interface is another design feature.. thats why i said that, dealing with EditInt, i expect to be dealing with int, no matter which container it is actually in, dealing with EditDouble with double.. this is user POV.
i agree, that EditInt probably is not needed, due to same reason why float is not in Value (remember  . it's a 'legacy', but here again, legacy means compatibility of types as well (as of me).
as of the SQL stuff. i think at this point, the data has been already analyzed and can continue to be dealt with as int, isnt it?
if(m >= minval && m <= maxval) return int(m);//v; <====
the other changes in the files are, again, only for logical completeness..
|
|
|
|
| Re: FIX: UPP::Scan returns int64 for INT_V [message #32041 is a reply to message #32031] |
Tue, 19 April 2011 07:28 |
|
mirek
Messages: 13975
Registered: November 2005
|
Ultimate Member |
|
|
| kohait00 wrote on Mon, 18 April 2011 04:46 |
as of the SQL stuff. i think at this point, the data has been already analyzed and can continue to be dealt with as int, isnt it?
|
No. Consider:
Sql sql;
sql * Select(NUMBER).From(TABLE);
sql.Fetch();
int x = sql[NUMBER];
At the line of assignement to 'x', at compile phase nothing is known about what data type DB returned - was it 'int' or 'double' or 'int64'?
[Updated on: Tue, 19 April 2011 07:29] Report message to a moderator |
|
|
|
| Re: FIX: UPP::Scan returns int64 for INT_V [message #32142 is a reply to message #32041] |
Wed, 27 April 2011 14:07 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
i still can't figure out where ConvertInt comes into play here with Sql..
i understand that operator[]() returns a Value, which content is determined at runtime. is it using a ConvertInt?
(have to admit i haven't used Sql in Upp yet).
if the fix is not possible with ConvertInt, ist there a possib to have sth like
class EditInt : public EditMinMax<int, ConvertInt>
{
public:
Value GetData() const { return int(EditValue::GetData()); }
}
anyway, the question is, what purpose does the ConvertInt serve to.. to convert stuff to a Value with an int inside. it does not know anything of Sql. so there is the problem..
what about the other completions to Convert?
[Updated on: Wed, 27 April 2011 15:13] Report message to a moderator |
|
|
|
|
|
| Re: FIX: UPP::Scan returns int64 for INT_V [message #32226 is a reply to message #32190] |
Mon, 02 May 2011 10:00 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
ok thanks for clearing up this stuff.
doing Python exporting currently, i see Value as sort of object and try to align them. and in python too, they have bool, int, long (64) and real (double) (and a few more complex, and ofcorse 'complex' which is not available in Upp at all currently, maybe an idea for the future).
so dont be too eager to remove INT_V too soon, since it's there in most scripting languages.
BTW: Value with its type checks is ideally suited as a data type container, where Is<>() is kind of natural approach to be certain about a type, where type differences do really matter (i.e. communication layers). i'm really lazy to invent a new layer to cope with that so i use what upp gives already..
|
|
|
|
|
|
|
|
|
|
|
|
| Re: FIX: UPP::Scan returns int64 for INT_V [message #32417 is a reply to message #32367] |
Tue, 17 May 2011 11:08 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
it's actually no problem in python. i do the translation as expected. int Value -> integer, int64 Value -> Long (which is not correct as well, python long: unlimited digits). this works fine. the problem arises for ConvertInt.
as i now understand ConvertInt, it's offering a margin check and returns an ErrorValue if the scanned int64 surpasses the int margin, so it's an error check feature. (the margins are the only difference between ConvertInt and ConvertInt64). ConvertInt expects you not to assume the type (int, int64, bool, actually there is not ConvertBool), it just garantees you get *some* integer value matching the expected margins of an 'int' which implies the usage of a data type as well. so i still dont quite see a problem in returning an int after error check.
since ConvertInt is used quite often (anytime scanning a String), it always generates a long in python, printing it results in '123L'.. i.e if one sets up an EditInt and expects in python to have an integer and not a long. which is not a problem, python deals with it just fine, but it's not clean. though python does the conversions as well as upp, it's still aware of the type differences
http://docs.python.org/reference/datamodel.html#the-standard -type-hierarchy
i'd really vote for doing it as in python
| Quote: |
Plain integers
These represent numbers in the range -2147483648 through 2147483647. (The range may be larger on machines with a larger natural word size, but not smaller.) When the result of an operation would fall outside this range, the result is normally returned as a long integer
|
so a ConvertInt would return the smallest representation possible *after* checking margins.
BTW: have you already checked out the BoostPyTest?
[Updated on: Tue, 17 May 2011 11:10] Report message to a moderator |
|
|
|
|
|
|
|
|
|
| Re: FIX: UPP::Scan returns int64 for INT_V [message #32467 is a reply to message #32460] |
Thu, 19 May 2011 09:35 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
you're right as usual
the int64 return needs to be addressed as well.
in this case i'd vote for separating the ConvertInt::Scan and ConvertInt64::Scan, so they both deal respectively with their proper minval maxval, so we have the INT_MAX/INT_MIN issue only in constructors. i think that's be more clean...
so i'd be
Value ConvertInt::Scan() { /***/ return int(v); }
Value ConvertInt64::Scan() { /***/ return v; }
i also thought of swapping derive order, to have ConvertInt->ConvertInt64. this would make possible to have a short ConvertInt::Scan like
Value ConvertInt::Scan()
{
Value v = ConvertInt64::Scan();
if(!IsErrorValue(v)) return int(m);
return v;
}
maybe that's an even cleaner option..
BTW: ConvertInt64 daysichain stuff returns ConvertInt& instead ConvertInt64&
[Updated on: Thu, 19 May 2011 09:36] Report message to a moderator |
|
|
|
Goto Forum:
Current Time: Fri Apr 19 12:38:15 CEST 2024
Total time taken to generate the page: 0.03499 seconds
|
|
|
Members
Pages
Help
Register
Login
Home
