> Pascal does not define any variable initialization itself - one should
> always init all Pascal vars of any type. Doing so is an excellent
coding > habit also portable to any other language/OS - protects against
> low-level implementation changes.
>
> I never trust a side effect I didn't code
Joao Morais replied to Jonas with:
>I think I didn't get your point. What about this piece of code:
>
>interface
>
>function foo: tfoo;
>
>implementation
>
>var
> _foo: tfoo;
>
>function foo: tfoo;
>begin
> if not assigned(_foo) then
> _foo := tfoo.create;
> result := _foo;
>end;
>
>Is it safe?
I wrote:
3. local class zeroed
4. global class zeroed
I meant class instance zeroed
(Regarding Jonas' nitpick ;-)
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
I wrote:
I think something like:
procedure test;
var blah: integer = 0;
begin
end;
Is useful.. i.e. initialized variables that are done on the spot.
To expand on this.. not only local scope vars, but global..
var
global: integer = 0;
I agree is much clearer than leaving it to the assumpti
>Using uninitialised variables is virtually always bad, regardless of the
> scope. And the fact that
> global variables are zeroed at the program start is afaik not defined
> by the Pascal standard. It's
> just a side effect of the way most operating systems work.
I think something like:
proce
On 25 Mar 2008, at 14:21, Joao Morais wrote:
Jonas Maebe wrote:
Using uninitialised variables is virtually always bad, regardless
of the scope. And the fact that global variables are zeroed at the
program start is afaik not defined by the Pascal standard. It's
just a side effect of the wa
Jonas Maebe wrote:
Using uninitialised variables is virtually always bad, regardless of the
scope. And the fact that global variables are zeroed at the program
start is afaik not defined by the Pascal standard. It's just a side
effect of the way most operating systems work.
I think I didn't g
On 25 Mar 2008, at 14:40, L wrote:
Not a fool proof test since random values have a chance of being
zero, but it basically shows:
1. global old heap object NOT zeroed
2. local old heap object NOT zeroed
3. local class zeroed
4. global class zeroed
The above terminology is wrong. Given your
p.s. I think the inconsistent behavior between local scope records
and global scope records is kind of a flaw/danger in modern
pascal.. as the bugs may not be caught until someone builds a
program with local scope var..
Using uninitialised variables is virtually always bad, regardless
o
I wrote:
What about old borland objects (heap and stack initialization) process?
program test1;
type
trec = record i: integer; end;
tclass = class i: integer; end;
tobj = object i: integer; end;
pobj = ^Tobj;
procedure show;
var rec: trec; c: tclass; o: tobj; po: pobj;
begin
write
On 25 Mar 2008, at 13:40, L wrote:
What about old borland objects (heap and stack initialization)
process?
I am guessing they are more like records...
They are exactly like records.
or do heap objects act like classes in that they are filled with
zeros?
Unlike classes, objects have no
What about old borland objects (heap and stack initialization) process?
I am guessing they are more like records... or do heap objects act like
classes in that they are filled with zeros?
p.s. I think the inconsistent behavior between local scope records and
global scope records is kind of a
Tomas Hajny rašė:
Isn't Fps one of the third party front-ends for fpc (with completely
independent versioning, of course)?
Yes, "FPS is system consisting from graphical user interface and
integrated Free Pascal compiler."
(http://ims.mii.lt/fps/en/devel/index.html).
--
Valdas Jankūnas
On 25 Mar 2008, at 04:27, L wrote:
So.. now I ask..
type something = class
s: ansistring;
int:integer
end;
Is "int" set to zero when it is a local scope var in a procedure
created on the heap with Create()?
New class instances are always automatically filled with zeroes upon
creation.
14 matches
Mail list logo
