[fpc-pascal] Exporting user-defined conditionals
Hi, According to the note in chapter 2, section 2.2.1 of the FPC Programmer's Guide, it is not possible for conditionals to be exported to other units. Is there a way around this? My Ref: Programmer's Guide for Free Pascal, Version 2.2.2 Document version 2.0 June 2008 Regards, Nino ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] How to Copy a Record data to a buffer?
TCommsBuffer = packed record
UnitID: Byte;
FunctionCode: TModBusFunction;
MBPData: TModBusDataBuffer;
Spare: Byte;
end; { TCommsBuffer }
SendBuffer: TCommsBuffer;
--
I want to send the data in SendBuffer to serial port
I define a array type:
rcvData:TDataByte;(TDataByte = array of byte)
setlength(rcvData, sizeof(SendBuffer ) );
count := datatosend;
CopyMemory( @rcvData, @ SendBuffer , count);
SeriComm.SendBuffer(@rcvData,count);
when run to "CopyMemory( @rcvData, @ SendBuffer , count);" the program crash,
what's wrong with me? Thanks.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to Copy a Record data to a buffer?
Hi,
either use "Move( SendBuffer, rcvData, count )" (recommended since its
from rtl, not windows api) or
"CopyMemory( @rcvData[0], @SendBuffer, count )".
Its a common mistake to use @ instead of @[ 0 ].
regards
On Sat, Oct 10, 2009 at 11:51 AM, yu ping wrote:
> TCommsBuffer = packed record
> UnitID: Byte;
> FunctionCode: TModBusFunction;
> MBPData: TModBusDataBuffer;
> Spare: Byte;
> end; { TCommsBuffer }
>
>
> SendBuffer: TCommsBuffer;
>
> --
> I want to send the data in SendBuffer to serial port
> I define a array type:
>
> rcvData:TDataByte;(TDataByte = array of byte)
> setlength(rcvData, sizeof(SendBuffer ) );
> count := datatosend;
> CopyMemory( @rcvData, @ SendBuffer , count);
> SeriComm.SendBuffer(@rcvData,count);
>
> when run to "CopyMemory( @rcvData, @ SendBuffer , count);" the program crash,
> what's wrong with me? Thanks.
> ___
> fpc-pascal maillist - fpc-pas...@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to Copy a Record data to a buffer?
Hi, For the Move solution, use "Move( SendBuffer, rcvData[0], count )".. Same common mistake with [0]. sry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to Copy a Record data to a buffer?
Solved,Thanks there is another mistake: FillChar(sendData, high(sendData), 0); change to FillChar(sendData[0], high(sendData), 0); OK. 2009/10/10 Matthias K. : > Hi, > For the Move solution, use "Move( SendBuffer, rcvData[0], count )".. > Same common mistake with [0]. > > sry > ___ > fpc-pascal maillist - fpc-pas...@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
Its a common mistake to use @ instead of @[ 0 ].
IMO this happens because of an illogical design flaw (which seems to be
introduced by Borland). If I have a variable that is a *pointer* to an
array then why is it possible to use the square brackets to use it as if
it was an array? The derefencing symbol ^ should be needed here (X^[1]
instead of X[1]). It's the same for PCHAR. It is a pointer and there
should not be any automatic derefencing. That obscures the type origin
and is not in the spirit of Pascal. And it leads to the mistakes
mentioned above. It is C-like style ("the compiler will guess what you
meant") which should never have crept into Pascal. If you build a
complex data structure with nested pointers and arrays you get into hell
with this automatic dereferencing.
Well, it is now much too late to change this but it annoys me all the time.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
2009/10/10 Jürgen Hestermann :
>> Its a common mistake to use @ instead of @> array var>[ 0 ].
>
> IMO this happens because of an illogical design flaw (which seems to be
> introduced by Borland). If I have a variable that is a *pointer* to an array
> then why is it possible to use the square brackets to use it as if it was
> an array? The derefencing symbol ^ should be needed here (X^[1] instead of
> X[1]). It's the same for PCHAR. It is a pointer and there should not be any
> automatic derefencing. That obscures the type origin and is not in the
> spirit of Pascal. And it leads to the mistakes mentioned above. It is C-like
> style ("the compiler will guess what you meant") which should never have
> crept into Pascal. If you build a complex data structure with nested
> pointers and arrays you get into hell with this automatic dereferencing.
This behaviour comes from C syntax. The array is a pointer, which you
dereference by using the square brackets. This is well defined
syntax, nothing automatic or illogical about it. The only reason
pascal programmers make mistakes with this is because they are less
accustomed to using pointers.
Henry
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
This behaviour comes from C syntax. The array is a pointer, which you
dereference by using the square brackets. This is well defined
syntax, nothing automatic or illogical about it. The only reason
pascal programmers make mistakes with this is because they are less
accustomed to using pointers.
It is illogical that I am able to enumerate a pointer as if it was an
array. So the brackets do the dereferencing automatically. When I write
X[1] it assumes I meant X^[1]. To the user it behaves the same as if X
was an array instead of a pointer to an array. There is no difference in
syntax which is wrong IMO. It's not wonder that many users think it *is*
an array.
That's the same as if I could use square brackets for an integer and the
compiler assumes I meant to pick up one of the bytes. Strict type
checking was a fundamental goal of Pascal but is has now been weakended
by C-style creaping into it. If you are forced to use the first element
of an array in situatons where you wanted to specify the whole array it
is illogical. And it's not that pascal programmers are less accustomed
to pointers, but they are less accustomed to obscure compiler magic. It
has become fashionable to *hide* such things ("you don't need to know
the details") and the syntax doesn't tell the users either which
provokes such mistakes.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
2009/10/10 Jürgen Hestermann :
>
> It is illogical that I am able to enumerate a pointer as if it was an array.
> So the brackets do the dereferencing automatically. When I write X[1] it
> assumes I meant X^[1]. To the user it behaves the same as if X was an array
> instead of a pointer to an array. There is no difference in syntax which is
> wrong IMO. It's not wonder that many users think it *is* an array.
I can't understand what you are trying to say. An array is a pointer
to where the elements of the array resides in memory. How else do you
think it works? Can you explain what would x[1] mean if it isn't
dereferenced?
>
> That's the same as if I could use square brackets for an integer and the
> compiler assumes I meant to pick up one of the bytes. Strict type checking
> was a fundamental goal of Pascal but is has now been weakended by C-style
> creaping into it. If you are forced to use the first element of an array in
> situatons where you wanted to specify the whole array it is illogical. And
> it's not that pascal programmers are less accustomed to pointers, but they
> are less accustomed to obscure compiler magic. It has become fashionable to
> *hide* such things ("you don't need to know the details") and the syntax
> doesn't tell the users either which provokes such mistakes.
No, it's not weakened by C-style all of a sudden, it's _always_ been
like this. As I've been trying to explain to you, there's no "obscure
compiler magic", if you put the brackets there, the compiler
dereferences.
Henry
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
2009/10/10 Jürgen Hestermann : > > It is illogical that I am able to enumerate a pointer as if it was an array. > So the brackets do the dereferencing automatically. When I write X[1] it > assumes I meant X^[1]. To the user it behaves the same as if X was an array > instead of a pointer to an array. There is no difference in syntax which is > wrong IMO. It's not wonder that many users think it *is* an array. I have to agree 100%. This is what through me off a few days ago as well. Plus I haven't used pointers and pointers to array structures in many years. But yes, the syntax is inconsistent with other syntax rules. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
2009/10/10 Jürgen Hestermann : > > It is illogical that I am able to enumerate a pointer as if it was an array. > So the brackets do the dereferencing automatically. When I write X[1] it > assumes I meant X^[1]. To the user it behaves the same as if X was an array > instead of a pointer to an array. There is no difference in syntax which is > wrong IMO. It's not wonder that many users think it *is* an array. One thing I think you don't understand is that an array _is_ a pointer. Look at this table to visualise: http://en.wikipedia.org/wiki/C_syntax#Accessing_elements Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
In our previous episode, Henry Vermaak said: [ Charset ISO-8859-1 unsupported, converting... ] > 2009/10/10 J?rgen Hestermann : > > > > It is illogical that I am able to enumerate a pointer as if it was an array. > > So the brackets do the dereferencing automatically. When I write X[1] it > > assumes I meant X^[1]. To the user it behaves the same as if X was an array > > instead of a pointer to an array. There is no difference in syntax which is > > wrong IMO. It's not wonder that many users think it *is* an array. > > One thing I think you don't understand is that an array _is_ a > pointer. Look at this table to visualise: > http://en.wikipedia.org/wiki/C_syntax#Accessing_elements That link is talking about interchangability, which is not the same as being the same. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
2009/10/10 Marco van de Voort : >> http://en.wikipedia.org/wiki/C_syntax#Accessing_elements > > That link is talking about interchangability, which is not the same as being > the same. Yes, I'm just trying to explain that there's no magic to it, illustrated by some basic pointer arithmetic. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
In our previous episode, Henry Vermaak said:
> >
> > That link is talking about interchangability, which is not the same as being
> > the same.
>
> Yes, I'm just trying to explain that there's no magic to it,
> illustrated by some basic pointer arithmetic.
I think there are several bits that mix in this thread:
1 nearly all types that don't fit in registers are in memory, and you need
a memory access to reference them. This makes them all
references/pointers/addresses on assembler level, but not necessary pointers
on language level.
2 The fact that Delphi mandatory skips a ^ when indexing a pointer + array.
3 The fact that FPC allows both in objfpc mode. (which means)
4 The fact that FPC and Delphi allow pchar to be overindexed.
5 The fact that FPC and Delphi 2009+ with {$pointermath on} also allow it
for other pointer types.
Note that I write this from memory after porting some FPC bits to Delphi
last week. Most notably the {$pointermath on} (5) and the mandatory aspect
of (2) might be related.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
Also, it is very important to make distinction between static and
dynamic arrays. For static arrays, compiler knows their exact memory
location at compile time (modulo situations where static array is part
of another structure), but for dynamic arrays, compiler only knows
where in memory is reference (akka pointer) to the contents of that
array. So, if we wanted to have that distinction on syntax level, we
would have to use X[1] for static arrays and X^[1] for dynamic arrays.
Doesn't sound nice, does it?
On Sat, Oct 10, 2009 at 15:32, Marco van de Voort wrote:
> In our previous episode, Henry Vermaak said:
>> >
>> > That link is talking about interchangability, which is not the same as
>> > being
>> > the same.
>>
>> Yes, I'm just trying to explain that there's no magic to it,
>> illustrated by some basic pointer arithmetic.
>
> I think there are several bits that mix in this thread:
>
> 1 nearly all types that don't fit in registers are in memory, and you need
> a memory access to reference them. This makes them all
> references/pointers/addresses on assembler level, but not necessary pointers
> on language level.
> 2 The fact that Delphi mandatory skips a ^ when indexing a pointer + array.
> 3 The fact that FPC allows both in objfpc mode. (which means)
> 4 The fact that FPC and Delphi allow pchar to be overindexed.
> 5 The fact that FPC and Delphi 2009+ with {$pointermath on} also allow it
> for other pointer types.
>
> Note that I write this from memory after porting some FPC bits to Delphi
> last week. Most notably the {$pointermath on} (5) and the mandatory aspect
> of (2) might be related.
> ___
> fpc-pascal maillist - fpc-pas...@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>
--
Aleksa Todorovic - Lead Programmer
Eipix Entertainment
http://www.eipix.com/
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
Henry Vermaak wrote: One thing I think you don't understand is that an array _is_ a pointer. Look at this table to visualise: In Pascal, an array is not a pointer; at least not at the language level. For a static array X (array[1..n] of T), you *can* write: Move(Ptr^, X, sizeof(X)); because X *is* the array, representing the memory of the array. Micha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
I can't understand what you are trying to say. An array is a pointer to where the elements of the array resides in memory. How else do you think it works? just look at: type ArrayType = array[1..10] of char; var X : ArrayType; PX : ^ArrayType What is the difference between X and PX? X is an array of char which can be accessed directly. The identifier X means the address in memory where the array elements 1..10 are stored. The address of X (@X) is the address of the array (first element). XP is just a pointer to such a structure. It's not the array itself. The address of XP (@XP) is the address of the pointer, not the array. Sizeof(X) is 10 bytes. Sizeof(PX) is 4 bytes. Still you can use X[1] and PX[1]. That's illogical. No, it's not weakened by C-style all of a sudden, it's _always_ been like this. It has never been like this (in Pascal). That's C-style. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
Also, it is very important to make distinction between static and dynamic arrays. For static arrays, compiler knows their exact memory location at compile time (modulo situations where static array is part of another structure), but for dynamic arrays, compiler only knows where in memory is reference (akka pointer) to the contents of that array. So, if we wanted to have that distinction on syntax level, we would have to use X[1] for static arrays and X^[1] for dynamic arrays. Exactly! Doesn't sound nice, does it? To me it does, much more as it's now. It would make it clear what kind of data structure I am working with. What is not nice with it? Now all these facts are obscured by some background compiler magic and misinterpretations are generated. Imagine a highly nested structure of pointers to arrays of pointers to arrays of pointers. If you try to write code to access the data you will soon get lost what to write if you mean some of the arrays or mean the pointers. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Exporting user-defined conditionals
You can use include files On Sat 10 Oct 2009, fpcl...@silvermono.co.za wrote: > Hi, > > According to the note in chapter 2, section 2.2.1 of the FPC Programmer's > Guide, it is not possible for conditionals to be exported to other units. > > Is there a way around this? > > My Ref: > Programmer's Guide for Free Pascal, Version 2.2.2 > Document version 2.0 > June 2008 > > Regards, > Nino > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
2009/10/10 Jürgen Hestermann : >> I can't understand what you are trying to say. An array is a pointer >> to where the elements of the array resides in memory. How else do you >> think it works? > > just look at: > > type ArrayType = array[1..10] of char; > var X : ArrayType; > PX : ^ArrayType > > What is the difference between X and PX? > > X is an array of char which can be accessed directly. The identifier X means > the address in memory where the array elements 1..10 are stored. The address > of X (@X) is the address of the array (first element). > > XP is just a pointer to such a structure. It's not the array itself. The > address of XP (@XP) is the address of the pointer, not the array. > > Sizeof(X) is 10 bytes. > Sizeof(PX) is 4 bytes. > > Still you can use X[1] and PX[1]. That's illogical. Right, I see what you mean, now. Contrary to what I thought arrays are not pointers (in syntax, at least), this is indeed confusing. I hardly ever use pointer arithmetic in pascal, though, so it doesn't really bother me. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] two small ?s - high(real) and nearest 2^x
1. Is there a way to get the highest and lowest real values? I can do high(longint) but high(real) gives me an error. Also of interest is a low(real) value (-m * 10^n) as distinct from the smallest real value (m * 10^-n) 2. For the purposes of reserving memory in block sizes that can be easily reallocated, I like to use powers of two. So if I have, e.g., a dynamic array, I might start with a size of 1024 and then double it when it hits capacity. Hopefully this smoothes memory management, as I am using a lot of memory... Anyway, what I'd like is a simple function that can quickly identify the next power-of-two larger than an arbitrary number. So if I feed the function 472, it will return 512. Thus far I haven't been able to figure out how to do this without a big if-then-else nest. Is there some clever way to request that the processor return the position of the leftmost '1' in 00101101? Thanks! ~David. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] two small ?s - high(real) and nearest 2^x
2. For the purposes of reserving memory in block sizes that can be easily reallocated, I like to use powers of two. So if I have, e.g., a dynamic array, I might start with a size of 1024 and then double it when it hits capacity. Hopefully this smoothes memory management, as I am using a lot of memory... I have done this too. I maintain 2 values, one for the *allocated* memory and one for the *used*. This way I don't need to reallocate unless I hit the border. If this happens, I simply allocate a new chunk of memory of double size (which is then again a power of 2) and move(copy) the data to the new memory. This way I don't have to reallocate very often because the additional memory increases by a factor of 2 which makes it less propably for large numbers of bytes. Is there some clever way to request that the processor return the position of the leftmost '1' in 00101101? The only way I can think of is a shr (or shl) loop which should run as often as number of bits exist in the worst case; i := 0; while x<>0 do begin x := x shr 1; inc(i); end; if i<>0 then x := 1 shl i else error if X=0 then overflow; ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] two small ?s - high(real) and nearest 2^x
On Sat, 2009-10-10 at 10:14 -0700, David Emerson wrote: > 2. For the purposes of reserving memory in block sizes that can be > easily reallocated, I like to use powers of two. So if I have, e.g., a > dynamic array, I might start with a size of 1024 and then double it > when it hits capacity. Hopefully this smoothes memory management, as I > am using a lot of memory... > > Anyway, what I'd like is a simple function that can quickly identify the > next power-of-two larger than an arbitrary number. So if I feed the > function 472, it will return 512. Thus far I haven't been able to > figure out how to do this without a big if-then-else nest. Is there > some clever way to request that the processor return the position of > the leftmost '1' in 00101101? On the processor level, if it is an x86, you can use "bsr" (bit scan reverse). Other processors may have similar instructions. I don't know if this is somehow mapped to an RTL function. In pure pascal, use a loop to determine the magnitude, something like (omitting the details): repeat requested := requested shr 1; inc(magnitude); until requested=0; Anton ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
Henry Vermaak > I can't understand what you are trying to say. An array is a pointer > to where the elements of the array resides in memory. No, not in Pascal. In Pascal an array is a variable just like any other: A name for some memory area where values can be stored. > How else do you think it works? Just like "a : integer" -> reserve the needed number of bytes and let the programmer access the associated memory via the identifier "a". > Can you explain what would x[1] mean if it isn't dereferenced? Access the memory at address of "x + 1 * (size of element)". Just like you do array4 : record a1, a2, a3, a4 end; and access the record members respectively. It's a static address, known at compile time. No dereferencing. > No, it's not weakened by C-style all of a sudden, it's _always_ been > like this. No. Your confusing arrays and pointers. Or maybe, you're confusing Pascal and C. > As I've been trying to explain to you, there's no "obscure > compiler magic", if you put the brackets there, the compiler > dereferences. The dereferencing operator in Pascal is "^". Vinzent. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
Henry Vermaak : > One thing I think you don't understand is that an array _is_ a > pointer. Look at this table to visualise: > > http://en.wikipedia.org/wiki/C_syntax#Accessing_elements One thing I think you don't understand is that arrays and pointers are orthogonal concepts in almost every other programming language than C. So technically, C is the one who got it wrong. Same for "Array subscript numbering begins at 0." - which simply isn't true for Pascal. Vinzent. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
In our previous episode, "Vinzent H?fler" said: > > One thing I think you don't understand is that an array _is_ a > > pointer. Look at this table to visualise: > > > > http://en.wikipedia.org/wiki/C_syntax#Accessing_elements > > One thing I think you don't understand is that arrays and pointers are > orthogonal concepts in almost every other programming language than C. > > So technically, C is the one who got it wrong. Wrong and right are absolute terms. C chose a deliberate other way, mostly based on the need to keep as little possible state in memory to be able to compile an as large program as possible on early seventies hardware. So from C's THEN requirements, it was sane. C has to live with the both the advantage (looking at the huge unix codebase) and the disadvantage (the sorry state of typing and importing) of being a production language right from the start. > Same for "Array subscript numbering begins at 0." - which simply isn't > true for Pascal. Except for dyn arrays, open arrays etc. See ISO pascal's conforming arrays. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
2009/10/10 "Vinzent Höfler" : > Henry Vermaak > >> I can't understand what you are trying to say. An array is a pointer >> to where the elements of the array resides in memory. > > No, not in Pascal. In Pascal an array is a variable just like any other: A > name for some memory area where values can be stored. > >> How else do you think it works? > > Just like "a : integer" -> reserve the needed number of bytes and let the > programmer access the associated memory via the identifier "a". > >> Can you explain what would x[1] mean if it isn't dereferenced? > > Access the memory at address of "x + 1 * (size of element)". > > Just like you do > > array4 : record a1, a2, a3, a4 end; > > and access the record members respectively. It's a static address, known at > compile time. No dereferencing. > >> No, it's not weakened by C-style all of a sudden, it's _always_ been >> like this. > > No. Your confusing arrays and pointers. Or maybe, you're confusing Pascal and > C. Thanks for the explanation, I was under the impression that arrays in Pascal were similar to C. How do you explain the "automatic" dereferencing with a pointer to an array that Jürgen is talking about? Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
In our previous episode, Henry Vermaak said: > > and access the record members respectively. It's a static address, known at > > compile time. No dereferencing. > > > >> No, it's not weakened by C-style all of a sudden, it's _always_ been > >> like this. > > > > No. Your confusing arrays and pointers. Or maybe, you're confusing Pascal > > and C. > > Thanks for the explanation, I was under the impression that arrays in > Pascal were similar to C. How do you explain the "automatic" > dereferencing with a pointer to an array that J?rgen is talking about? This is an extension of Borland dialects, of a much later period, where OS apis and examples are specified at C level. Other such examples are enums with gaps, the ability to have fieldnames with the same name as types etc. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Illogical automatic dereferencing
2009/10/10 "Vinzent Höfler" : > Henry Vermaak : > >> One thing I think you don't understand is that an array _is_ a >> pointer. Look at this table to visualise: >> >> http://en.wikipedia.org/wiki/C_syntax#Accessing_elements > > One thing I think you don't understand is that arrays and pointers are > orthogonal concepts in almost every > other programming language than C. Yes, I am aware of this (at least with the languages I've worked with). > > So technically, C is the one who got it wrong. Huh? Are you saying something is wrong because the majority does it differently? > > Same for "Array subscript numbering begins at 0." - which simply isn't true > for Pascal. Except when you define an array[0..9], for instance, or for dynamic arrays. I can think of only strings that always start with [1], but I'm often mistaken :) Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] two small ?s - high(real) and nearest 2^x
On Sat, Oct 10, 2009 at 7:14 PM, David Emerson wrote: > 1. Is there a way to get the highest and lowest real values? I can do > high(longint) but high(real) gives me an error. Also of interest is a > low(real) value (-m * 10^n) as distinct from the smallest real value > (m * 10^-n) As stated in the Documentation: http://www.freepascal.org/docs-html/ref/refsu6.html The Real Type is Plattform dependend and either Single or Double. And since its IEEE Floating Point Representation, Low = -High (just a difference in sign bit) You can find Max/Min Single/Double in unit math. Sample: -- uses math; ... WriteLn( 'Size: ', SizeOf(Real) ); if SizeOf(Real)>=8 then begin WriteLn( 'Low: ', -MaxDouble ); WriteLn( 'High: ', MaxDouble ); end else begin WriteLn( 'Low: ', -MaxSingle ); WriteLn( 'High: ', MaxSingle ); end; -- > 2. For the purposes of reserving memory in block sizes that can be > easily reallocated, I like to use powers of two. So if I have, e.g., a > dynamic array, I might start with a size of 1024 and then double it > when it hits capacity. Hopefully this smoothes memory management, as I > am using a lot of memory... > > Anyway, what I'd like is a simple function that can quickly identify the > next power-of-two larger than an arbitrary number. So if I feed the > function 472, it will return 512. Thus far I haven't been able to > figure out how to do this without a big if-then-else nest. Is there > some clever way to request that the processor return the position of > the leftmost '1' in 00101101? invalue := 412; -- outvalue := 1; while invalue <> 0 do begin invalue := invalue div 2; outvalue := outvalue*2; end; -- BUT.. this "allocation algorithm" may be good in theory (amortized performance for reallocation), but youre losing a lot of memory because of prereservation.. just for the records ;) regards, Matthias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] two small ?s - high(real) and nearest 2^x
On Sat, Oct 10, 2009 at 20:58, Matthias K. wrote: > On Sat, Oct 10, 2009 at 7:14 PM, David Emerson wrote: >> 2. For the purposes of reserving memory in block sizes that can be >> easily reallocated, I like to use powers of two. So if I have, e.g., a >> dynamic array, I might start with a size of 1024 and then double it >> when it hits capacity. Hopefully this smoothes memory management, as I >> am using a lot of memory... >> >> Anyway, what I'd like is a simple function that can quickly identify the >> next power-of-two larger than an arbitrary number. So if I feed the >> function 472, it will return 512. Thus far I haven't been able to >> figure out how to do this without a big if-then-else nest. Is there >> some clever way to request that the processor return the position of >> the leftmost '1' in 00101101? > > invalue := 412; > -- > outvalue := 1; > while invalue <> 0 do > begin > invalue := invalue div 2; > outvalue := outvalue*2; > end; > -- On x86 processors, there is bsr instruction which finds index of the most significant bit set. You just need some simple asm coding to use it. > regards, > Matthias > ___ > fpc-pascal maillist - fpc-pas...@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > -- Aleksa Todorovic - Lead Programmer Eipix Entertainment http://www.eipix.com/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] two small ?s - high(real) and nearest 2^x
On Sat, Oct 10, 2009 at 9:09 PM, Aleksa Todorovic wrote: > On Sat, Oct 10, 2009 at 20:58, Matthias K. wrote: >> On Sat, Oct 10, 2009 at 7:14 PM, David Emerson wrote: >>> 2. For the purposes of reserving memory in block sizes that can be >>> easily reallocated, I like to use powers of two. So if I have, e.g., a >>> dynamic array, I might start with a size of 1024 and then double it >>> when it hits capacity. Hopefully this smoothes memory management, as I >>> am using a lot of memory... >>> >>> Anyway, what I'd like is a simple function that can quickly identify the >>> next power-of-two larger than an arbitrary number. So if I feed the >>> function 472, it will return 512. Thus far I haven't been able to >>> figure out how to do this without a big if-then-else nest. Is there >>> some clever way to request that the processor return the position of >>> the leftmost '1' in 00101101? >> >> invalue := 412; >> -- >> outvalue := 1; >> while invalue <> 0 do >> begin >> invalue := invalue div 2; >> outvalue := outvalue*2; >> end; >> -- > > On x86 processors, there is bsr instruction which finds index of the > most significant bit set. You just need some simple asm coding to use > it. > Yes, the same thing can be written with 3 instructions (bsr, inc, shl) for x86, but... 1. the code above is crossplattform compatible 2. with some size checks it can be assured, this code is only called if "current arraysize < new array size". So with a starting size of 1024 = 2^10, you need to call this code at most 22 times to grow a (4*SizeOf(array Element Type))GB array 3. the 22 times reallocation overhead is significant less performant.. so its a simple solution with benefits in compatibility ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Broken PIC support in FPC 2.2.4
Hello! Because PIC-Support is broken in FPC 2.2.4, I cannot build shared libraries at time. ( See http://bugs.freepascal.org/view.php?id=12492 ) Unfortunately it is not possible for me to switch to the development version of FPC, FPC 2.3.0. So, is there a patch for FPC 2.2.4 available to fix PIC? When does FPC 2.4.0 will be released? Thanks! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Broken PIC support in FPC 2.2.4t
In our previous episode, Matthias Klumpp said: > Because PIC-Support is broken in FPC 2.2.4, I cannot build shared libraries > at time. ( See http://bugs.freepascal.org/view.php?id=12492 ) > Unfortunately it is not possible for me to switch to the development > version of FPC, FPC 2.3.0. > So, is there a patch for FPC 2.2.4 available to fix PIC? When does FPC > 2.4.0 will be released? Probably not this year, but early next. Note that 2.4.0-to-be is the same as the development version 2.3.x. So if you have problems with that, it might also be in 2.4.0 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Broken PIC support in FPC 2.2.4t
On Sat, 10 Oct 2009 23:32:58 +0200 (CEST), mar...@stack.nl (Marco van de Voort) wrote: > In our previous episode, Matthias Klumpp said: >> Because PIC-Support is broken in FPC 2.2.4, I cannot build shared >> libraries >> at time. ( See http://bugs.freepascal.org/view.php?id=12492 ) >> Unfortunately it is not possible for me to switch to the development >> version of FPC, FPC 2.3.0. > >> So, is there a patch for FPC 2.2.4 available to fix PIC? When does FPC >> 2.4.0 will be released? > > Probably not this year, but early next. Note that 2.4.0-to-be is the same > as > the development version 2.3.x. So if you have problems with that, it might > also be in 2.4.0 I do not have problems with FPC 2.3.x, but it is not allowed for me to use experimental SVN software :-( Early next year sounds good! Matthias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] two small ?s - high(real) and nearest 2^x
Thanks, guys! hrm, I am a little disappointed to realize that, although I'm on a 32-bit system, 'real' maps to 'double' rather than 'single' ... and it is a bit slower, too. So I guess I'll use single for now. an fpc bsr function would be nice, but I'm gonna stick with compatible code. I do realize that allocating by doubling size is memory intensive, but it's just for the rapid growth part-- once the array is populated, I shrink it down to its precise size. Cheers, David. On Sat 10 Oct 2009, David Emerson wrote: > 1. Is there a way to get the highest and lowest real values? I can do > high(longint) but high(real) gives me an error. Also of interest is a > low(real) value (-m * 10^n) as distinct from the smallest real value > (m * 10^-n) > > 2. For the purposes of reserving memory in block sizes that can be > easily reallocated, I like to use powers of two. So if I have, e.g., a > dynamic array, I might start with a size of 1024 and then double it > when it hits capacity. Hopefully this smoothes memory management, as I > am using a lot of memory... > > Anyway, what I'd like is a simple function that can quickly identify the > next power-of-two larger than an arbitrary number. So if I feed the > function 472, it will return 512. Thus far I haven't been able to > figure out how to do this without a big if-then-else nest. Is there > some clever way to request that the processor return the position of > the leftmost '1' in 00101101? > > Thanks! > ~David. > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
