UNICODESTRING vs ANSISTRING

[SilverWarior]

The test I did was:

  procedure TForm1.Button1Click (Sender: TObject);
  VAR
    lText: ANSISTRING;
  begin
    INC (fNum);
    lText := 'Test #%d';
    lText := Format (lText, [fNum]);
    Memo1.Lines.Add (lText)
  end;

Compiled with {$H-}, and also changing the "Long strings by default" to false, but it still shows the warning.

Using your example in modern Delphi versions will always show a warning regardless of what string compiler directives you use in your code. Why? That is because the Format function is always returning default Delphi string type which is WideString, And since you are then assigning it to AnsiString you get a warning.

So you either need to create your own version of Format function that will be returning AnsiString result or disable of using of LongString as default string type at Project Options->Building->Delphi Compiler->Compiling (check Syntax options section).
http://docwiki.embarcadero.com/RADSt...o/en/Compiling
Do note that this affects your entire project so if you have other code parts that are built to work with Unicode string they may stop working properly.

[Ñuño Martínez]

Thanks for your comments.

After some working, I've reduced a lot the warnings when compiling. I'm still doing testing and changes trying to reach zero warnings (if possible).

I've also added my own Format function as SilverWarrior suggested and I think I'll add functions to convert from/to numeric values too.

Once done I'll release a new beta version so you can test it. If you're curious you can see what I'm doing here.

[Ñuño Martínez]

Sorry for the double post, but I have to say this: the solution was trivial

While testing I discovered that function StrPas (used internally to force some callings to overloaded functions in my abstraction layer unit) were in a different unit in modern Delphi (AnsisString instead of SysUtils), so I added it to be used only in Delphi. Since then warnings appeared again and I was like WTF Delphi is trolling me... But using the Find declaration command to see the actual declaration of Format I discovered AnsiString also defines it's own version using ANSISTRING instead of UNICODESTRING!

Note it doesn't avoid the need of the abstraction layer unit, but it simplifies a lot the implementation of this unit (and avoids to call an extra function internally in other units). For example:

  USES
  {$IFDEF ISDELPHI2009ANDUP}
  { This unit implements sysutils using ANSISTRING instead of UNICODESTRING,
    which is the default in modern Delphi compilers. }
    AnsiStrings;
  {$ELSE}
    sysutils;
  {$ENDIF}

··· 

  FUNCTION al_str_format (CONST Fmt: AL_STR; CONST Args : ARRAY OF CONST)
    : AL_STR;
  BEGIN
    Format (Fmt, Args)
  END;

This way there's no need of conditional compilation outside Allegro.pas.

So, now we know.

[SilverWarior]

Wait Delphi has a special unit just for dealing with ANSI strings? I must shamefully admit that I didn't knew that

[Ñuño Martínez]

Well, you know now.

Anyway I think they should add an option to tell the compiler to define STRING as ANSISTRING, as FPC does with {$unicodestrings} or something. That would help a lot porting and maintaining code.

[pitfiend]

Mother of Strings!!! it's highly inefficient and error prone to have multiple, obscure and undocumented units to deal with the same task.

[Ñuño Martínez]

If you mean the AnsiStrings unit, I agree. If I were Delphi developer I would overload the functions adding UNICODESTRING, without breaking backwards compatibility.

If you mean my al5strings... well, I didn't found a better solution.