Re: Strange EAccessViolation which I cannot figure out...

Rob Kennedy wrote:

Jamie wrote:

#1.
You need a constructor, never assume that an object in a class
is always NILL just because you know you haven't created it yet.


That's a perfectly safe assumption. Constructors are documented to always set their objects' fields to zero, nil, empty, or unassigned (depending on each field's type). In fact, the documentation says "there is no need to initialize fields in a constructor’s implementation except to nonzero or nonempty values."
Sorry, you don't get it. If you don't set it to some fixed value at
start up, then in your code as you were using, you were testing for
the creation of the object just by testing for a NIL>
In this case, you must either create the object of make sure you
clear the field to NIL>
Regardless of what it saids in the help, I can tell you by experience
that you should not assume the class to Nil your fields for you automatically in the constructor.
When memory is allocated, Delphi likes to zero it out, in this case
it will work how ever, if memory has been used already and it's still
in delphi's heap, it just simply gives you the memory. this means, what
ever was there before you get.

The last time I knew, Delphi uses the option from the API to get a
zeroed chunk of memory..
To speed things up, normally memory is not wiped while delphi has it
in it's own heap.


#2.
In your OutputDebugString(pchar(dbls.count)); is incorrect use of.

The dbls.counts yields a integer type, you have implied with a
type cast around this returned value as a pointer to a pchar string.


Aha, yes, that's the real problem.


--
"I'm never wrong, once i thought i was, but was mistaken"
Real Programmers Do things like this.
http://webpages.charter.net/jamie_5

.

Relevant Pages

  • Re: Strange EAccessViolation which I cannot figure out...
    ... Constructors are documented to always set their objects' fields to zero, nil, empty, or unassigned. ... That's _before_ the implementation of any constructor begins to execute. ... it just simply gives you the memory. ... Newly allocated memory might be zeroed by the OS on its way to Delphi's memory manager, but once Delphi has it, it won't do any further zeroing. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Question on Free and Nil
    ... I use a constructor in the TFrame.Create procedure, and a destructor in the ... > In the way you describe it, I own the memory since I created the TFrame. ... > Then I should Free it first, then set it to nil; ...
    (comp.lang.pascal.delphi.misc)
  • Re: Strange EAccessViolation which I cannot figure out...
    ... Two problems with this constructor, ... Instead of directly creating a new TObjectList, I have chosen to initialise dbls to nil. ... Am I correct in assuming that an empty TObjectList takes up memory space? ...
    (comp.lang.pascal.delphi.misc)
  • Exception on Create and before my code
    ... I am having a problem in Delphi and I figured anyone in here might understand it ... and it never goes pass the "begin" in the constructor when I press F7. ... Here is me creating an instance which fails: ... Note that adding a nil in there lets the Create pass through the begin. ...
    (borland.public.delphi.language.basm)
  • Re: Readings on clr optimization?
    ... The compiler cannot inline a call to a constructor if the class has a static ... Weak references are special objects that allow you to track references that ... There aren't many implication with memory ...
    (microsoft.public.dotnet.framework.clr)