Graeme Geldenhuys wrote on do, 19 nov 2009:
Jonas Maebe wrote:
Delphi compatibility. And Delphi does that because COM requires this
behaviour.
Can't that behaviour be limited to Windows platform only.
It would change the behaviour of code between Windows and non-Windows
platforms. One
On Thu, Nov 19, 2009 at 18:36, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
More importantly, another thing it would affect is that in case someone has
written their own fillchar with an out parameter, and *expects* reference
counted structures to be finalised at the caller side before they
Alexander Klenin wrote on do, 19 nov 2009:
On Thu, Nov 19, 2009 at 18:36, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
More importantly, another thing it would affect is that in case someone has
written their own fillchar with an out parameter, and *expects* reference
counted structures to be
Graeme Geldenhuys schrieb:
Florian Klaempfl wrote:
Without COM, FPC wouldn't have out parameters.
Why do you say that?
Because I added it for Delphi compatibility which needs it for COM?
I see many use-cases for out parameters
You mean for VAROUT parameters :)?
Jonas Maebe wrote:
Alexander Klenin wrote on do, 19 nov 2009:
Can you give an example code which would be (badly) affected by
proposed change?
type
tr = record
str: ansistring;
end;
procedure clear(out rec; size: ptruint);
begin
fillchar(rec,size,0);
end;
var
r: tr;
begin
Florian Klaempfl wrote:
I see many use-cases for out parameters
You mean for VAROUT parameters :)?
I search the latest FP Language Reference document, and there is no
mention of 'varout'. I also tried to use varout in a procedure as
follows - which gave a compiler error with FPC 2.4.0-rc1
Alexander Klenin wrote:
Can you give an example code which would be (badly) affected by
proposed change?
Thanks Alexander, you beat me to that question. :-)
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/
Graeme Geldenhuys schreef:
Florian Klaempfl wrote:
I see many use-cases for out parameters
You mean for VAROUT parameters :)?
First one is not compilable, but the second one is. So no, I don't
understand your comment about 'varout'? Please explain more.
varout could be the name of the
Graeme Geldenhuys schrieb:
Florian Klaempfl wrote:
I see many use-cases for out parameters
You mean for VAROUT parameters :)?
I search the latest FP Language Reference document, and there is no
mention of 'varout'. I also tried to use varout in a procedure as
follows - which gave a
Vincent Snijders schrieb:
Graeme Geldenhuys schreef:
Florian Klaempfl wrote:
I see many use-cases for out parameters
You mean for VAROUT parameters :)?
First one is not compilable, but the second one is. So no, I don't
understand your comment about 'varout'? Please explain more.
Vincent Snijders wrote:
varout could be the name of the new parameter modifier that Jonas
mentions[1] and that has the semantics that you think out should
have, but hasn't.
Ah, now I understand. Thanks Vincent.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using
Florian Klaempfl wrote:
initialized. But be warned: with such a parameter type you can easily
create memory leaks with automated types like ansistrings.
Well, isn't that what heaptrc is for? I enable heaptrc by default for
all my projects (except on release builds). That way I can catch
Graeme Geldenhuys wrote:
Florian Klaempfl wrote:
initialized. But be warned: with such a parameter type you can easily
create memory leaks with automated types like ansistrings.
Well, isn't that what heaptrc is for?
No, the language should protect you from such easy to make mistakes.
In
Graeme Geldenhuys wrote:
As I stated in the other mailing list. It's not about a obsession to get
hint warning free code. It's about spoting REAL issues in code between
all the crap the compiler currently spits out. If your project uses a
lot of structure types, you can quickly sit with
Paul Ishenin schrieb:
Graeme Geldenhuys wrote:
As I stated in the other mailing list. It's not about a obsession to get
hint warning free code. It's about spoting REAL issues in code between
all the crap the compiler currently spits out. If your project uses a
lot of structure types, you
Marc Weustink wrote:
Well, isn't that what heaptrc is for?
No, the language should protect you from such easy to make mistakes.
I guess that's the ideal situation. Currently the language doesn't stop
me from creating other memory leaks like not freeing a TStringList or
other object
I still do not fully understand.
On Thu, Nov 19, 2009 at 19:20, Martin laza...@mfriebe.de wrote:
Jonas Maebe wrote:
[skipped example]
Well in this case, the code is actually positively affected by the out
param (because it avoids the mem leak)
Jonas, can you confirm that your example is
Paul Ishenin wrote:
Compiler will add a flag for each var/const argument that they dont
require that checks.
Can't the compiler simply initialize structured types by default?
Initialize char arrays to empty strings, other structures like pointers
to nil, byte arrays to #0 etc..?
After all,
On 19 Nov 2009, at 11:21, Alexander Klenin wrote:
On Thu, Nov 19, 2009 at 19:20, Martin laza...@mfriebe.de wrote:
Jonas Maebe wrote:
[skipped example]
Well in this case, the code is actually positively affected by the
out
param (because it avoids the mem leak)
Jonas, can you confirm
Jonas Maebe wrote:
If you change the behaviour of out so that such parameters are no
longer finalised before the routine is entered, then the above will
cause a memory leak. You can verify this by changing the out rec
parameter into var rec.
Then this is definitely not a sextopod but an
Jonas Maebe wrote:
On 19 Nov 2009, at 11:21, Alexander Klenin wrote:
Well in this case, the code is actually positively affected by the
out
param (because it avoids the mem leak)
Jonas, can you confirm that your example is incorrect one,
and Martin's example below is actually what you
In our previous episode, Graeme Geldenhuys said:
initialized. But be warned: with such a parameter type you can easily
create memory leaks with automated types like ansistrings.
Well, isn't that what heaptrc is for? I enable heaptrc by default for
all my projects (except on release
On Thu, Nov 19, 2009 at 20:31, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
On 19 Nov 2009, at 11:21, Alexander Klenin wrote:
On Thu, Nov 19, 2009 at 19:20, Martin laza...@mfriebe.de wrote:
Jonas Maebe wrote:
[skipped example]
Well in this case, the code is actually positively affected
On 19 Nov 2009, at 11:24, Graeme Geldenhuys wrote:
Paul Ishenin wrote:
Compiler will add a flag for each var/const argument that they dont
require that checks.
Can't the compiler simply initialize structured types by default?
The compiler already initialises the reference counted fields
On 19 Nov 2009, at 11:39, Thaddy wrote:
Jonas Maebe wrote:
If you change the behaviour of out so that such parameters are no
longer finalised before the routine is entered, then the above will
cause a memory leak. You can verify this by changing the out rec
parameter into var rec.
On 19 Nov 2009, at 11:42, Alexander Klenin wrote:
No, I asked for an example of code that would be negatively affected
by
changing var to out in FillChar parameter.
I don't know by heart anymore, but as I mentioned the compiler crashed
when I tried that (or if you did that move, which
On Thu, Nov 19, 2009 at 20:46, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
On 19 Nov 2009, at 11:42, Alexander Klenin wrote:
No, I asked for an example of code that would be negatively affected by
changing var to out in FillChar parameter.
I don't know by heart anymore, but as I mentioned
Alexander Klenin wrote:
On Thu, Nov 19, 2009 at 20:46, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
On 19 Nov 2009, at 11:42, Alexander Klenin wrote
No, I asked for an example of code that would be negatively affected by
changing var to out in FillChar parameter.
I don't know by
On 19 Nov 2009, at 11:51, Alexander Klenin wrote:
On Thu, Nov 19, 2009 at 20:46, Jonas Maebe
jonas.ma...@elis.ugent.be wrote:
I don't know by heart anymore, but as I mentioned the compiler
crashed when
I tried that (or if you did that move, which has the same problem).
There is
probably
On Thu, Nov 19, 2009 at 21:02, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
Ok, so how about introducing, say, FillMem procedure, which is
identical to FillChar
except that it has out parameter,
See http://lists.freepascal.org/lists/fpc-devel/2009-November/018559.html
FillMem would be a
Florian Klaempfl flor...@freepascal.org:
Without COM, FPC wouldn't have out parameters.
And because there would be no difference between var and out then, it also
wouldn't have the hint. Case dismissed. ;)
Vinzent.
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt
Without COM, FPC wouldn't have out parameters.
And because there would be no difference between var and out then, it also
wouldn't have the hint. Case dismissed. ;)
Vinzent.
Yup.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Florian Klaempfl flor...@freepascal.org:
A VAROUT parameter could have the same semantics as VAR except that the
compiler does not expect that it is needed that it is initialized. But
be warned: with such a parameter type you can easily create memory leaks
with automated types like
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
A VAROUT parameter could have the same semantics as VAR except that the
compiler does not expect that it is needed that it is initialized. But
be warned: with such a parameter type you can easily create memory leaks
with
Graeme Geldenhuys gra...@mastermaths.co.za:
Can't the compiler simply initialize structured types by default?
[...]
After all, this is already done for AnsString, Integer type, real types
etc...
No, it's not (except for AnsiString, because it's reference counted).
Vinzent.
--
GRATIS für
Florian Klaempfl flor...@freepascal.org:
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
A VAROUT parameter could have the same semantics as VAR except that the
compiler does not expect that it is needed that it is initialized. But
be warned: with such a parameter
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
A VAROUT parameter could have the same semantics as VAR except that the
compiler does not expect that it is needed that it is initialized. But
be warned: with
On 19 Nov 2009, at 22:31, Florian Klaempfl wrote:
Because a VAROUT parameter would be simply overwritten by the callee
even if it contains a valid automated type:
procedure p(varout v : ansistring);
begin
v:='asdf';
end;
I don't think that this could cause a memory leak, otherwise this
Florian Klaempfl flor...@freepascal.org:
Because a VAROUT parameter would be simply overwritten by the callee
even if it contains a valid automated type:
That's a semantic definition, not an explanation. IOW: What stops you from
selecting to implement the proper semantics depending on the
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
Because a VAROUT parameter would be simply overwritten by the callee
even if it contains a valid automated type:
That's a semantic definition, not an explanation.
Sorry, but it seems you didn't follow up the thread, so I
Florian Klaempfl flor...@freepascal.org:
Vinzent Höfler schrieb:
Florian Klaempfl flor...@freepascal.org:
Because a VAROUT parameter would be simply overwritten by the callee
even if it contains a valid automated type:
That's a semantic definition, not an explanation.
Sorry, but
Jonas Maebe wrote:
Delphi compatibility. And Delphi does that because COM requires this
behaviour.
Can't that behaviour be limited to Windows platform only. Now *all*
platforms and all non-COM code has to be stuck with the useless compiler
hint simply because of some Windows and more
Graeme Geldenhuys schrieb:
Jonas Maebe wrote:
Delphi compatibility. And Delphi does that because COM requires this
behaviour.
Can't that behaviour be limited to Windows platform only. Now *all*
platforms and all non-COM code has to be stuck with the useless compiler
hint simply because
Florian Klaempfl wrote:
Without COM, FPC wouldn't have out parameters.
Why do you say that? I see many use-cases for out parameters - all
without using Windows or Windows+COM.
Not to mention, even Kylix (which for obvious reasons doesn't have COM
support) had out parameter support. So even
Hi,
I asked a question about a compiler hint in the fpc-users mailing list.
As JoshyFun suggested, is it not maybe better to change FillChar()
definition so first parameter is a out parameter - to prevent
unnecessary compiler hint in code?
Original Message
Subject: Re:
On 17 Nov 2009, at 12:04, Graeme Geldenhuys wrote:
I asked a question about a compiler hint in the fpc-users mailing list.
As JoshyFun suggested, is it not maybe better to change FillChar()
definition so first parameter is a out parameter - to prevent
unnecessary compiler hint in code?
No,
Jonas Maebe wrote:
On 17 Nov 2009, at 12:04, Graeme Geldenhuys wrote:
I asked a question about a compiler hint in the fpc-users mailing list.
As JoshyFun suggested, is it not maybe better to change FillChar()
definition so first parameter is a out parameter - to prevent
unnecessary compiler
On 17 Nov 2009, at 13:43, Thaddy tha...@thaddy.com wrote:
Jonas Maebe wrote:
No, that is not possible. I once tried to change move and fillchar
to use out parameters instead of var parameters, and the result
was all sorts of crashes. The reason is that out has special
semantics for
Jonas Maebe wrote:
Delphi compatibility. And Delphi does that because COM requires this
behaviour.
Yes, but.. As I hinted before that is because COM is reference counted
on an intermediate level by a certain OS. A simple (but performance
cost) change of the memorymanager can fix that for
49 matches
Mail list logo
