Re: [fpc-devel] Feature announcement: Record management operators

2016-03-07 15:52 GMT+01:00 tha...@thaddy.com : > You mean really,really,smart pointers and the introduction of the comma > into the language? > By comma did you mean comma "," ? I mean really really really smart pointers ;) without comma "," operator: http://lists.freepascal.org/pipermail/fpc-d

Re: [fpc-devel] Feature announcement: Record management operators

You mean really,really,smart pointers and the introduction of the comma into the language? On 07-Mar-16 3:37 PM, Maciej Izak wrote: 2016-03-07 15:34 GMT+01:00 Kazantsev Alexey >: It's cool! What about Copy or CopyRecord? Work in progress. Will be probabl

Re: [fpc-devel] The (near) future of strings

In our previous episode, Sven Barth said: > > source dir is read-only. If you start building sources multiple times in > one > > run, that is a good way. > > > > That's part of the build system. Yes it is, and that is what I meant. ___ fpc-devel mailli

Re: [fpc-devel] The (near) future of strings

Am 07.03.2016 20:30 schrieb "Marco van de Voort" : > > >> > > >> Dotted, unicode > > >> not dotted, unicode. > > >> > > >> which is clear nonsense. > > > > > > No, two rtls, both dotted, with namespace if needed. Which is the same as > > > what you propose, just kept physically apart. > > > > If th

Re: [fpc-devel] The (near) future of strings

Am 07.03.2016 19:16 schrieb "Michael Van Canneyt" : > > > > On Mon, 7 Mar 2016, Marco van de Voort wrote: > >> In our previous episode, Michael Van Canneyt said: However in Michael's scheme with Sysutils using Ansi and System.Sysutils using unicodestring this will fail. >>> >>>

Re: [fpc-devel] The (near) future of strings

On Mon, 7 Mar 2016, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: /usr/local/lib/fpc/4.0.0/x86_64-linux/dotted/XYZ But only one is referenced in fpc.cfg : #IFDEF NAMESPACED /usr/local/lib/fpc/4.0.0/x86_64-linux/dotted/XYZ #ELSE /usr/local/lib/fpc/4.0.0/x86_64-

Re: [fpc-devel] The (near) future of strings

In our previous episode, Michael Van Canneyt said: > /usr/local/lib/fpc/4.0.0/x86_64-linux/dotted/XYZ > > But only one is referenced in fpc.cfg : > > #IFDEF NAMESPACED > /usr/local/lib/fpc/4.0.0/x86_64-linux/dotted/XYZ > #ELSE > /usr/local/lib/fpc/4.0.0/x86_64-linux/XYZ > #ENDIF > > where the -N

Re: [fpc-devel] The (near) future of strings

On Mon, 7 Mar 2016, Florian Klämpfl wrote: I hope somebody implements this in fpmake :) My "subarch" directory approach needed by several targets is already on hold for years as I do not owe to touch fpmake regarding this. I don't understand why ? Why would you not touch fpmake for this ?

Re: [fpc-devel] The (near) future of strings

Am 07.03.2016 um 19:16 schrieb Michael Van Canneyt: > > > On Mon, 7 Mar 2016, Marco van de Voort wrote: > >> In our previous episode, Michael Van Canneyt said: However in Michael's scheme with Sysutils using Ansi and System.Sysutils using unicodestring this will fail. >>> >>> Why

Re: [fpc-devel] The (near) future of strings

On Mon, 7 Mar 2016, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: However in Michael's scheme with Sysutils using Ansi and System.Sysutils using unicodestring this will fail. Why would this fail ? All we need to do is introduce -NS ? If you have a mix of ge

Re: [fpc-devel] Feature announcement: Record management operators

On Mon, 7 Mar 2016, Maciej Izak wrote: 07.03.2016 15:50 "Jonas Maebe" : The syntax with the separate "var aFoo: TFoo" parameter, but then seemingly using that parameter as some kind of automatic alias for a fake "self" in the body, is also rather strange (why don't you have to use "aFoo.F :=

Re: [fpc-devel] The (near) future of strings

In our previous episode, Michael Van Canneyt said: > > > > However in Michael's scheme with Sysutils using Ansi and System.Sysutils > > using unicodestring this will fail. > > Why would this fail ? All we need to do is introduce -NS ? If you have a mix of generations (as is currently possible wit

Re: [fpc-devel] Feature announcement: Record management operators

07.03.2016 15:50 "Jonas Maebe" : > The syntax with the separate "var aFoo: TFoo" parameter, but then seemingly using that parameter as some kind of automatic alias for a fake "self" in the body, is also rather strange (why don't you have to use "aFoo.F := 10" etc?) My mistake in example. I misunde

Re: [fpc-devel] Feature announcement: Record management operators

2016-03-07 17:12 GMT+01:00 Sven Barth : > Might be, but even then you can commit that separately. > > Might be ;) > Jonas meant that you didn't use "aFoo" inside the body of the > Initialize/Finalize operators. Is that a copy and paste oversight or does > that really work? In the latter case: tha

Re: [fpc-devel] Feature announcement: Record management operators

Am 07.03.2016 16:00 schrieb "Maciej Izak" : > > 2016-03-07 15:50 GMT+01:00 Jonas Maebe : >> >> Congratulations! However, in the future please try to split your commits more. For example, it seems the optimisation regarding the RTTI for initialisation could have been committed (and hence tested and

Re: [fpc-devel] The (near) future of strings

Am 07.03.2016 15:00 schrieb "Marco van de Voort" : > > In our previous episode, Michael Van Canneyt said: > > 2. Provide Delphi-compatible dotted units, with string = widestring. > > > > Basically, the user has then 2 choices: > > 1. is the pre-delphi 2009 option, > > 2. is the Delphi 2009 and high

Re: [fpc-devel] Feature announcement: Record management operators

On Mon, 7 Mar 2016, Maciej Izak wrote: 2016-03-07 15:50 GMT+01:00 Jonas Maebe : Congratulations! However, in the future please try to split your commits more. For example, it seems the optimisation regarding the RTTI for initialisation could have been committed (and hence tested and potentia

Re: [fpc-devel] The (near) future of strings

On Mon, 7 Mar 2016, Marco van de Voort wrote: DXE2+ also allow to introduce the scopeprefix so that you don't need to use dotted units (iow if you uses sysutils, then System.sysutils.dcu is found etc). So I use @dcc32 "-NSSystem;System.Win;WinAPI;Vcl;Vcl.Imaging;Data;VclTee" %1 %2 %3 %4 %5

Re: [fpc-devel] Feature announcement: Record management operators

Michael Van Canneyt wrote on Mon, 07 Mar 2016: On Mon, 7 Mar 2016, Jonas Maebe wrote: The syntax with the separate "var aFoo: TFoo" parameter, but then seemingly using that parameter as some kind of automatic alias for a fake "self" in the body, is also rather strange (why don't you have

Re: [fpc-devel] Feature announcement: Record management operators

2016-03-07 15:50 GMT+01:00 Jonas Maebe : > Congratulations! However, in the future please try to split your commits > more. For example, it seems the optimisation regarding the RTTI for > initialisation could have been committed (and hence tested and potentially > merged) separately from the rest.

Re: [fpc-devel] Feature announcement: Record management operators

On Mon, 7 Mar 2016, Jonas Maebe wrote: Maciej Izak wrote on Mon, 07 Mar 2016: I'm pleased to finally announce the additional record operators: Initialize, Finalize. Congratulations! However, in the future please try to split your commits more. For example, it seems the optimisation regar

Re: [fpc-devel] Feature announcement: Record management operators

Maciej Izak wrote on Mon, 07 Mar 2016: I'm pleased to finally announce the additional record operators: Initialize, Finalize. Congratulations! However, in the future please try to split your commits more. For example, it seems the optimisation regarding the RTTI for initialisation could h

Re: [fpc-devel] The (near) future of strings

In our previous episode, Mattias Gaertner said: > >[...] > > > Do you mean the dotted unitname will not be needed when the compiler > > > is extended to support namespace prefixes (project and command line > > > switch)? > > > > I assume not since that would be Delphi incompatible. Under delphi th

Re: [fpc-devel] Feature announcement: Record management operators

2016-03-07 15:34 GMT+01:00 Kazantsev Alexey : > > It's cool! What about Copy or CopyRecord? Work in progress. Will be probably released together with smart pointers. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.o

Re: [fpc-devel] Feature announcement: Record management operators

2016-03-07 15:30 GMT+01:00 Michael Van Canneyt : > > What is the need for the (var aFoo: TFoo); ? > There is no hidden "self" parameter for class operators. And need to be consistent with existing operators. Class operators works like (equivalent method without compiler magic): class procedure I

Re: [fpc-devel] The (near) future of strings

On Mon, 7 Mar 2016 15:23:01 +0100 (CET) mar...@stack.nl (Marco van de Voort) wrote: >[...] > > Do you mean the dotted unitname will not be needed when the compiler > > is extended to support namespace prefixes (project and command line > > switch)? > > I assume not since that would be Delphi inco

Re: [fpc-devel] Feature announcement: Record management operators

On Mon, 07 Mar 2016 18:13:43 +0400, Maciej Izak wrote: I'm pleased to finally announce the additional record operators: Initialize, Finalize. It's cool! What about Copy or CopyRecord? -- Kazantsev Alexey ___ fpc-devel maillist - fpc-devel@lists.

Re: [fpc-devel] Feature announcement: Record management operators

On Mon, 7 Mar 2016, Maciej Izak wrote: Hi, I'm pleased to finally announce the additional record operators: Initialize, Finalize. Download (r33200): http://svn.freepascal.org/svn/fpc/branches/maciej/smart_pointers "Record management operators aka record constructor/destructor" They working

Re: [fpc-devel] The (near) future of strings

In our previous episode, Mattias Gaertner said: > >[...] > > I usually use Delphi XE2+ with namespace prefix, and many with me. IMHO > > requiring to change Delphi sources to dotted units is a nono. > > What do you mean with Delphi sources? The Classes unit or the > user's unit? User code that is

[fpc-devel] Feature announcement: Record management operators

Hi, I'm pleased to finally announce the additional record operators: Initialize, Finalize. Download (r33200): http://svn.freepascal.org/svn/fpc/branches/maciej/smart_pointers "Record management operators aka record constructor/destructor" They working like low level auto-executed constructor/de

Re: [fpc-devel] The (near) future of strings

On Mon, 7 Mar 2016 15:00:01 +0100 (CET) mar...@stack.nl (Marco van de Voort) wrote: >[...] > I usually use Delphi XE2+ with namespace prefix, and many with me. IMHO > requiring to change Delphi sources to dotted units is a nono. What do you mean with Delphi sources? The Classes unit or the user's

Re: [fpc-devel] The (near) future of strings

In our previous episode, Michael Van Canneyt said: > > The -Mdelphiunicode is the first step towards Delphi XE compatibility. > > The next step is to provide a compatible UTF-16 UnicodeString RTL/FCL > > and then third party packages like the LCL can be adapted. This would > > be the most compatibl

Re: [fpc-devel] The (near) future of strings

In our previous episode, Michael Van Canneyt said: > 2. Provide Delphi-compatible dotted units, with string = widestring. > > Basically, the user has then 2 choices: > 1. is the pre-delphi 2009 option, > 2. is the Delphi 2009 and higher option > > Both units can be created using a single codebas

Re: [fpc-devel] The (near) future of strings

On Mon, 7 Mar 2016, Mattias Gaertner wrote: On Thu, 03 Mar 2016 06:35:35 + Alfred wrote: [...] In the (near) future, I am still a very happy user of FPC. And mORMot. And sometimes some version of Delphi > XE2. Lets say its 2017. And I am using FPC 3.2.0. Or FPC 4.0. What mode will I be

Re: [fpc-devel] The (near) future of strings

On Mon, 7 Mar 2016, Alfred wrote: I was assuming that a goal (first quote: UTF16) would be accompanied by (some sort of) a roadmap. Opinions are divided, hence there is no roadmap. The main point is what to do with backwards compatibility. Most people do not want to give this up. There i

Re: [fpc-devel] The (near) future of strings

On Thu, 03 Mar 2016 06:35:35 + Alfred wrote: >[...] > In the (near) future, I am still a very happy user of FPC. And mORMot. > And sometimes some version of Delphi > XE2. > Lets say its 2017. And I am using FPC 3.2.0. Or FPC 4.0. > > What mode will I be using when writing programs/framework

[fpc-devel] The (near) future of strings

I was assuming that a goal (first quote: UTF16) would be accompanied by (some sort of) a roadmap. Perhaps I am wrong. But, again, a comment on the remaining quotes would be welcome. And also a comment on the use of {$mode delphiunicode}. ___ fpc-devel

Re: [fpc-devel] The (near) future of strings

On Mon, 7 Mar 2016, Alfred wrote: Mmmm ... not that many answers ... Let me try another question: does the link below correctly state the current use and especially future of FPC / Lazarus ? http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus Especially (quotes): * The goal of FP

[fpc-devel] The (near) future of strings

Mmmm ... not that many answers ... Let me try another question: does the link below correctly state the current use and especially future of FPC / Lazarus ? http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus Especially (quotes): * The goal of FPC project is to create a Delphi compat