Forum > General

TryStrToInt declaration question

(1/5) > >>

lagprogramming:
Hi!
Regarding the "TryStrTo..." functions, we have a single function name to convert strings to single, double or extended, it's TryStrToFloat. Not all CPUs support extended, double, some not even single.
Why do we have TryStrToInt for 32bit variables, TryStrToInt64 for 64bit signed variables and TryStrToQWord for 64bit unsigned variables?
I found this situation when I realized that calling TryStrToInt with a sizeuint parameter may lead to errors when I target x86_64.
I've looked at rtl documentation and I've seen:
Declaration: function TryStrToInt(const s: string; out i: LongInt) : Boolean
Declaration: function TryStrToInt64(const s: string; out i: Int64) : Boolean
Declaration: function TryStrToQWord(const s: string; out Q: QWord) : Boolean
How comes that for 32bit we have a single function(TryStrToInt) with a longint parameter, but for 64bit we have a function for signed integers(TryStrToInt64) and a different function for unsigned integers(TryStrToQWord)?
Thank you!

ASerge:
For historical reasons.
The Int64 type was first introduced in Delphi4. And at the same time, the StrToInt64 function was added in addition to the existing StrToInt. Since overlapping functions (introduce in Delphi4 also) do not differ in the type of results, the names were chosen of course different. It is also worth noting that for 32-bit Intel processors, 32-bit integers and 10-bit floating-point numbers (extended) were native. Therefore, the functions StrToInt: Integer and StrToFloat:Extended were native, but StrToInt64: Int64 is optional. In later versions Delphi, TryStrTo... functions were added. With the preservation of names, of course.
The StrToQWord function was added in FPC because the QWord type did not fit into Int64. A similar StrToUInt64 function was also added, but later, in Delphi.

ASerge:
Of course, if you don't like a lot of names, you can overload the functions:

--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---{$MODE OBJFPC}{$LONGSTRINGS ON} uses SysUtils; function TryStrToInt(const S: string; out Value: Int64): Boolean; inline; overload;begin  Result := SysUtils.TryStrToInt64(S, Value);end; function TryStrToInt(const S: string; out Value: QWord): Boolean; inline; overload;begin  Result := SysUtils.TryStrToQWord(S, Value);end; var  I32: Int32;  I64: Int64;  Q: QWord;begin  TryStrToInt('1', I32); // Call SysUtils.TryStrToInt  TryStrToInt('1', I64); // Call SysUtils.TryStrToInt64  TryStrToInt('1', Q); // Call SysUtils.TryStrToQWordend.

lagprogramming:
   Let's assume that a developer has a code like this:

--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---function foo(StringVariable:string; var Number:integer):boolean;var  IntegerVariable: integer;begin  {Pascal code}  if TryStrToInt(StringVariable,IntegerVariable) then...  {Additional pascal code}  Number:=IntegerVariable;end;
   In order to make the above code work nicely and native with 64bit CPUs it's not enough to change the integer types to sizeint.
   According to the slogan "Write once, compile anywhere", if the code in written in a 32bit environment(which means sizeint would have the same size as integer) each and every developer has to realize that TryStrToInt won't work as they expect when the code is compiled in a 64bit environment. Those developers needs some luck to realize that. If the developers realize that their code has a problem in using this function, they must come with a workaround. One workaround is the one presented by ASerge, other approaches might be using conditional compilation syntax like {$IF....} or using the Val routine directly. The approach involving workarounds is far from being crosscompile friendly.

   Wouldn't be better to avoid pushing each and every developer to write workarounds in their code by making TryStrToInt also accept 64bit integers and then modify existing code in TryStrToInt64 and TryStrToQWord to make it call TryStrToInt? With this approach we would have a clean way of using TryStrToInt routine similar to TryStrToFloat while keeping existing written pascal code compatible, for historical reasons.

Seenkao:
разработчикам в любом случае надо будет приводить тип данных к компилируемой архитектуре. Понятно дело, это не надо будет делать пользователю. Но вот подгонка типов данных под компилируемую архитектуру... этот не очень благодарное дело.

google translate:
developers in any case will need to cast the data type to the compiled architecture. Clearly, the user does not need to do this. But here's the adjustment of data types to the compiled architecture ... this is not a very rewarding job.

Navigation

[0] Message Index

[#] Next page

Go to full version