Op 2011-02-14 14:15, Felipe Monteiro de Carvalho het geskryf: > > Maybe I used a bad example, but anyway, var parameters need to be exact
"alias types" are not really new types, so will not affect var parameters. So in my previous example, UTF16String will still be a UnicodeString. The only difference will be that UTF16String has its internal encoding bit set to UTF-16. Here is a test program using latest FPC 2.4.3 showing that TMyString = String - the compiler sees no difference between the two types. So the same should be valid for UnicodeString vs UnicodeString(...) that have their encoding bit set to something other than the platform default. ---8<-----------8<-----------8<-----------8<-----------8<----------- program project1; {$mode objfpc}{$H+} uses Classes type TMyText = String; procedure TestMe(var AText: string); begin writeln(AText); AText := 'Hello ' + AText; end; var s: TMyText; begin s := 'Graeme'; TestMe(s); writeln(s); end. ---8<-----------8<-----------8<-----------8<-----------8<----------- >> So for every possible encoding and code page you want to make a new >> function? > > Of course not! Only the important ones. For me this means only UTF-8, > but I supposed some people might want UTF-16 too. Again I don't see why that is needed. You might only require UTF-8, but somebody else wants UTF-16, and somebody else wants CP850 versions etc etc.. Where does it end? A simple function like: function CompareText(const S1: UnicodeString; const S2: UnicodeString): integer; should be able to work with any UnicodeString parameters (including alias types that have different encoding bits set). So it should work fine for your UTF-8 text, and somebody else's UTF-16 etc. text. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus