[DUG] [computing]XE2 string conversion question

[John Bird]

I am tidying up some library stuff for XE2....

Assigning a AnsiChar to Char does not compile in this case below

Background - from what I have read not all variables declared string are 
compiled as string in XE2 - for instance any sized strings as in the record 
below are take to be AnsiString.

(I am also wondering if this applies to Dataset string fields, which are 
often declared with a length)

To save me time in testing and experimenting and googling, which conversions 
do work implicitly by assignment, and which do not?

Anyone who has already been there and done that suggest best practice for 
this case?

type
  TJUFRec = record
    JUFno:integer;
    JUFName:string[20];
    JUFHeds:string[10];
    JUFPrompt:string[30];
    JUFArrNo:integer;
    JUFArrSz:integer;
    JUFType1:string[1];        //<===Ansistring
    JUFNB:integer;
    JUFType2:string[10];
    JUFSB:integer;
    JUFDecpl:integer;
    JUFUpc:integer;
    JUFMin:int64;
    JUFMax:int64;
    JUFReq:integer;
    JUFEdtName: string[25];
    JUFEdit:integer;
    JUFShow:integer;
    JUFRemake:integer;
    JUFDesc:string[60];
  end;

var
lJUFType1:char;

begin
//
  lJUFType1:=aJUFRec.JUFType1[1];        //<======== does not compile

error is [DCC Error]  E2010 Incompatible types: 'Char' and 'AnsiChar'



John Bird
JBCL
Contact:
johnkbird at paradise.net.nz
jbclnz at xtra.co.nz
(027 4844528)
http://www.jbcl.co.nz
http://jbclnz.googlepages.com
-----Original Message----- 
From: Peter Ingham
Sent: Tuesday, January 17, 2012 5:09 PM
To: delphi at listserver.123.net.nz
Subject: Re: [DUG] [computing] Re: D2007 to XE2 conversion notes

On 17/01/2012 1:47 p.m., Jolyon Smith wrote:
>  > On the other hand - it looks like the same test program uses a lot less
>  > memory than the old D2007 version.    The figures vary wildly
> depending on
>
> John, none of the utilities for measuring "memory use" are actually
> reporting truly "used" memory.  The only thing that can do that is some
> utility which can interpret the information in the process heap and work
> out which memory is actually in use by the process and which memory has
> been allocated just in case it may need to be used.

If you are using an OS-level tool to measure memory usage (e.g. Task
Manager, Process Explorer), then you need to know the meaning of the
particular "Memory" figure you are looking at.  Unfortunately many
people don't know what they mean and get confused by the results.

It doesn't help that the default "memory" figure under Windows Task
Manager (a.k.a "Working Set") is usually one of the worst that can be
used by developer (it can be heavily influenced by other processes
running on the system to the point of being meaningless in isolation).

A much better value to use is "Private Virtual Bytes" or "Commit Size".

At the OS memory management level (for a native application), there is
no knowledge of the existence of a heap (or heaps).  Ignoring Virtual
Memory issues,  Memory is either allocated to a process or not.  What
the application (or its run time libraries) do with the memory is of
little interest.  It gets more interesting when we stop ignoring Virtual
Memory issues and the process asks to be allocated memory, but never (or
infrequently) accesses it.  There is unlikely to be any OS level tools
that will tell you anything about the use of Heap memory per se.

As most modern apps do a large number of memory allocation and
deallocation operationg (e.g. Object Create/Destroy, Temp Strings etc) -
and usually for relatively small amounts of memory, it is usual for some
form of internal process memory manager to be used.  Going to the OS
every time for small chunks of memory is very slow.  Most process memory
managers will maintain pools of memory that have been allocated by the
OS, but are not currently being used by anything in the process.


When we know what Memory Manager (or managers) are being used within the
process, then we may be able to come up with more accurate ideas of how
a process is using memory.  In the case of a Java Virtual Machine or a
..Net VM,  there is explicit knowledge of memory usage derived for some
parts of the process when Garbage Collection is done (however for
efficiency, modern GC techniques do not come up with definitive
results).  Some OS level tools understand how to externally query the VM
memory manager inside the process to obtain usage information.

FastMM4 (full version) has API calls available to dump out all memory
blocks allocated by it, so you can compare at a detailed level what is
being used for what (if the FastMM4 debugging options are set you can
get details of what class a block is containing and a stack trace taken
at the time the block was allocated).


Cheers

_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: delphi at listserver.123.net.nz
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to delphi-request at listserver.123.net.nz with 
Subject: unsubscribe