<div><div>Having just looked up the references for New/GetMem it may not actually be a question of amount of memory allocated after all, but rather one of correct initialization of the allocated memory.</div><div><br></div>
<div>GetMem() does not initialize the allocated memory, New() does.</div><div><br></div><div>This is explained in the documentation for the "Initialize()" procedure (it might have been helpful if the documentation for GetMem() had mentioned this - or the lack there-of - too - LOL)</div>
<div><br></div><div>So you might find that GetMem() would have worked had you also called Initialise() on the pointer afterward (and Finalize() before calling FreeMem()). But whatever the underlying reasons it is obviously simply much easier and safer (less to remember to have to do, less to get wrong in doing it :)) to use New/Dispose when working with allocations of variables/structured(typed) memory and use GetMem/FreeMem when it is strictly speaking *just* unstructured memory you need (e.g. i/o buffers etc), rather than space for variables.<br>
<br>Glad it helped with your problem in any event. :)</div><div><br></div><div><br><div class="gmail_quote">On 29 August 2011 17:40, David Moorhouse <span dir="ltr"><<a href="mailto:delphi@moorhouse.net.nz">delphi@moorhouse.net.nz</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#FFFFFF" text="#000000">
I'm aware of the compiler layout behind the scene - and the fact
that regardless of the length of the dynamic array, my call to
GetMem (or New) does NOT have to allocate memory for the dynamic
array's contents, just it's overhead :)<br>
<br>
However, the compiler gets the size right using New rather than
GetMem :) So thanks for the tip.<br>
<br>
Cheers<br><font color="#888888">
<br>
D</font><div><div></div><div class="h5"><br>
<br>
<br>
<br>
<br>
On 29/08/11 16:23, Jolyon Smith wrote:
<blockquote type="cite">Is it a compiler *error* or just a compiler
_behaviour_ ?<br>
<br>
I haven't looked into it in detail, but dynamic arrays are
notoriously slippery when you are working with them at a low level
and alarm bells started ringing as soon as I saw they were
involved.
<div>
<br>
</div>
<div>In particular, a dynamic array is a reference type, like a
string. So whilst their may be additional RTTI at a negative
offset from the base address of the array, the "array" itself
may well be a pointer, hence "sizeof()" will return 4 - the size
of a pointer - no matter how many items may be in the array (as
opposed to Length(), obviously).<br>
<br>
NOTE: sizeof(String) also yields "4" even though we all know
that a String variable requires many more bytes than that.</div>
<div><br>
</div>
<div><br>
As far as this particular example goes, do you get any better
results using the typed New() function rather than GetMem()
which knows nothing about the "type" of memory required by the
pointer you are initialising and just blithely allocates the
specified number of bytes...:</div>
<div><br>
</div>
<div>Instead of >> LogData := GetMem( ... ); </div>
<div><br>
</div>
<div>Use >> New( LogData );<br>
<br>
And see if you get better results. :)<br>
<br>
(Also, don't forget to use "Dispose()" to deallocate the memory
obtained with "New()", rather than FreeMem())<br>
<br>
</div>
<div><br>
<div class="gmail_quote">On 28 August 2011 21:33, David
Moorhouse (DUG) <span dir="ltr"><<a href="mailto:delphi@moorhouse.net.nz" target="_blank">delphi@moorhouse.net.nz</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I believe it is a compiler error and will raise a QA ticket<br>
<br>
Thanks for your help<br>
<font color="#888888"><br>
<br>
D<br>
</font>
<div>
<div><br>
<br>
On 26/08/11 08:17, Peter Ingham wrote:<br>
> Try filling LogData with binary zeros after the
Getmem& before the assign.<br>
><br>
> FillChar (LogData^, sizeof(TLogData), 0);<br>
><br>
> I believe the uninitialized memory is messing up
the compiler magic<br>
> associated with the dynamic array.<br>
><br>
><br>
> Any reason the local Tlogdata record is referenced
via a pointer?<br>
><br>
> I suspect the following will also work:<br>
> procedure TUserClass.Log(const LogType: TLogType;
const Args: array of<br>
> const );<br>
> var<br>
> LogData: TLogData;<br>
> begin<br>
> LogData.LogType := LogType;<br>
> LogData.LogArgs := CreateConstArray(Args);<br>
> // ... do some other stuff with the LogData
item finally calling<br>
> end;<br>
><br>
> Cheers<br>
><br>
> On 26/08/2011 1:49 a.m., David Moorhouse wrote:<br>
>> Hi Peter<br>
>><br>
>> Been there done that :)<br>
>><br>
>> The function call is fine. It is the
assignment that causes the AV -<br>
>> because the "bucket" is too small.<br>
>> Assigning it with 16 bytes fixes the problem,
regardless of how many<br>
>> items the array holds.<br>
>><br>
>> I smell compiler magic in the background.<br>
>><br>
>> Cheers<br>
><br>
>> D<br>
>><br>
>> On 25/08/11 17:29, Peter Ingham wrote:<br>
>>> Another attempt to reply...<br>
>>><br>
>>> First thing to do is determine if the crash
occurs in the procedure call,<br>
>>> on the subsequent assign, or in between.<br>
>>><br>
>>> Give this a try:<br>
>>> procedure TUserClass.Log(const LogType:
TLogType; const Args: array of<br>
>>> const );<br>
>>> var<br>
>>> LogData: PLogData;<br>
>>> TempArgs : TConstArray;<br>
>>> begin<br>
>>> // size of record TLogData does not
work<br>
>>> GetMem(LogData, sizeof(TLogData));<br>
>>> LogData.LogType := LogType;<br>
>>> // blows up on one of these lines<br>
>>> TempArgs := CreateConstArray(Args);<br>
>>> LogData.LogArgs := TempArgs;<br>
>>> // ... do some other stuff with the
LogData item finally calling<br>
>>> FreeMem<br>
>>> end;<br>
>>><br>
>>><br>
>>> Regarding the size of a dynamic array,
like a string variable, the<br>
>>> variable (LogArgs in this case) is the size
of a pointer (i.e. 4 bytes<br>
>>> for Win32). If the pointer is non-zero, it
points to a structure which<br>
>>> includes the adjacent array elements
preceded by a length.<br>
>>><br>
>>> One thing to watch out for is that Getmem
does not clear the allocated<br>
>>> memory, so LogData after the Getmem call
will contain any old rubbish.<br>
>>> The reference to LogData.LogArgs in the
assignment may be<br>
>>> dereferencing a non-zero pointer&
attempting to use whatever it<br>
>>> contains.<br>
>>><br>
>>> Cheers<br>
>>><br>
>>><br>
>>> On 25/08/2011 11:40 a.m., David Moorhouse
(DUG) wrote:<br>
>>>> I have the following code snippet<br>
>>>><br>
>>>> <code><br>
>>>> type<br>
>>>> PConstArray = ^TConstArray;<br>
>>>> TConstArray = array of TVarRec;<br>
>>>><br>
>>>> function CreateConstArray(const
Elements: array of const): TConstArray;<br>
>>>><br>
>>>> type<br>
>>>> TLogType = (ltError, ltWarn,
ltInfo);<br>
>>>> PLogData = ^TLogData;<br>
>>>> TLogData = record<br>
>>>> LogType: TLogType;<br>
>>>> LogArgs: TConstArray;<br>
>>>> end;<br>
>>>><br>
>>>> ....<br>
>>>><br>
>>>> procedure TUserClass.Log(const LogType:
TLogType; const Args: array of<br>
>>>> const );<br>
>>>> var<br>
>>>> LogData: PLogData;<br>
>>>> begin<br>
>>>> // size of record TLogData does
not work<br>
>>>> GetMem(LogData,
sizeof(TLogData));<br>
>>>> LogData.LogType := LogType;<br>
>>>> // blows up on next line<br>
>>>> LogData.LogArgs :=
CreateConstArray(Args);<br>
>>>> // ... do some other stuff with the
LogData item finally calling<br>
>>>> FreeMem<br>
>>>> end;<br>
>>>><br>
>>>> function CreateConstArray(const
Elements: array of const): TConstArray;<br>
>>>> var<br>
>>>> I: Integer;<br>
>>>> begin<br>
>>>> SetLength(Result,
Length(Elements));<br>
>>>> for I := Low(Elements) to
High(Elements) do<br>
>>>> Result[I] := // assign a
TVarRec here<br>
>>>> end;<br>
>>>> </code><br>
>>>><br>
>>>> The code that assigns the memory only
assigns 8 bytes - and an access<br>
>>>> violation ensues. If I replace the
call to "sizeof" with the number 16,<br>
>>>> the code works fine.<br>
>>>><br>
>>>> My understanding of dynamic arrays was
that the compiler created a 4<br>
>>>> byte<br>
>>>> field before the first element that
contained the length of the array.<br>
>>>><br>
>>>> So why does the sizeof function not
reflect this ? And why do I<br>
>>>> need 16<br>
>>>> bytes not 12 (4 for LogType + 4 for
length of array + 4 for array<br>
>>>> pointer)?<br>
>>>> Also regardless of the number of items
in the open array parameter, 16<br>
>>>> bytes works, so it does not relate the
length of the TConstArray.<br>
>>>><br>
>>>> Your thoughts ?<br>
>>>><br>
>>>> David<br>
>>>><br>
>>>><br>
>>>><br>
>>>>
_______________________________________________<br>
>>>> NZ Borland Developers Group - Delphi
mailing list<br>
>>>> Post: <a href="mailto:delphi@delphi.org.nz" target="_blank">delphi@delphi.org.nz</a><br>
>>>> Admin: <a href="http://delphi.org.nz/mailman/listinfo/delphi" target="_blank">http://delphi.org.nz/mailman/listinfo/delphi</a><br>
>>>> Unsubscribe: send an email to <a href="mailto:delphi-request@delphi.org.nz" target="_blank">delphi-request@delphi.org.nz</a>
with<br>
>>>> Subject: unsubscribe<br>
>>>><br>
>><br>
>> _______________________________________________<br>
>> NZ Borland Developers Group - Delphi mailing
list<br>
>> Post: <a href="mailto:delphi@delphi.org.nz" target="_blank">delphi@delphi.org.nz</a><br>
>> Admin: <a href="http://delphi.org.nz/mailman/listinfo/delphi" target="_blank">http://delphi.org.nz/mailman/listinfo/delphi</a><br>
>> Unsubscribe: send an email to <a href="mailto:delphi-request@delphi.org.nz" target="_blank">delphi-request@delphi.org.nz</a>
with Subject: unsubscribe<br>
>><br>
> _______________________________________________<br>
> NZ Borland Developers Group - Delphi mailing list<br>
> Post: <a href="mailto:delphi@delphi.org.nz" target="_blank">delphi@delphi.org.nz</a><br>
> Admin: <a href="http://delphi.org.nz/mailman/listinfo/delphi" target="_blank">http://delphi.org.nz/mailman/listinfo/delphi</a><br>
> Unsubscribe: send an email to <a href="mailto:delphi-request@delphi.org.nz" target="_blank">delphi-request@delphi.org.nz</a>
with Subject: unsubscribe<br>
<br>
<br>
_______________________________________________<br>
NZ Borland Developers Group - Delphi mailing list<br>
Post: <a href="mailto:delphi@delphi.org.nz" target="_blank">delphi@delphi.org.nz</a><br>
Admin: <a href="http://delphi.org.nz/mailman/listinfo/delphi" target="_blank">http://delphi.org.nz/mailman/listinfo/delphi</a><br>
Unsubscribe: send an email to <a href="mailto:delphi-request@delphi.org.nz" target="_blank">delphi-request@delphi.org.nz</a>
with Subject: unsubscribe<br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
NZ Borland Developers Group - Delphi mailing list<br>
Post: <a href="mailto:delphi@listserver.123.net.nz">delphi@listserver.123.net.nz</a><br>
Admin: <a href="http://delphi.org.nz/mailman/listinfo/delphi" target="_blank">http://delphi.org.nz/mailman/listinfo/delphi</a><br>
Unsubscribe: send an email to <a href="mailto:delphi-request@listserver.123.net.nz">delphi-request@listserver.123.net.nz</a> with Subject: unsubscribe<br></blockquote></div><br></div></div>