Forum > FPC development

FPC 3.0 changes

(1/3) > >>

Ocye:
I'm compiling my program for the first time with 3.0.0rc1. And found a few conspicuity:

*File*UTF8()-functions should be used from LazFileUtils. Most functions keep their names but DeleteDirectory(string, boolean) is changed to RemoveDirUTF8(string) and FileSize() is replaced by FileSizeUTF8(). However, I didn't found a equivalent to CopyFile() and GetAllFilesMask(). Shouldn't it be expected? Or better: I has to be documented.

I have quite a lot of widestring operations implemented, e.g. val(ws[i+1],x,e); or StrToInt(Copy(ws,1,y-1)), both with ws=widestring. Former UTF8 operations such as UTF8Copy() or UTF8Length() were known to be slow. Does it makes sense to carefully go through all string handling now since fpc itself supports UTF8? In other words would I benefit from using strings instead of widestrings?

I get the warning "Local variable $bar of a managed type is not initialized" with a function Foo(var bar:string). Sounds not correct to me, or am I wrong?

Jonas Maebe:

--- Quote from: Ocye on September 02, 2015, 02:15:08 pm ---I get the warning "Local variable $bar of a managed type is not initialized" with a function Foo(var bar:string). Sounds not correct to me, or am I wrong?

--- End quote ---
It's a hint, not a warning. "var" means "the called routine can read and/or write the variable". The hint refers to the fact that you yourself did not assign a value to the variable before it may be read. This could be a bug in the logic if your program. It is orthogonal to implementation details such as the fact that managed variables need compiler initialisation because otherwise the program will just crash.

It's a hint instead of a warning because it is unlikely to be an actual bug in your program, so you can turn it off separately.

JuhaManninen:

--- Quote from: Ocye on September 02, 2015, 02:15:08 pm ---I'm compiling my program for the first time with 3.0.0rc1. And found a few conspicuity:

*File*UTF8()-functions should be used from LazFileUtils. ...

--- End quote ---

*File*UTF8()-functions were needed in LCL applications also earlier, before FPC 3.0.
LCL has used AnsiString + dedicated UTF8() functions for its Unicode support until now.
If you did not use those functions, your application did not support Unicode.

Good news for you! You can continue using the functions without "UTF8" prefix/suffix by using this :
  http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus
It changes FPC's default string encoding to UTF-8 and all string- and file-functions work correctly.
We are expecting more issues related to WinAPI W-functions and reading/writing files and streams with different encodings. Please report your findings here or in the "Open issues" section in the wiki page.

This "Better Unicode" solution is still not Delphi compatible but is much closer to it than the current solution with dedicated functions.

marcov:
If you don't mess up the default encoding, and store utf8 strings code only  in utf8string, it should also be ok.

Ocye:

--- Quote from: Jonas Maebe on September 02, 2015, 02:21:50 pm ---"var" means "the called routine can read and/or write the variable". The hint refers to the fact that you yourself did not assign a value to the variable before it may be read.
--- End quote ---
I was just surprised. 'Var' parameters are standard in Pascal and these hints spam a little bit. BTW, 'out' doesn't give a hint.


--- Quote from: JuhaManninen on September 02, 2015, 03:44:10 pm ---You can continue using the functions without "UTF8" prefix/suffix...
--- End quote ---
Ah yes, that should work as well. Is it recommended to use the FPC functions rather than the LCL versions (targeting all desktop platforms)? And what's about the missing functions like CopyFile()?

Navigation

[0] Message Index

[#] Next page

Go to full version