Re: [fpc-pascal] Warning not to use the "String" type with FPC 3.x

On 05/09/2016 11:57 AM, Graeme Geldenhuys wrote: the usage of the aliased "String" type should not be used any more with FPC 3.x. You can't seriously suggest to dump all code that ever had been written in Pascal (Delphi Dialect). -Michael ___ fpc-

Re: [fpc-pascal] The world is ending (was: Warning not to use the "String" type with FPC 3.x)

2016-05-09 16:34 GMT-03:00 Jonas Maebe : > Graeme Geldenhuys wrote: > >> Now some would say, simply switch your compiler mode to DelphiUnicode. >> But I don't want to do that, because I like the stricter ObjFPC mode, >> and prefer ObjFPC's syntax. >> > > While still missing in the documentation, y

Re: [fpc-pascal] The world is ending

On 2016-05-09 22:48, Sven Barth wrote: >> > Very good to know. Is that in FPC 3.0.x too, or only FPC Trunk? > It's also in 3.0.0. In fact it's one of the two modeswitches that has mode Excellent. That should also fix another issue with FPC 3.x in tiOPF's D2009+ branch. function SomeName(const A

Re: [fpc-pascal] The world is ending

Am 09.05.2016 23:38 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > On 2016-05-09 20:34, Jonas Maebe wrote: > > While still missing in the documentation, you can already do that with > > {$modeswitch unicodestrings}. > > > Very good to know. Is that in FPC 3.0.x too, or only FPC T

Re: [fpc-pascal] The world is ending

On 2016-05-09 20:34, Jonas Maebe wrote: > While still missing in the documentation, you can already do that with > {$modeswitch unicodestrings}. Very good to know. Is that in FPC 3.0.x too, or only FPC Trunk? Regards, Graeme ___ fpc-pascal maillis

Re: [fpc-pascal] The world is ending

On 2016-05-09 21:14, Tomas Hajny wrote: > about possible data loss isn't cause by the > compiler but rather by the user who sets his environment to use a > character set which can only process a limited subset of all possible > characters while he intends to use a bigger set. My issue is with Stri

Re: [fpc-pascal] Smart Pointers

On 09.05.2016 22:11, Florian Klämpfl wrote: > Am 09.05.2016 um 21:40 schrieb Maciej Izak: >> 2016-05-09 19:50 GMT+02:00 Mazo Winst > >: >> >> I read that mails about implementation of management operators and smart >> pointers. >> >> 1 - These features are expe

Re: [fpc-pascal] The world is ending (was: Warning not to use the "String" type with FPC 3.x)

On Mon, May 9, 2016 21:34, Jonas Maebe wrote: > Graeme Geldenhuys wrote: Hello Graeme, >> Now some would say, simply switch your compiler mode to DelphiUnicode. >> But I don't want to do that, because I like the stricter ObjFPC mode, >> and prefer ObjFPC's syntax. > > While still missing in the

Re: [fpc-pascal] Smart Pointers

Am 09.05.2016 um 21:40 schrieb Maciej Izak: > 2016-05-09 19:50 GMT+02:00 Mazo Winst >: > > I read that mails about implementation of management operators and smart > pointers. > > 1 - These features are expected to be available in which version? > > > The

Re: [fpc-pascal] The world is ending (was: Warning not to use the "String" type with FPC 3.x)

Graeme Geldenhuys wrote: Now some would say, simply switch your compiler mode to DelphiUnicode. But I don't want to do that, because I like the stricter ObjFPC mode, and prefer ObjFPC's syntax. While still missing in the documentation, you can already do that with {$modeswitch unicodestrings}.

Re: [fpc-pascal] Smart Pointers

2016-05-09 19:50 GMT+02:00 Mazo Winst : > I read that mails about implementation of management operators and smart > pointers. > > 1 - These features are expected to be available in which version? > The feature is ready and works almost perfectly but I need more time to tests. It brings also null

Re: [fpc-pascal] Warning not to use the "String" type with FPC 3.x

Graeme Geldenhuys wrote: On 2016-05-09 17:40, Mark Morgan Lloyd wrote:> What, /exactly/, are you saying can be lost, and under what circumstances? You loose “data” due to codepage based AnsiString (aka the String type)not always supporting all code points of UTF8String or UnicodeString data. eg

Re: [fpc-pascal] Warning not to use the "String" type with FPC 3.x

On 2016-05-09 17:40, Mark Morgan Lloyd wrote: > What, /exactly/, are you saying can be lost, and under what circumstances? You loose “data” due to codepage based AnsiString (aka the String type) not always supporting all code points of UTF8String or UnicodeString data. eg: I write a program tha

Re: [fpc-pascal] Smart Pointers

Am 09.05.2016 19:50 schrieb "Mazo Winst" : > > Hello list, > > I don't know if here is the correct place to make this question. > > I read that mails about implementation of management operators and smart pointers. > > 1 - These features are expected to be available in which version? They are curr

Re: [fpc-pascal] Invoking methods through rtti

Am 09.05.2016 18:19 schrieb "Mazo Winst" : > > > > Em segunda-feira, 9 de maio de 2016, Sven Barth < pascaldra...@googlemail.com> escreveu: > > Am 09.05.2016 17:23 schrieb "Mazo Winst" : > >> > >> Is there any way to invoke a method passing parameters through rtti? > > > > As long as you know the s

[fpc-pascal] Smart Pointers

Hello list, I don't know if here is the correct place to make this question. I read that mails about implementation of management operators and smart pointers. 1 - These features are expected to be available in which version? 2 - Are these features an introduction to Arc objects? Best regards

Re: [fpc-pascal] Invoking methods through rtti

Em segunda-feira, 9 de maio de 2016, Graeme Geldenhuys < mailingli...@geldenhuys.co.uk> escreveu: > On 2016-05-09 16:22, Mazo Winst wrote: >> Is there any way to invoke a method passing parameters through rtti? > > Yes, it should be possible. Take a look at the FPCUnit (unit testing > framework) in

Re: [fpc-pascal] Warning not to use the "String" type with FPC 3.x

Graeme Geldenhuys wrote: I really think the FPC team should make it blatantly clear that the usage of the aliased "String" type should not be used any more with FPC 3.x. It turn I think major alarm bells should start ringing when AnsiString type is used too. Both are fraught with dangers of lo

Re: [fpc-pascal] Warning not to use the "String" type with FPC 3.x

On Mon, May 9, 2016 17:49, Graeme Geldenhuys wrote: > On 2016-05-09 16:34, Sven Barth wrote: >> MS-DOS and Win16 where memory restrictions are much more likely to >> arise. > > Fair enough. Then use UTF-8 (instead of UTF-16) as the default (or only) > encoding for the RTL. UTF-8 memory usage is on-

Re: [fpc-pascal] Invoking methods through rtti

Em segunda-feira, 9 de maio de 2016, Sven Barth escreveu: > Am 09.05.2016 17:23 schrieb "Mazo Winst" : >> >> Is there any way to invoke a method passing parameters through rtti? > > As long as you know the signature of the method you can cast the pointer to the method to an approbiate method varia

Re: [fpc-pascal] Warning not to use the "String" type with FPC 3.x

On 2016-05-09 16:34, Sven Barth wrote: > MS-DOS and Win16 where memory restrictions are much more likely to arise. Fair enough. Then use UTF-8 (instead of UTF-16) as the default (or only) encoding for the RTL. UTF-8 memory usage is on-par with AnsiString (FPC 2.6.4 and earlier) for MS-DOS and Win1

Re: [fpc-pascal] Invoking methods through rtti

Am 09.05.2016 17:23 schrieb "Mazo Winst" : > > Is there any way to invoke a method passing parameters through rtti? As long as you know the signature of the method you can cast the pointer to the method to an approbiate method variable and call that. For dynamic calls you'll need to wait for Invok

Re: [fpc-pascal] Warning not to use the "String" type with FPC 3.x

Am 09.05.2016 13:11 schrieb "Graeme Geldenhuys" < mailingli...@geldenhuys.co.uk>: > > On 2016-05-09 11:47, Jonas Maebe wrote: > > Having opinions available is not the issue. Getting people to completely > > implement all of their opinions so that we can compare all options in > > practice, > > And

Re: [fpc-pascal] Invoking methods through rtti

On 2016-05-09 16:22, Mazo Winst wrote: > Is there any way to invoke a method passing parameters through rtti? Yes, it should be possible. Take a look at the FPCUnit (unit testing framework) included with FPC. The testing framework invokes methods and passes parameters around. Regards, Graeme _

[fpc-pascal] Invoking methods through rtti

Is there any way to invoke a method passing parameters through rtti? Best regards ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Warning not to use the "String" type with FPC 3.x

Graeme Geldenhuys wrote on Mon, 09 May 2016: I unit tested the StrUtils.pp unit. It is part of the RTL, but seems not to live inside the “rtl” directory, but rather the “packages/rtl-objpas/” directory. So I presume it is okay to use FPCUnit then. Yes, that should be fine. Jonas ___

Re: [fpc-pascal] Warning not to use the "String" type with FPC 3.x

On 2016-05-09 14:16, Jonas Maebe wrote: > If these are tests for non-core units (basically nothing that's in the > RTL directory), that's fine. RTL tests should not depend on FPCUnit, I unit tested the StrUtils.pp unit. It is part of the RTL, but seems not to live inside the “rtl” directory, b

Re: [fpc-pascal] Warning not to use the "String" type with FPC 3.x

Graeme Geldenhuys wrote on Mon, 09 May 2016: On 2016-05-09 13:11, Jonas Maebe wrote: tests/test/units/unitname What I've created are FPCUnit based unit tests. Looking a bit further, what I'm looking for seems to be in tests/test/units/fpcunit/ If these are tests for non-core units (basica

Re: [fpc-pascal] Warning not to use the "String" type with FPC 3.x

On 2016-05-09 13:11, Jonas Maebe wrote: > > tests/test/units/unitname What I've created are FPCUnit based unit tests. Looking a bit further, what I'm looking for seems to be in tests/test/units/fpcunit/ Thanks again. Regards, Graeme ___ fpc-pascal

Re: [fpc-pascal] Warning not to use the "String" type with FPC 3.x

Graeme Geldenhuys wrote on Mon, 09 May 2016: I already have some UnicodeString RTL updates while I worked on the tiOPF code. I want to submit those to Mantis, but where does RTL unit tests go (not compiler syntax tests, but RTL)? All my changes have accompanied unit tests. As far as I understan

Re: [fpc-pascal] Warning not to use the "String" type with FPC 3.x

On 2016-05-09 12:40, Tomas Hajny wrote: > If such implementations are created, you can always decide if > string/ansistring interfaces should continue to exist Exactly what I've done. I've created UnicodeString only versions. I don't see the point of the others. Regards, Graeme -- fpGUI Toolk

Re: [fpc-pascal] Warning not to use the "String" type with FPC 3.x

On 2016-05-09 11:47, Jonas Maebe wrote: > Getting people to completely > implement all of their opinions so that we can compare all options in > practice, with the chance that most of those people's work will be I already have some UnicodeString RTL updates while I worked on the tiOPF code. I w

Re: [fpc-pascal] {$H+} meaning with compiler {$mode DELPHIUNICODE}

Graeme Geldenhuys wrote on Mon, 09 May 2016: The other problem being? How can we contribute to bringing the Unicode Enabled RTL up to par with Delphi, when the FPC team can't decide on what the RTL must be or look like? See Tomas' mail for a start. When can we expect a decision from the dev

Re: [fpc-pascal] Warning not to use the "String" type with FPC 3.x

On Mon, May 9, 2016 13:10, Graeme Geldenhuys wrote: > On 2016-05-09 11:47, Jonas Maebe wrote: Hello Graeme, >> Having opinions available is not the issue. Getting people to completely >> implement all of their opinions so that we can compare all options in >> practice, > > And we all know that w

Re: [fpc-pascal] {$H+} meaning with compiler {$mode DELPHIUNICODE}

On 2016-05-09 11:42, Jonas Maebe wrote: > > Lots, such as unicodestring versions of all standard classes. OK, thanks. So FPC 3.0.0 is really just an interim / preview Unicode FPC (think KDE 4.0 release situation). The other problem being? How can we contribute to bringing the Unicode Enabled RTL

Re: [fpc-pascal] Warning not to use the "String" type with FPC 3.x

On 2016-05-09 11:47, Jonas Maebe wrote: > Having opinions available is not the issue. Getting people to completely > implement all of their opinions so that we can compare all options in > practice, And we all know that will never happen in FPC. Neither does it happen [implementing every possibl

Re: [fpc-pascal] Warning not to use the "String" type with FPC 3.x

Graeme Geldenhuys wrote: On 2016-05-09 11:28, Jonas Maebe wrote: so the programmer is completely helpless in preventing this. Unlike in previous FPC versions, in FPC 3.x the programmer can specify the encoding that ansistring should use at run time via the SetMultiByteConversionCodePa

Re: [fpc-pascal] {$H+} meaning with compiler {$mode DELPHIUNICODE}

Graeme Geldenhuys wrote: This weekend I tried to unify tiOPF's Delphi and FPC code. Year back tiOPF branched to support D2009 only and do loads of code clean-up. FPC couldn't follow that branch due to all Delphi's many RTL changes and UnicodeString support. I'm now trying to see what is still mi

Re: [fpc-pascal] Warning not to use the "String" type with FPC 3.x

On 2016-05-09 11:28, Jonas Maebe wrote: >> > so the programmer is completely helpless in preventing >> > this. > Unlike in previous FPC versions, in FPC 3.x the programmer can specify > the encoding that ansistring should use at run time via the > SetMultiByteConversionCodePage(). > Tru

Re: [fpc-pascal] Warning not to use the "String" type with FPC 3.x

Graeme Geldenhuys wrote: My reasoning for the above. Data loss during string conversions! 1. The "String" type has too many meanings. I recommend you simply stop using it in your code. Instead, use the exact type you really mean or support in your application. The same is true in previ

[fpc-pascal] Warning not to use the "String" type with FPC 3.x

Hi, I really think the FPC team should make it blatantly clear that the usage of the aliased "String" type should not be used any more with FPC 3.x. It turn I think major alarm bells should start ringing when AnsiString type is used too. Both are fraught with dangers of loosing data. I've long g

[fpc-pascal] {$H+} meaning with compiler {$mode DELPHIUNICODE}

Hi, This weekend I tried to unify tiOPF's Delphi and FPC code. Year back tiOPF branched to support D2009 only and do loads of code clean-up. FPC couldn't follow that branch due to all Delphi's many RTL changes and UnicodeString support. I'm now trying to see what is still missing in FPC 3.x Norma