Converting integer to binary - how it's done on Android ( vs Windows) - XE5

Question

So, yesterday I opened up a question about converting integer to binary, which was a little unclear to me, about how it works (with the shifting operations). Now, I have another question here to disguss: How it's done on android, why it results differently than doing it on windows, and how to get the actual binary result rather than what I get now (and about this one I'm not yet clear what it is; it's somehow hex with a wrong value).

I have this code in a firemonkey mobile project, which has both, android and windows platforms set as targets. This way the code testing can be done by targeting windows, so that it compiles faster, and previews as virtual mobile form; Well, at least the intention is to do this, but looks like it's not so reliable source of errors...

While the same project ran on Win32 worked just fine, running it on android results in not getting binary result out of a function.

I use this code to make conversions:

function IntToBin(Value: Integer): string;
var
  i: Integer;
begin
  SetLength(Result, 9);
  for i := 1 to 9 do begin
    if (Value shr (9-i)) and 1 = 0 then begin
      Result[i] := '0'
    end else begin
      Result[i] := '1';
    end;
  end;
end;

The debugger shows this, when trying to convert value '1':

Result: 0x6d09d738
   *Result: #0'00000000'                      [expanded from Result]
Value: 1

Now, I know that the reason I'm then (after the main procedure, which calls this conversion function is completed) getting exactly the half value of what it should be (1 instead of 3, 2 instead of 4, 8 isntead of 16, 6 instead of 12...) is because in *Result there is clear that it's only 8 bit, when I need 9 bit result (I'm doing conversions from Integer (1..512) to binary...), and therefore insead of reading 2 as 0010, I get 001, which is 1, instead of 6 (0110) I get 3 (011), 8 (1000) I get 4 (100) etc....

Now I really want to know why, at first, it even throws result as 0x6d09d738 / 0x6d09d738 instead of just binary, and why is it not 9bit, as I set the length of a result string?

Also, here's another interesting and for me ununderstandable thing:

This is my procedure which triggers coversion:

procedure TForm1.CalculateAddress1;
var SetDip: string;
    C: integer;
begin
  SetDip := IntToBin(StrToInt(MergeAddr));
  //Text1.Text:=SetDip;
  for C := 1 to 9 do
    begin
      if Copy(SetDip, b, 1) = '1' then
      DipSW[10-b].IsChecked:=True
      else DipSW[10-b].IsChecked:=False;
    end;
end;

// (I use this to convert dmx address into dip switch configuration...)

The SetDip gets something of a value like #0'00000000'. (it differs; this is the case when integer that was converted is 1; for 11 I get #0'00000101' );

This results as having the exact half value as it should be (as I mentioned above; And I understand why this is happening, since one bit of a result is missing...).

However, if I remove the // from Text1.Text:=SetDip;, which I putted there so I could see the result on the phone screen, I get the next error, on phone only! (again, targeting windows runs ok):

'String index out of range (-1). Must be >= 0 and <= 8';

After that, Segmentation fault is raised, 2 Access violation errors and finally, the app closes itself.

It looks like it can't copy SetDip to Text1.Text field; That's what I thought. But later I found out that this error doesn't occur always, which was weird, since it should, and not just that: it should even when I leave Text1.Text:=SetDip out of code; -> I don't know how it copyes string at index 9, if it's not that long; I know this is exactly the reason it throws the error, but again: why not always?

[[ Ps: +, found out that Firemonkey handles fixed arrays automatically, if the code tries to create entry beyond the defined size. Interesting... :) Maybe this means that it handles the string length and copy indexes by itself too..? ]]

Answer 1

On Android (and other mobile platforms), the first character in a string is indexed with the value 0, whereas on desktop versions, it is indexed with the value 1.

So, you need to change

Result[i] := '0'

with

Result[i-1] := '0'

when compiling for mobile platforms. In order to do this automatically, you can use the following:

{$IFDEF CPUARM }
  Result[i-1] := '0'
{$ELSE }
  Result[i] := '0'
{$ENDIF }

But beware that it is only INDEXING (ie. using the [] syntax) that is different. The Copy, Pos, etc. functions still treat 1 as the first character in a string.

Talk about inconsistency (and a programmer's headache)...

I use the following helper functions:

FUNCTION GetChar(CONST S : STRING ; OneBasedIndex : Cardinal) : CHAR;
  BEGIN
    IF LOW(STRING)=0 THEN Result:=S[PRED(OneBasedIndex)] ELSE Result:=S[OneBasedIndex]
  END;

PROCEDURE SetChar(VAR S : STRING ; OneBasedIndex : Cardinal ; C : CHAR);
  BEGIN
    IF LOW(STRING)=0 THEN S[PRED(OneBasedIndex)]:=C ELSE S[OneBasedIndex]:=C
  END;

to get/set a character, regardless of compilation target. It also has the advantage of being "future proof", since it doesn't use the compiler's {$DEFINE}s, but checks the low index of the STRING type.

Answer 2

Your problems are because on the mobile platform, string indexing is zero based, and by default on desktop platforms it is one based. There are a number of ways to deal with this, and you certainly do not need platform switching ifdefs.

The easiest solution is to use {$ZEROBASEDSTRINGS ON} to make the desktop compiler behave the same way as does the mobile compiler.

When you add this to your code then you will need to get used to zero-based indexing for your strings. You should stop using legacy functions like Pos and instead use the TStringHelper methods.

Your function would be re-written like this:

{$ZEROBASEDSTRINGS ON}
function IntToBin(Value: Integer): string;
var
  i: Integer;
begin
  SetLength(Result, 9);
  for i := 0 to 8 do begin
    if (Value shr (8-i)) and 1 = 0 then begin
      Result[i] := '0'
    end else begin
      Result[i] := '1';
    end;
  end;
end;

The code is, in my view, a little cleaner and avoids branching if written like this:

{$ZEROBASEDSTRINGS ON}
function IntToBin(Value: Integer): string;
var
  i: Integer;
begin
  SetLength(Result, 9);
  for i := 0 to 8 do
    Result[i] := Chr(ord('0') + (Value shr (8-i)) and 1));
end;

The other mooted change to strings, which has not yet happened, is to make them immutable. That change would make the string indexing operator read-only. That change might never happen. If it did then I would probably re-write the code as follows:

function IntToBin(Value: Integer): string;
var
  i: Integer;
  buff: array [0..8] of Char;
begin
  for i := 0 to 8 do
    buff[i] := Chr(ord('0') + (Value shr (8-i)) and 1));
  SetString(Result, PChar(@Buffer), Length(buff));
end;

You should certainly have a read of the documentation on this subject: http://docwiki.embarcadero.com/RADStudio/en/Migrating_Delphi_Code_to_Mobile_from_Desktop

The other thing that you simply must do, at the very least for debug builds, is to enable range checking. Had that been enabled, the compiler would have written out code that would have revealed your error immediately. It is best to control this feature globally through the project configuration.

Answer 3

Here is a solution that is not depending on which index the strings starts with (i.e. platform independent):

function IntToBin(Value: Integer): String; 
var 
  i: Integer; 
  pStr: PChar; 
begin 
  SetLength( Result,9); 
  pStr := PChar(Pointer(Result));  // Get a pointer to the string
  for i := 8 downto 0 do begin 
    pStr[i] := Char(Ord('0') + ((Value shr (8 - i)) and 1)); 
  end; 
end;