I agree that the introduction of managed data types is inconsistent with
previous Pascal data types. Perhaps it is a design flaw to have changed
the semantics of reference-counted data types. Perhaps not.
Nevertheless, it has been this way for many, many years and will not be
changed at this
At least a file identifier always means the same memory address (where
the record data is stored). If needed (for some special purpose) I *can*
typecast it because I know the address of the data (@myfile). But when
using the identifier of a dynamic array then this identifier does not
always mean
Bihar Anwar schreef:
I've tried to use Move() instead of Copy(). Any objection with the following
code?
Yes, at first glance without much thinking, I don't think it is safe. Did you think
through the consequences of copying reference counted types (ansistring in this case
presumably)?
On Tue, 27 Apr 2010, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
As soon as I get around to some bugfixing, I'll have a look at these.
Shouldn't we create some testsuite for fcl-passrc? (or have a flag in the
existing testsuite to exclude tests from
Michael Van Canneyt schrieb:
On Tue, 27 Apr 2010, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
As soon as I get around to some bugfixing, I'll have a look at these.
Shouldn't we create some testsuite for fcl-passrc? (or have a flag in the
existing
On Wed, 28 Apr 2010, Florian Klaempfl wrote:
Michael Van Canneyt schrieb:
On Tue, 27 Apr 2010, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
As soon as I get around to some bugfixing, I'll have a look at these.
Shouldn't we create some testsuite for
In our previous episode, Anthony Walter said:
Technical limitations aside, at this point what would be needed from the
community to get the generic syntax changed?:
: Patches.
I believe there would first need to be some sort ofg consensus within the
community about the changing the
Jürgen Hestermann wrote:
Where are the usage, internals and purpose of dyn. arrays documented?
I dunno. But I find them incredibly useful.
they have some quirks, and over the years I've been using dynarrays, I've
documented these on my own computer -- I even have a dynamic array test program
In our previous episode, Florian Klaempfl said:
I created a VERY small test sample in utils/fpdoc, it tests 'strange'
cases. It would indeed be a good idea to create a testsuite in
fcl-passrc itself.
Wouldn't it be enough just to let it scan/parse the whole fpc test suite :)?
That's what
On 28 April 2010 04:24, Bihar Anwar bihar_an...@rocketmail.com wrote:
Ok, I'll try to observe the compiled code using debugger and benchmark it if
needed. BTW, what do you mean by allocating memory directly? Is there another
way to allocate memory for dynamic array besides using SetLength()?
On 28 Apr 2010, at 08:05, Jürgen Hestermann wrote:
I am not sure whether this now cast in stone forever. Errors *can*
be corrected sometimes. ;-)
The behaviour of dynamic arrays will not be changed. At best, one day
we may add GPC-compatible array schema types (see
On 28 Apr 2010, at 09:26, Michael Van Canneyt wrote:
Good idea. Are all possible constructs in FPC in the testsuite ?
Probably not, but a lot of them are.
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
Vincent Snijders wrote:
Bihar Anwar schreef:
I've tried to use Move() instead of Copy(). Any objection with the following
code?
Yes, at first glance without much thinking, I don't think it is safe. Did you
think through the consequences of copying reference counted types (ansistring
in
On 28 Apr 2010, at 10:48, Jonas Maebe wrote:
{ now delete one of these elements }
finalise(a[4]);
{ and compact the array }
move(a[3],a[4],(length(a)-3)*sizeof(a[0]));
Well, actually:
move(a[5],a[4],(length(a)-5)*sizeof(a[0]));
Jonas
___
On 28 April 2010 05:33, Bihar Anwar bihar_an...@rocketmail.com wrote:
I've tried to use Move() instead of Copy(). Any objection with the following
code?
var
a: array of string;
SetLength(a, 5);
a[0] := 'aa'; a[1] := 'bb'; a[2] := 'cc'; a[3] := 'dd'; a[4] := 'ee';
System.Move(a[3],
The funny thing is I have already read that wiki page, but did not
recognize it in your description.
When I added 'pascal' to the Google search, then it turned up on the
first page..
FreePascal users ought to blog some more. ;-)
On 27 April 2010 19:47, Luiz Americo Pereira Camara
Hello,
It seems that once a pointer has been assigned nil, it needs to be
(re)allocated using new() before using it to (re)set its target:
...
p := nil; // pointer to Integer
...
new(p) ; p^ := 1;
Is this hypothesis correct?
Use case: Linked List
nil is used in the toNext field of a
On 28 Apr 2010, at 13:11, spir ☣ wrote:
It seems that once a pointer has been assigned nil, it needs to be
(re)allocated using new() before using it to (re)set its target:
You might want to read some tutorials on pointers before continuing
you experiments. See e.g.:
*
Hi, you all.
At current TMaks.Matches does a case insensitive matching of a
filename against a given mask(list).
Currently this comparison is case insensitive ('ABC.doc' matches the
mask 'abc*').
This is OK for Windows/DOS environments, but it will not do for case
sensitive operating systems (or
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
Thank you very much Henry, David, and Vincent. I think, I must go back to the
basic of reference counting. Special thanks to David for the detail explanation.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
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',
22 matches
Mail list logo
