[fpc-devel] Move of mailing lists to another server

Hi, The mailing lists will be moved to another server. As a result, their operation will be temporarily suspended. Normally, they should be back some time tomorrow (CEST). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Object upgrades

> On Jun 10, 2019, at 4:07 PM, Sven Barth via fpc-devel > wrote: > > Of course the dereferentiation of PBase while always have the size of TBase. > That's the point of a pointer. You need to add a static Create method to each > subclass if you want to use that concept. And no kind of

Re: [fpc-devel] Object upgrades

> On Jun 10, 2019, at 4:04 PM, Sven Barth via fpc-devel > wrote: > > Ehm... You are aware that you can simply use TRecord here? > Yes but it’s lots of redundancy. It’s nice to have a type that says “the type of the structure”, the same as what “self” basically means but at the class

Re: [fpc-devel] Object upgrades

Ryan Joseph schrieb am Mo., 10. Juni 2019, 21:31: > > > > On Jun 10, 2019, at 3:25 PM, Ben Grasset wrote: > > > > Result in your example is the size of a pointer in all cases, which is > fine / exactly what you'd expect it to be. > > > > Sorry, if I dereference the size is still of TBase. I

Re: [fpc-devel] Object upgrades

Ryan Joseph schrieb am Mo., 10. Juni 2019, 20:31: > > > > On Jun 10, 2019, at 2:26 PM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > Also FPC doesn’t have something “self” but for the class level so you > need to cast the return value. Btw adding “ClassSelf” is

Re: [fpc-devel] class operator overloads

Ryan Joseph schrieb am Mo., 10. Juni 2019, 20:35: > > > > On Jun 10, 2019, at 2:21 PM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > There exist only two assignment operators, namely "Implicit" (aka := in > mode ObjFPC) and "Explicit" both taking a single argument.

Re: [fpc-devel] Object upgrades

> On Jun 10, 2019, at 3:25 PM, Ben Grasset wrote: > > Result in your example is the size of a pointer in all cases, which is fine / > exactly what you'd expect it to be. > Sorry, if I dereference the size is still of TBase. I don’t think “result" is actually changing depending on the class

Re: [fpc-devel] Object upgrades

On Mon, Jun 10, 2019 at 1:56 PM Ryan Joseph wrote: > I don’t think this is possible. Just did little test and the size of > “result” is always the size of the base class. Does this work? > Result in your example is the size of a *pointer* in all cases, which is fine / exactly what you'd expect

Re: [fpc-devel] class operator overloads

> On Jun 10, 2019, at 2:21 PM, Sven Barth via fpc-devel > wrote: > > There exist only two assignment operators, namely "Implicit" (aka := in mode > ObjFPC) and "Explicit" both taking a single argument. Introducing a binary > operator does not change that the operator is forbidden for

Re: [fpc-devel] Object upgrades

> On Jun 10, 2019, at 2:26 PM, Sven Barth via fpc-devel > wrote: > > Also FPC doesn’t have something “self” but for the class level so you need to > cast the return value. Btw adding “ClassSelf” is something I’ve wanted for a > while, so I can reference the class type within the class

Re: [fpc-devel] Object upgrades

Ryan Joseph schrieb am Mo., 10. Juni 2019, 19:56: > Also FPC doesn’t have something “self” but for the class level so you need > to cast the return value. Btw adding “ClassSelf” is something I’ve wanted > for a while, so I can reference the class type within the class declaration. > What are

Re: [fpc-devel] class operator overloads

Ryan Joseph schrieb am Mo., 10. Juni 2019, 16:26: > > > > On Jun 10, 2019, at 9:31 AM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > The +-operator is not defined internally thus it is allowed to be > overloaded. (is it really that hard to understand? If you can use

Re: [fpc-devel] Object upgrades

On Mon, 10 Jun 2019, Ryan Joseph wrote: On Jun 10, 2019, at 1:20 PM, Michael Van Canneyt wrote: Records do. Objects not. Ooops forget the mode switch. :) I’m seeing objects have properties. Are you sure? Maybe they got added recently. Well, at the time I used objects, they didn't

Re: [fpc-devel] Object upgrades

> On Jun 10, 2019, at 1:19 PM, Michael Van Canneyt > wrote: > > I don't think that for classes this should be allowed. Sven and Florian > already explained the reasons for this in detail. Yes but that was in regards to binary operators which would have memory management issues. The

Re: [fpc-devel] Object upgrades

> On Jun 10, 2019, at 1:20 PM, Michael Van Canneyt > wrote: > > Records do. Objects not. Ooops forget the mode switch. :) I’m seeing objects have properties. Are you sure? Maybe they got added recently. Regards, Ryan Joseph ___ fpc-devel

Re: [fpc-devel] Object upgrades

On Mon, 10 Jun 2019, Ryan Joseph wrote: On Jun 10, 2019, at 11:25 AM, Michael Van Canneyt wrote: (same for properties, BTW) Just noticed this. Yes, why don’t records have properties? Seems like an omission. Records do. Objects not.

Re: [fpc-devel] Object upgrades

On Mon, 10 Jun 2019, Ryan Joseph wrote: On Jun 10, 2019, at 11:25 AM, Michael Van Canneyt wrote: So where do we stand on this? I have a patch to make it possible allow operator overloads that are members of objects but I hear that objects are legacy types. I disagree of course and

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On 10/06/2019 12:57, Luca Olivetti wrote: In fact I see more and more lazarus being confused and I have to restart it frequently just to be able to make it code complete again instead of reporting bogus errors (but that may be just another bug). I think a lot of those cases are caused by

Re: [fpc-devel] Object upgrades

> On Jun 10, 2019, at 11:25 AM, Michael Van Canneyt > wrote: > > (same for properties, BTW) Just noticed this. Yes, why don’t records have properties? Seems like an omission. Regards, Ryan Joseph ___ fpc-devel maillist -

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

El 10/6/19 a les 9:14, Michael Van Canneyt ha escrit: 2. I really want to see more arguments than the worn-out 'increased productivity' before adding another exception to an otherwise easy to understand rule in declaring procedures/functions. Simplicity has its virtues. I think that what

Re: [fpc-devel] Object upgrades

> On Jun 10, 2019, at 11:25 AM, Michael Van Canneyt > wrote: > >> >> So where do we stand on this? I have a patch to make it possible allow >> operator overloads that are members of objects but I hear that objects are >> legacy types. I disagree of course and claim they are the only way to

Re: [fpc-devel] Object upgrades

On Mon, 10 Jun 2019, Ryan Joseph wrote: So where do we stand on this? I have a patch to make it possible allow operator overloads that are members of objects but I hear that objects are legacy types. I disagree of course and claim they are the only way to get inheritance for records since

Re: [fpc-devel] Object upgrades

So where do we stand on this? I have a patch to make it possible allow operator overloads that are members of objects but I hear that objects are legacy types. I disagree of course and claim they are the only way to get inheritance for records since I’m 99% certain FPC is never going to allow

Re: [fpc-devel] class operator overloads

> On Jun 10, 2019, at 9:31 AM, Sven Barth via fpc-devel > wrote: > > The +-operator is not defined internally thus it is allowed to be overloaded. > (is it really that hard to understand? If you can use an operator in code > without declaring an operator overload then this operator is

Re: [fpc-devel] class operator overloads

Ryan Joseph schrieb am Mo., 10. Juni 2019, 15:28: > > > > On Jun 10, 2019, at 9:25 AM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > The operator for assigning one class instance to another exists and is > internal thus it is not allowed to be overloaded. > > > > Is

Re: [fpc-devel] class operator overloads

> On Jun 10, 2019, at 9:25 AM, Sven Barth via fpc-devel > wrote: > > The operator for assigning one class instance to another exists and is > internal thus it is not allowed to be overloaded. > Is that true for binary operators also? The same principle could apply to them also and

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

FYI: I thought a little bit more about your answer and decided to try it with my Stanford compiler; in fact, your pointer parameter is a VALUE parameter, and because it is copied into the procedure's local stack, it should be treated much like a local variable IMO, and there it is indeed

Re: [fpc-devel] class operator overloads

Ryan Joseph schrieb am Mo., 10. Juni 2019, 14:28: > > > > On Jun 10, 2019, at 3:13 AM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > A basic principle of operator overloads is that existing, internal > operators are not overloadable. This principle won't be

Re: [fpc-devel] class operator overloads

> On Jun 10, 2019, at 3:13 AM, Sven Barth via fpc-devel > wrote: > > A basic principle of operator overloads is that existing, internal operators > are not overloadable. This principle won't be abandoned only because you want > managed classes. > Existing internal operators? Sorry I

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On 10/06/2019 04:00, Dmitry Boyarintsev wrote: function DoSomething (a: ^Integer; b: Pointer): integer; Should the flowing code (inside of DoSomething body) be ok as well?   ((^Integer)(b))^ := a^; (keep in mind that ^A ... ^Z is also a character escaping) Inside code / Outside declaration,

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On 10/06/2019 02:47, Ben Grasset wrote: Yes? Obviously? I clearly demonstrated the technical benefit in my original comment. *Yet again *though I do not understand why this is controversial. It would amount to a very tiny syntax addition, that does *nothing *other than make certain things

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Mon, 10 Jun 2019, Florian Klämpfl wrote: Am 10.06.2019 um 09:14 schrieb Michael Van Canneyt: Now, there exists an exception to this rule, introduced by Borland: open array parameters. Well, open strings and open arrays cannot be considered as real types imo (you cannot declare

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

Am 10.06.2019 um 09:14 schrieb Michael Van Canneyt: > > Now, there exists an exception to this rule, introduced by Borland: open > array parameters. Well, open strings and open arrays cannot be considered as real types imo (you cannot declare anything else than a parameter as open

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

Am 10.06.2019 um 00:28 schrieb Ben Grasset: > On Sun, Jun 9, 2019 at 11:26 AM Florian Klämpfl > wrote: > > Yes, but this has *nothing* to do with the output of -vp. Nothing. > > > My point with that was more just getting at "clearly typed pointer aliases >

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

On Mon, 10 Jun 2019, Ben Grasset wrote: So, you're going to keep pretending like you're actually concerned about maintaining the integrity of some (completely fictional) "traditional" Pascal (that FPC never has been and was presumably never intended to be), and implying that arbitrary

Re: [fpc-devel] class operator overloads

Ryan Joseph schrieb am Mo., 10. Juni 2019, 03:00: > Sorry to bring this up again but I had a thought today while working > regarding class operator overloads in classes (i.e. operators that are > members of classes). > > If the operators in classes allowed another parameter for the left sided >

Re: [fpc-devel] Thoughts on being able to declare "pointer-to-type" parameters directly in method signatures?

> You can do it like this (yes, works in mode Delphi as well): > > === code begin === > > {$mode objfpc} > {$modeswitch advancedrecords} > > type > generic TPointerType = record > public type > PT = ^T; > end; > > generic procedure MemCopy(Dest, Src: specialize > TPointerType.PT; Len: