Anthony Walter schrieb:
This first time concerning the topic const records passed
incorrectly you said, It is nowhere written in the Delphi specs that
const parameters are passed by reference. It is often so, but is by no
means guaranteed
I checked this out. Both Turbo Pascal and fpc
On 02 Dec 2009, at 10:26, Holger Bruns wrote:
I checked this out. Both Turbo Pascal and fpc reported the same
error massage: Variable identifier expected. You simply cannot pass
constant values by reference.
Passing a parameter by reference and var parameters are not the same
thing.
In our previous episode, Anthony Walter said:
Allows is not the same as forces. This line in the help file does not
say that const parameters are passed by reference. It says that it may often
be so, perhaps all current implementations make it so, but it is by no means
guaranteed.
On 30 Nov 2009, at 10:29, Marco van de Voort wrote:
In our previous episode, Anthony Walter said:
Martin Schreiber also chimed in, pointing out:
http://bit.ly/6uaAiB
Larger sets, records, and static arrays are passed as 32-bit pointers
to the value.
The documentation is unambiguous
In our previous episode, Jonas Maebe said:
anything to say on the subject is patently false.
As per what? OS ABI? Delphi rules?
As per the linked Delphi documentation. But as has mentioned before, the
Delphi documentation doesn't match its implementation in case of cdecl and
const
On Sun, Nov 29, 2009 at 1:11 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
On 29 Nov 2009, at 16:51, Anthony Walter wrote:
Having said all that, Jonas, what is the actual implemented behaviour
of FPC? Does it 0 initialize heap memory at startup or not?
I guess you mean global data rather
Anthony Walter schrieb:
I don't care if you claim to have written documentation, you clearly
either don't have a grasp of the English language, good memory,
research skills, or some combination those deficiencies.
Michael and so Jonas are Authors and Developers of FPC. Most FPC Authors
are
Can we please not start bashing people here?
(Cuuntry of origin: Netherlands, so not a native English speaker as well)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Anthony Walter schrieb:
Okay, I am going to call bullshit on you.
What about just unsubscribing from the list? Nobody needs you here. MvC
did an incredible job on FPC docs, you just waste our time.
___
fpc-pascal maillist -
Florian Klaempfl wrote:
Anthony Walter schrieb:
Okay, I am going to call bullshit on you.
What about just unsubscribing from the list? Nobody needs you here. MvC
did an incredible job on FPC docs, you just waste our time.
Actually it is a very ridiculous behavior to talk about developers
Anthony Walter wrote:
Okay, I am going to call bullshit on you.
I, like many others in this list, resent your unwarranted behavior
towards Michael Van Canneyt.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
On 28 Nov 2009, at 22:34, Michael Van Canneyt wrote:
It was Jonas Maebe (Jonas, correct me if I'm wrong) who pointed
out (already some time ago) that this behaviour is purely coincidental (but
admittedly convenient), and should not be taken for granted.
That's correct,
Usually, this is
Hi Jürgen,
Not that I am aware of. But for what reason do you want such a behaviour?
I wrote data analysis programs which are very difficult. I change some
lines to optimize a program. Somethimes it is necessary that I will save
a variable after an input because the second setup of the variable
On 28 Nov 2009, at 23:31, Anthony Walter wrote:
This second time regarding the current discussion you said: This is
not guaranteed in any way. and nowhere it says in the Pascal
language specification that this is guaranteed by the compiler
And I responded with the section, subsection, page
Jonas,
Thank you. I certainly will make an attempt to tone down a few of my
remarks which I admit were inflammatory. I assure everyone here
though, my purpose in conversing on these lists is to help improve
FPC, so far by discussing easy to resolve and reproduce technical
points. I personally
Anthony Walter wrote:
Having said all that, Jonas, what is the actual implemented behaviour
of FPC? Does it 0 initialize heap memory at startup or not? If not,
what is the justification for not doing so when this has been a long
established behaviour of Delphi?
It's not the compiler or RTL
On 29 Nov 2009, at 16:51, Anthony Walter wrote:
Having said all that, Jonas, what is the actual implemented behaviour
of FPC? Does it 0 initialize heap memory at startup or not?
I guess you mean global data rather than heap (heap is what is handled by
getmem/freemem/..., and there are no
FPC currently initialises the global data to 0 on platforms that do not do
this by themselves. When it turns global variables into register variables,
it will also initialise such registers with 0.
Ah, okay. So it is working as expected. Thanks for the reply.
On Sun, 29 Nov 2009, Anthony Walter wrote:
Jonas,
Thank you. I certainly will make an attempt to tone down a few of my
remarks which I admit were inflammatory. I assure everyone here
though, my purpose in conversing on these lists is to help improve
FPC, so far by discussing easy to resolve
Micha Nelissen wrote:
Anthony Walter wrote:
Having said all that, Jonas, what is the actual implemented behaviour
of FPC? Does it 0 initialize heap memory at startup or not? If not,
what is the justification for not doing so when this has been a long
established behaviour of Delphi?
It's not
On 29 Nov 2009, at 19:20, Mehmet Erol Sanliturk wrote:
My experience with Windows XP Professional is that it is NOT zeroing the
memory . I know this from actual Delphi ( and also Free Pascal ) compiled
program executions . Due to this I am explicitly initializing all of the
local simple
Jonas Maebe wrote:
On 29 Nov 2009, at 19:20, Mehmet Erol Sanliturk wrote:
My experience with Windows XP Professional is that it is NOT zeroing the memory .
I know this from actual Delphi ( and also Free Pascal ) compiled program
executions .
Due to this I am explicitly initializing all of
On Nov 28, 2009, at 1:15 PM, Anthony Walter wrote:
This is not guaranteed in any way. It happens to be so most of the
time,
but your code should never assume this is so, except for global
Ansistring
variables.
If all globals weren't initialized to 0 a lot of code from lots of
people
Anthony Walter wrote:
Okay, I am going to call bullshit on you. This is the second time (in
a few weeks) where you've replied to something I've written with wrong
information.
This first time concerning the topic const records passed
incorrectly you said, It is nowhere written in the Delphi
On 29 Nov 2009, at 22:59, Anthony Walter wrote:
Do you mean this one?
Using const allows the compiler to optimize code for structured- and
string-type parameters.
Allows is not the same as forces. This line in the help file does not
say that const parameters are passed by reference. It
So it seems that passing them by value actually corresponds to what the
Delphi docs say.
Jonas, I agree, the documentation definitely does address the issue,
which was where that conversation was derailed.
Regarding actual implementation, I previously posted the full source
to a test program
This is quite simple :
1 - Imagine that fpc initializes all memory to 0.
2 - Imagine that you are running on a low power platform.
3 - You are not going to use the default value of 0.
4 - You reinitialize the memory to your own default value.
See, you did TWO memory store instructions instead of
Hello,
is it possible to set a variable in a programm as a readonly variable?
I would set a variable at a position in the runing programm. Since this
time the variable should be readonly. The next set of the variable
should produce an error.
In bash programming you found a command readonly
is it possible to set a variable in a programm as a readonly variable?
Not that I am aware of. But for what reason do you want such a behaviour?
And if I think it over, this can only work at runtime (letting the program
crash on the second assignment). At compile time the compiler may not
On Sat, 28 Nov 2009 14:58:26 +0100
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
is it possible to set a variable in a programm as a readonly variable?
Not that I am aware of. But for what reason do you want such a behaviour?
And if I think it over, this can only work at runtime
On Sat, 28 Nov 2009 15:07:42 +0100
Mattias Gaertner nc-gaert...@netcologne.de wrote:
On Sat, 28 Nov 2009 14:58:26 +0100
Jürgen Hestermann juergen.hesterm...@gmx.de wrote:
is it possible to set a variable in a programm as a readonly variable?
Use the following:
property MyVar: integer
You can use read function:
var
DirectAccessToValue: T;
function Value: T; inline;
begin
Result := DirectAccessToValue;
end;
begin
...
DirectAccessToValue := ...;
...
DoSomething(Value);
end.
On Sat, Nov 28, 2009 at 13:55, Markus Glugla f...@xgelb.de wrote:
Hello,
is it possible
procedure InitMyVariable(Value: T);
function MyVariable: T;
implementation
var
PrivateMyVariable: T;
PrivateMyVariableSet: Boolean;
procedure InitMyVariable(Value: T);
begin
if not PrivateMyVariableSet then
PrivateMyVariable := Value;
PrivateMyVariableSet := True;
end;
function
On Sat, 28 Nov 2009 12:10:48 -0500
Anthony Walter sys...@gmail.com wrote:
procedure InitMyVariable(Value: T);
function MyVariable: T;
implementation
var
PrivateMyVariable: T;
PrivateMyVariableSet: Boolean;
procedure InitMyVariable(Value: T);
begin
if not PrivateMyVariableSet
PrivateMyVariableSet is not intialised, so will have an undefined
(random) value when InitMyVariable is first called.
Mattias' code given earlier avoids this problem.
Bzzzt. Wrong.
Global variables (even in the implementation section) are always
initialized to 0.
On Sat, 28 Nov 2009, Anthony Walter wrote:
PrivateMyVariableSet is not intialised, so will have an undefined
(random) value when InitMyVariable is first called.
Mattias' code given earlier avoids this problem.
Bzzzt. Wrong.
Global variables (even in the implementation section) are always
This is not guaranteed in any way. It happens to be so most of the time,
but your code should never assume this is so, except for global Ansistring
variables.
If all globals weren't initialized to 0 a lot of code from lots of
people would potentially be in trouble. I've been using
On Sat, 28 Nov 2009, Anthony Walter wrote:
This is not guaranteed in any way. It happens to be so most of the time,
but your code should never assume this is so, except for global Ansistring
variables.
If all globals weren't initialized to 0 a lot of code from lots of
people would
That should be removed, actually.
I'll take that as an admission that you were wrong. It's in the
specification, lot's of code uses the feature, and it works the way I
described.
Changing the specification to match your argument is stupid.
___
On Sat, 28 Nov 2009, Anthony Walter wrote:
That should be removed, actually.
I'll take that as an admission that you were wrong. It's in the
specification, lot's of code uses the feature, and it works the way I
described.
I'm not admitting anything here, I am attempting to enlighten you
Okay, I am going to call bullshit on you. This is the second time (in
a few weeks) where you've replied to something I've written with wrong
information.
This first time concerning the topic const records passed
incorrectly you said, It is nowhere written in the Delphi specs that
const
Michael - I see you are one of the authors of fpc (thank you), so I assume your
statement is true by virtue of inside knowledge. But this is a concern. As
I'm sure you will know, in Delphi globals are always initialised to zero - and
in my experience (almost 15 years with a 30-strong Delphi
42 matches
Mail list logo
