Jürgen Hestermann | 1 May 2010 11:09
Picon
Picon

Re: dynamic array contents and system.move

> At best, one day we may add GPC-compatible array schema types (see 
> http://www.gnu-pascal.de/gpc/Schema-Types.html, the part under "As a GNU 
> Pascal extension, the above can also be written as"). These don't hide 
> anything.

Yes, that looks good as it does not violate the rule that an identifier 
should mean the same memory address independent from context.

>> A simple solution would be to use the address the pointer is pointing 
>> to (address of first element) for fillchar/move too.
> It would break code like this:
> type  tbytedynarr = array of byte;
> var   a: array of tbytedynarr;
> begin
> setlength(a,10);
> { initialise all dynamic array elements of a}
>   ...
> { now delete one of these elements }
> finalise(a[4]);
> { and compact the array }
> move(a[3],a[4],(length(a)-3)*sizeof(a[0]));
> end.
> With your change, move() would operate on the contents of a[3] 
> tbytedynarr instead of on the contents of "a" itself.

Yes, that's a problem because a[0] and a[0]^ are not distinguishable. 
Although I would have expected that special procedures exist to insert
and remove array elements so that there is no need to do such things 
manually which also requires knowledge of the exact handling of dynamic 
arrays which is not fully documented so you are never sure.
(Continue reading)

Jonas Maebe | 1 May 2010 16:54
Picon
Favicon

Re: dynamic array contents and system.move


On 01 May 2010, at 11:09, Jürgen Hestermann wrote:

> Yes, that looks good as it does not violate the rule that an identifier should mean the same memory address
independent from context.

As has been explained umpteen times already in this thread: a dynamic array identifier always identifies
exactly the same memory address (namely the address of the pointer to the array). It's the "[]" operator
that has been overloaded for dynamic arrays to basically mean "^[]", similarly to how
a) it behaves for pchars
b) "." for classes means "^." (and also for pointers to records in Delphi mode)

And no, the syntax for dynamic arrays will not be changed nor extended (unless Embarcadero would do so).

This is my final post in this thread.

Jonas_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

spir ☣ | 1 May 2010 18:43
Picon
Gravatar

Re: method order

On Fri, 30 Apr 2010 19:17:51 +0200
Mattias Gaertner <nc-gaertnma@...> wrote:

> Maybe you don't know 'forward'?

Thank you!

Denis
________________________________

vit esse estrany ☣

spir.wikidot.com
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

David Emerson | 1 May 2010 22:13

Re: dynamic array contents and system.move

Jürgen Hestermann wrote:
> Although I would have expected that special procedures exist to insert
> and remove array elements so that there is no need to do such things 
> manually ...

These must be written on a case-by-case basis, for each type of array element. 
Perhaps I'll tackle this someday as my first contribution to the fpc codebase.

As for the rest, I have addressed these very issues in the last week...

> ... which also requires knowledge of the exact handling of dynamic  
> arrays which is not fully documented so you are never sure.

See my test program, http://david9.freepgs.com/fpc/dynamic-arrays.pas
also: http://lists.freepascal.org/lists/fpc-pascal/2010-April/024840.html

You can figure out how all this stuff works relatively easily -- if it is so 
important to you to be able to use system.move on dynamic array contents.

> For example, in the above example, a[10] still exists and 
> points to the same data as a[9], correct? And how do I *insert* elements?
> I would need to extend the allocated memory but how to do that without 
> distroying reference counters etc.?

http://lists.freepascal.org/lists/fpc-pascal/2010-April/024845.html

Of course you need to use setlength to extend allocated memory.

Cheers,
David
(Continue reading)

| 2 May 2010 07:31
Favicon

Is there anyone will answer my questions

Dear FreePascal,
  

 I have some questions when I am using Free Pascal
 >> firstly , I find that I Can't use hot-key "Ctrl+N" to add
     a new line in the IDE.
  and I think the Free Pascal's ide is not very stable,
  I am using fpc under a MS-DOS 7.1, sometimes when I am editing
  my sourse code(I chosed Microsoft Convention (Ctrl+X,Ctrl+V,Ctrl+C) )
  if I pressed Ctrl+C
  
sometimes the ide will terminate and said like this:
  "  The ide is terminated , save your soure code and restart the ide"
  
And sometimes if I use Alt+F and Commend Shell
  the ide is still in my sight . Maybe it is because "Out of Memory"?
 

>> secondly, if I want to debug my program when I use "step over  F8"
   the ide will display the user screen when I press F8. It is not the
   same as Turbo Pascal. I really dislike it ,but I don't know what to
   do.


 >> Tirdly, once I was programming a program (the source code is below)
  when I input about 100 data the program occured a error ,then it
  terminated. I don't why ,and I can't understand the Error Code it gives
  to me.Can you find my error and fix it for me? 

      {=======    The source code is below  ======= }
(Continue reading)

Bihar Anwar | 2 May 2010 07:59
Picon
Favicon

Is this a reference counting bug?

I found that the last element of a dynamic array starts with reference count = 2 in FPC, but in Delphi is 1. Is
this an FPC bug, or FPC implements reference counting differ from Delphi?

type
  PAnsiRec = ^TAnsiRec;
  TAnsiRec = packed Record
    Ref,
    Len   : SizeInt;
    First : Char;
  end;

const
  AnsiRecLen = SizeOf(TAnsiRec);
  FirstOff   = SizeOf(TAnsiRec) - SizeOf(Char);

procedure Test;
var
  a: array of ansistring;

begin
  SetLength(a, 5);
  a[0] := IntToStr(0);
  a[1] := IntToStr(1);
  a[2] := IntToStr(2);
  a[3] := IntToStr(3);
  a[4] := IntToStr(4);

  WriteLn('a[0] = ', PAnsiRec(Pointer(a[0]) - FirstOff)^.Ref);  // Ref Count = 1
  WriteLn('a[1] = ', PAnsiRec(Pointer(a[1]) - FirstOff)^.Ref);  // Ref Count = 1
  WriteLn('a[2] = ', PAnsiRec(Pointer(a[2]) - FirstOff)^.Ref);  // Ref Count = 1
(Continue reading)

David Emerson | 2 May 2010 08:27

Re: IDE and programming woes

First, a descriptive subject header is much appreciated.

As for your IDE troubles, I don't know how many people actually use that old 
FreeVision-based IDE... many of us use either Lazarus or some other more modern 
editor. Is there some reason you can't or don't want to try Lazarus?

>  Tirdly, once I was programming a program (the source code is below)

good of you to include the source!

>   when I input about 100 data the program occured a error ,then it
>   terminated. I don't why ,and I can't understand the Error Code it gives
>   to me.Can you find my error and fix it for me? 

I can't imagine how we could help you without the errors.

The data would definitely be useful too. Lacking that, we can't reproduce the 
error. The error might even be in your data, which would make it impossible for 
anyone to detect by just looking at your source.

Cheers,
David

_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Frank Church | 2 May 2010 08:59

Re: XML Iteration

I am having some problems with XPath.

EvaluateXPathExpression raises exceptions with some search strings and I am not sure if it is my limited knowledge of XPath, or a buggy XPath implementation.

The attached demo uses the example from http://www.w3schools.com/xpath/xpath_examples.asp and I am running 0.9.28.2 beta on Windows


On 29 April 2010 03:08, Luiz Americo Pereira Camara <luizmed-qJvVNIR2imNQFI55V6+gNQ@public.gmane.org> wrote:
Lee Jenkins escreveu:

Luiz Americo Pereira Camara wrote:
Frank Church escreveu:
I am glad to see someone with an interest in FPCs XML. Do you have
some experience with XPath usage in PFC/Lazarus?

 


Luiz,

In Unit1.pas:

XPathResult := EvaluateXPathExpression('//Descricao', XmlTree.DocumentElement);
 if (XPathResult <> nil) then
 begin
   for i := 0 to XPathResult.AsNodeSet.Count - 1 do
   begin
     Node := TDOMNode(XPathResult.AsNodeSet[i]);
     if Node.FirstChild <> nil then
       Memo1.Lines.Add(UTF8Encode(Node.FirstChild.NodeValue));
   end;
   XPathResult.Destroy;
 end;
 XmlTree.Free;


Why the call to XPathResult.Destroy ?  Is it for reference counting?  Just seems something else to remember (use destroy instead of free)...

No special reason.

Free is redundant in this case since i already knows that XPathResult <> nil

Luiz



Thanks

--
Warm Regards,

Lee
_______________________________________________
fpc-pascal maillist  -  fpc-pascal-PD4FTy7X32k2wBtHl531yWD2FQJk+8+b@public.gmane.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal



_______________________________________________
fpc-pascal maillist  -  fpc-pascal-PD4FTy7X32k2wBtHl531yWD2FQJk+8+b@public.gmane.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal



--
Frank Church

=======================
http://devblog.brahmancreations.com
Attachment (prjXPath.zip): application/zip, 3102 bytes
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Florian Klaempfl | 2 May 2010 09:50
Favicon

Re: Is this a reference counting bug?

Bihar Anwar schrieb:
> I found that the last element of a dynamic array starts with
> reference count = 2 in FPC, but in Delphi is 1. Is this an FPC bug,
> or FPC implements reference counting differ from Delphi?

FPC and Delphi handle code generation for ref. counted types slightly
different, so there might be cases where the ref. counter differs. As
long as there is no memory leak when the vars are properly used, we
don't consider it as a bug.
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Bihar Anwar | 2 May 2010 10:30
Picon
Favicon

Re: Is this a reference counting bug?

Florian Klaempfl:

> FPC and Delphi handle code generation for ref. counted types slightly
> different, so there might be cases where the ref. counter differs. As
> long as 
there is no memory leak when the vars are properly used, we
> don't 
consider it as a bug.

I see, well, there should be explanation about this in FPC doc.

      
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal


Gmane