>Gesendet: Samstag, 30. Juni 2018 um 13:34 Uhr
>Von: "Florian Klämpfl"
Sorry for the late reply.
>> In an ideal world, either the language would not let you write code that has
>> random behavior or the compiler would enforce this.
>
>Compile with trunk and -Sew and you get this behavior.
On 29.06.2018 17:57, Stefan Glienke wrote:
Change the code to following:
type
TFoo = class
A, B: Vector;
end;
procedure Main;
var
foo: TFoo;
begin
foo := TFoo.Create;
foo.A := DoSomething(3);
foo.A[0] := 42;
foo.B := DoSomething(4);
Writeln(foo.B[0]);
end;
Now we
Am 29.06.2018 um 21:27 schrieb Thorsten Engler:
>>> [...] COM interface methods can't logically not be virtual,
>>
>> I think you are confusing things here. They can be virtual or not
>> virtual in COM and CORBA.
>
> I think a lot of people simply don't understand how interfaces are
>
On Sat, 30 Jun 2018, Willibald Krenn wrote:
Managed fields of records are "setup" ;)
I will add a section about this in the documentation, seeing that people
often confuse the 2 concepts.
In an ideal world, either the language would not let you write code that has
random behavior or the
Am 30.06.2018 um 12:02 schrieb Willibald Krenn:
Gesendet: Samstag, 30. Juni 2018 um 10:54 Uhr
Von: "Michael Van Canneyt"
Am 30.06.2018 um 08:47 schrieb Sven Barth via fpc-devel:
The variables we're talking about here *are* initialized.
Bit lost here. Maybe A and B are setup, but not
>Gesendet: Samstag, 30. Juni 2018 um 10:54 Uhr
>Von: "Michael Van Canneyt"
>> Am 30.06.2018 um 08:47 schrieb Sven Barth via fpc-devel:
>>> The variables we're talking about here *are* initialized.
>
Bit lost here. Maybe A and B are setup, but not result. And the apparent re-use
of tmp vars also
On Sat, 30 Jun 2018, Florian Klämpfl wrote:
Am 30.06.2018 um 08:47 schrieb Sven Barth via fpc-devel:
Willibald Krenn mailto:willibald.kr...@gmx.at>>
schrieb am Sa., 30. Juni 2018, 08:01:
TBH, I didn't know this issue existed in Delphi and I've done my
share of Delphi over time. I
Am 30.06.2018 um 08:47 schrieb Sven Barth via fpc-devel:
Willibald Krenn mailto:willibald.kr...@gmx.at>>
schrieb am Sa., 30. Juni 2018, 08:01:
TBH, I didn't know this issue existed in Delphi and I've done my share of
Delphi over time. I still maintain that
for managed types the
Willibald Krenn schrieb am Sa., 30. Juni 2018,
08:01:
> TBH, I didn't know this issue existed in Delphi and I've done my share of
> Delphi over time. I still maintain that for managed types the compiler is
> responsible for some minimal initialization (like it's done for records
> etc, no?).
>
Gesendet: Donnerstag, 28. Juni 2018 um 20:06 Uhr
Von: "Jonas Maebe"
An: fpc-devel@lists.freepascal.org
Betreff: Re: [fpc-devel] Managed Types, Undefined Bhaviour
On 28/06/18 18:45, Willibald Krenn wrote:
>
> type Vector = array of integer;
> function DoSomething (len: longint): Vector
On 29/06/18 22:02, Stefan Glienke wrote:
If I am not mistaken (this is from my observarion and might not be 100%
accurate) usually the rule in Delphi (possibly similar in FPC) when it
allows to directly pass the LHS as hidden result parameter is when it is
a local variable.
FPC does it when
> -Original Message-
> From: fpc-devel On Behalf Of
> Mattias Gaertner
>
> > [...] COM interface methods can't logically not be virtual,
>
> I think you are confusing things here. They can be virtual or not
> virtual in COM and CORBA.
I think a lot of people simply don't understand how
On 29/06/18 19:03, Stefan Glienke wrote:
Delphi does not reuse them, every call to a function generates a temp
variable. Sure, if you call it in a loop it of course uses the same one.
That does not make any sense to me from a language design point of view.
Either the language guarantees that
> -Original Message-
> From: fpc-devel On Behalf Of
> Martok
> Sent: Saturday, 30 June 2018 03:15
> To: fpc-devel@lists.freepascal.org
> Subject: Re: [fpc-devel] Managed Types, Undefined Bhaviour
>
> Okay, then why does the calling convention change matters so much
On Fri, 29 Jun 2018 19:15:00 +0200
Martok wrote:
> Am 29.06.2018 um 16:37 schrieb Thorsten Engler:
> > The specific functions that implement an interface get baked into the class
> > at the moment when the interface is defined as part of the class. This
> > results in important differences in
> -Original Message-
> From: fpc-devel On Behalf Of
> Michael Van Canneyt
> Sent: Saturday, 30 June 2018 03:11
> To: FPC developers' list
> Subject: Re: [fpc-devel] Managed Types, Undefined Bhaviour
>
>
> Please explain. Exactly how does it demonstrate this
gt; >> To: FPC developers' list
> >> Subject: Re: [fpc-devel] Managed Types, Undefined Bhaviour
> >>
> >> what does this demo actually demonstrate other than that the compiler
> >> functions ?
> >
> > That there is a difference between &qu
Am 29.06.2018 um 16:37 schrieb Thorsten Engler:
> The specific functions that implement an interface get baked into the class
> at the moment when the interface is defined as part of the class. This
> results in important differences in behaviour, depending if methods (in the
> class) are
On Sat, 30 Jun 2018, Thorsten Engler wrote:
-Original Message-
From: fpc-devel On Behalf Of
Michael Van Canneyt
Sent: Saturday, 30 June 2018 01:07
To: FPC developers' list
Subject: Re: [fpc-devel] Managed Types, Undefined Bhaviour
what does this demo actually demonstrate other than
Delphi does not reuse them, every call to a function generates a temp
variable. Sure, if you call it in a loop it of course uses the same one.
But if you have 2 calls after each other the compiler generates two
variables. Even if they are in seperate code branches. I have often
enough
On 29/06/18 17:57, Stefan Glienke wrote:
Now we are back to using temp variables (both Delphi and FPC do) but FPC again
reuses its temp variable for A and B while Delphi uses different ones. Now for
some integer this might not be a big issue but imagine you have something else
in these arrays
Let me add some information to this issue - as I think this is one - before
this drifted into the interface chaining thing:
When you execute this code in Delphi it will print 0 while on FPC it prints 42:
type
Vector = array of integer;
function DoSomething (len: Integer): Vector;
begin
> -Original Message-
> From: fpc-devel On Behalf Of
> Michael Van Canneyt
> Sent: Saturday, 30 June 2018 01:07
> To: FPC developers' list
> Subject: Re: [fpc-devel] Managed Types, Undefined Bhaviour
>
> what does this demo actually demonstrate other than that
On Fri, 29 Jun 2018, Mattias Gaertner wrote:
Pressed send too quickly.
home:~> ./tirc
Chain: 7FA5948CF040
Chain: 7FA5948CF040
Done: 7FA5948CF040
"stdcall" is wrong for Linux. It must be
{$IFNDEF WINDOWS}cdecl{$ELSE}stdcall{$ENDIF};
Then you get under Linux:
Addref:
On Fri, 29 Jun 2018 16:18:04 +0200 (CEST)
Michael Van Canneyt wrote:
> On Fri, 29 Jun 2018, Michael Van Canneyt wrote:
>
> >
> >
> > On Fri, 29 Jun 2018, Martok wrote:
> >
> >> Am 29.06.2018 um 14:41 schrieb Michael Van Canneyt:
> >>> As far as I can see, you get 2 chain and 1 done call.
> -Original Message-
> From: fpc-devel On Behalf Of
> Martok
> Sent: Friday, 29 June 2018 23:55
> To: fpc-devel@lists.freepascal.org
> Interface functions are always virtual and implemented by the
> actually instantiated class. The "override" keyword is neither
> allowed nor needed,
On Fri, 29 Jun 2018, Michael Van Canneyt wrote:
On Fri, 29 Jun 2018, Michael Van Canneyt wrote:
On Fri, 29 Jun 2018, Martok wrote:
Am 29.06.2018 um 14:41 schrieb Michael Van Canneyt:
As far as I can see, you get 2 chain and 1 done call. Which is what I'd
expect.
The overrides of
Am 29.06.2018 um 16:05 schrieb Michael Van Canneyt:
>> The expected output would be 3 Addrefs and 3 Releases.
>
> I don't get that.
Somewhat current FPC trunk output, annotations added manually:
==
Addref: 0022FAA8 Refcount: 1 at 00404961
On Fri, 29 Jun 2018, Michael Van Canneyt wrote:
On Fri, 29 Jun 2018, Martok wrote:
Am 29.06.2018 um 14:41 schrieb Michael Van Canneyt:
As far as I can see, you get 2 chain and 1 done call. Which is what I'd
expect.
The overrides of the _* calls are useless, since they are not virtual
On Fri, 29 Jun 2018, Martok wrote:
Am 29.06.2018 um 14:41 schrieb Michael Van Canneyt:
As far as I can see, you get 2 chain and 1 done call. Which is what I'd expect.
The overrides of the _* calls are useless, since they are not virtual in
TInterfacedObject and hence never called. So that's
Am 29.06.2018 um 14:41 schrieb Michael Van Canneyt:
> As far as I can see, you get 2 chain and 1 done call. Which is what I'd
> expect.
> The overrides of the _* calls are useless, since they are not virtual in
> TInterfacedObject and hence never called. So that's OK too.
Interface functions are
On Fri, 29 Jun 2018, Martok wrote:
Am 29.06.2018 um 12:43 schrieb Michael Van Canneyt:
Out of curiosity, can you give a simple example of such a funny behaviour
in such a chaining pattern ?
We've had this topic about 2 years ago with regard to automatic file close on
interface release.
Am 29.06.2018 um 12:43 schrieb Michael Van Canneyt:
> Out of curiosity, can you give a simple example of such a funny behaviour
> in such a chaining pattern ?
We've had this topic about 2 years ago with regard to automatic file close on
interface release. Interestingly, something must have changed
On Fri, 29 Jun 2018, Martok wrote:
I hope this issue gets addressed, as I deem the current behaviour completely
broken and also going totally against the spirit of Pascal, feeling much more
like some very obscure behaviour I'd expect from some C compiler.
Discovering the handling of this
> I hope this issue gets addressed, as I deem the current behaviour completely
> broken and also going totally against the spirit of Pascal, feeling much more
> like some very obscure behaviour I'd expect from some C compiler.
> Discovering the handling of this issue, however, makes me wonder
>
On 28/06/18 18:45, Willibald Krenn wrote:
type Vector = array of integer;
function DoSomething (len: longint): Vector; begin
SetLength (result,len); // whatever
end;
var A,B: Vector;
begin
A := DoSomething(3);
// changing A here will influence B below,
// which seems ok to some
Dear FPC developers,
Since I am unable to provide a comment on bug report #33912 itself, I figured I had but one option to move the discussion here. Basically, I don't follow the reasoning that led to closing the report "as designed" out of several reasons. To put the situation in a
37 matches
Mail list logo
