I Hope the following never goes away - I use this stuff all the time!
Types
-----
Cardinal, Pointer, Integer
Always evaluate to the endian in use.
SizeOf(Cardinal)=SizeOf(Pointer)=SizeOf(Integer)
Offsets
-------
If I have a record or a class - and dereference the pointer "nil" I can
always get the actual offset for a data element! I LOVE THIS.
Example:
---------------CODE BEGIN
Type rtMyRecord = record
saMyName: ansistring;
saMyEmail: ansistring;
end;
var rMyRecord:=rtMyRecord;
lpMyRecord: pointer;
uMyCardinalOffset: cardinal;
begin
lpMyRecord:=getmem(SizeOf(rtMyRecord));
uMyCardinalOffset:=cardinal(@rMyRecord(nil^).saMyEmail);
end;
---------------CODE END
You can do the same thing with a class, without the carat "^" symbol. This
is not such a big deal for many people because you can access the record or
class elements like this:
rMyRecord(lpMyRecord^).saMyEmail:='[EMAIL PROTECTED]'; However, there are
times when I use a generic routine - that works with ansistrings generally -
or binary chunks - like searching memory for a specific integer value.
I'm able to write a generic routine - that can search an array of pointers
to class instances or record types, and pick out the element to seek out
based on the offset.
------- CODE BEGIN
// Sample function definition to look at a specific element
function bFindAnsistring(
p_saSearchFor: ansistring;
p_lpStructureWithAnsiToSearch: pointer;
p_lpOffset: pointer;
): boolean;
...
// Sample usage of offsets - in a ansistring search routine for a known
"structure type"
if bFindAnsistring('[EMAIL PROTECTED]', lpMyRecord,
@rMyRecord(nil^).saMyEmail) then
begin
writeln('FOUND IT')
end;
------- CODE END
And this is cool because the above call to bFindAnsiString function can be
designed for Ansistrings - and use the value passed in lpMyRecord and add
the passed offset using the nil trick above - to get the actual address of
the ansistring. So, in this mock up function bFindAnsistring, you could
write the contents of the element like this if you chose to (Just to
demonstrate why I think this is neat)
---- Code Begin
// Sample function definition to look at a specific element
writeln(Ansistring(pointer(cardinal(p_lpStructure)+cardinal(p_lpOffset))^));
// another example
bFindAnsistring:=(p_saSearchFor =
Ansistring(pointer(cardinal(p_lpStructure)+cardinal(p_lpOffset))^));
---- Code End
I have used this technique to write two main search functions in my own base
classes - one for binary searching - I use for everything NON-ansistring,
And another, like above - for ansistring. Ansistring has it's own rules - so
I try to let freepascal handle the slicing and dicing - and only use
pointers - not to "find the data" but to let the compiler know I mean the
Ansistring at this address. My tests show that this works fine - and doesn't
seem to screw up freepascals' reference counts and stuff (e.g. I don't get
memory leaks for accessing ansistring this way)
I just wanted to share that - and how much I love these abilities in FPC to
date. I hope this "raw power" stays available. Its basically fancy pointer
math - but - its nicer than c/c++ way - and shows how you can do all the
C/C++ dirty pointer tricks - rather cleanly in free pascal.
BASEADDRESS+OFFSET=YOU Are HERE
Best Regards,
Jason P Sage
Best Regards,
Jason P Sage
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, February 21, 2007 3:05 AM
To: fpc-pascal@lists.freepascal.org
Subject: fpc-pascal Digest, Vol 30, Issue 25
Send fpc-pascal mailing list submissions to
fpc-pascal@lists.freepascal.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of fpc-pascal digest..."
Today's Topics:
1. Re: Advantages of Pascal (Jonas Maebe)
2. Re: Advantages of Pascal (Dani?l Mantione)
3. Re: Wikies (Felipe Monteiro de Carvalho)
4. Re: Wikies (Florian Klaempfl)
5. Re: Wikies (Felipe Monteiro de Carvalho)
6. Re: Wikies (Florian Klaempfl)
7. open array and 2.1.1 (Joao Morais)
8. Re: Wikies (Felipe Monteiro de Carvalho)
9. Re: Advantages of Pascal (Marco van de Voort)
----------------------------------------------------------------------
Message: 1
Date: Tue, 20 Feb 2007 20:09:51 +0100
From: Jonas Maebe <[EMAIL PROTECTED]>
Subject: Re: [fpc-pascal] Advantages of Pascal
To: FPC-Pascal users discussions <fpc-pascal@lists.freepascal.org>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
On 20 feb 2007, at 19:46, Patrick Leslie Polzer wrote:
> 1) "No Makefiles"
> ...and yet you ship a Makefile generator with FPC. Why?
Because you cannot tell the compiler to compiler run time library,
then itself with the rtl that was just compiled, then recompile the
run time library with the newly compiled compiler, then itself with
the newly compiled compiler etc. fpcmake is a tool developed for
internal use, but everyone is free to use it. You don't strictly need
it except in complex cases like the above, though.
> 2) "Pascal compilers are Fast with a big F [...]"
> Why is that?
Because you do not need a preprocessor pass, and compiled unit
interfaces can be reused much more often than e.g. C pre-compiled
headers because no external defines can influence them (and therefore
you also need much less checking to see whether or not a unit needs
to be recompiled).
> 3) "Great integration with assembler"
> Is being able to use Assembler easily inline really that much
> better as opposed to having the code in separate object files?
Personal preference.
> 4) "Smartlinking"
> Ah, I think you can have that one in C with some obscure linker
> flags, too.
Nowadays you can indeed, yes.
> 5) Why use Pascal instead of Ada?
Personal preference.
> 6) Can I have run-time range checking of arrays/strings and *still*
> use functions that accept arrays of any length?
Yes.
Jonas
------------------------------
Message: 2
Date: Tue, 20 Feb 2007 20:22:54 +0100 (CET)
From: Dani?l Mantione <[EMAIL PROTECTED]>
Subject: Re: [fpc-pascal] Advantages of Pascal
To: FPC-Pascal users discussions <fpc-pascal@lists.freepascal.org>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="iso-8859-1"
Op Tue, 20 Feb 2007, schreef Patrick Leslie Polzer:
> Dear FreePascal adepts,
> =
> when I was younger (about seven years ago), I wrote several programs
> in Borland's Turbo Pascal version 7 (IIRC).
> =
> I then learned C and haven't looked much at Pascal ever since.
> However, I'm still fond of Pascal's clear syntax, so I would like
> to know more about its advantages.
Please try it. There is no better way to learn about its advantages than =
actual programming. This can better explain it to you than I can do in =
1000 words. For many C programmers, getting into Free Pascal is a very =
enjoyable experience.
=
> I would be very grateful if you could answer the following questions,
> loosely based on the "Advantages" section of the FreePascal homepage.
> =
> =
> 1) "No Makefiles"
> ...and yet you ship a Makefile generator with FPC. Why?
Since the compiler is able to find the dependencies of files automatically,=
do =
this is not something you need a Makefile for. However, there are several =
other things, like creating a tar or zip of your program, installing it =
and some more things. A makefile is one way to provide this functionality, =
which we make easy and user friendly by providing a makefile generator.
Still we are going to kick fpcmake, since makefiles are hard to port. As C =
programmer you probably know this, to be able to execute a configure =
script on Windows you need an Unix emulator like Cygwin or Msys.
Building the compiler using fpcmake on Windows requires people to =
several Unix utilities, like cp, mv. In near the future we will move to a =
build tool which doesn't depend on external tools to copy files etc., =
increasing the portability of the compiler.
=
> 2) "Pascal compilers are Fast with a big F [...]"
> Why is that?
The main reason for this is the unit system. If a C program uses a =
library, all header files need to be loaded and parsed, for each source =
file again. A Pascal compiler can simply load a unit from disk, so it =
doesn't need to parse headers. Further, once loaded, the unit remains in =
memory, so if the next file is compiled, it is ready to be used again.
Some C-compilers provide pre-compiled headers to provide some of the same =
advantages, but since the content of a header can change with a simple =
define, this is limited; until now this has not been very successfull in =
obtaining similar performance to Pascal compilers.
> 3) "Great integration with assembler"
> Is being able to use Assembler easily inline really that much
> better as opposed to having the code in separate object files?
Assembler at the Pascal level frees you from the trouble to access =
parameters. If you would write pure assembler you need to work with =
offsets on the stack that need to match what the compiler uses. This is =
very error prone.
Further, you can access any Pascal symbol directly from your assembler =
routines, which saves you all kinds of cubersome imports in your assembler =
files.
> 4) "Smartlinking"
> Ah, I think you can have that one in C with some obscure linker
> flags, too.
Recently it has become possible to do real smartlinking with gcc. FPC has =
done this since the late 90's; while gcc could only remove unused files, =
FPC could remove individual variables and procedures.
Still, it works better. Try to statically link a hello world in C and then =
smartlink a hello word in FPC. Compare the executables.
> 5) Why use Pascal instead of Ada?
Ada is a good language. Pascal is good language too, and
modern Object Pascal might be even more advanced than Ada. For certain is =
that Pascal has better development tools, a much larger treasury chest of =
existing code and libraries and is much better documented due to the =
libraries of book been written on it.
> =
> 6) Can I have run-time range checking of arrays/strings and *still*
> use functions that accept arrays of any length?
Yes. We call this open arrays.
> Thank you so much in advance for helping me.
You're welcome :)
Dani=EBl Mantione
------------------------------
Message: 3
Date: Tue, 20 Feb 2007 20:46:30 +0100
From: "Felipe Monteiro de Carvalho"
<[EMAIL PROTECTED]>
Subject: Re: [fpc-pascal] Wikies
To: "FPC-Pascal users discussions" <fpc-pascal@lists.freepascal.org>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello,
I implemented a trivial solution for this. Take a look at:
http://wiki.freepascal.org/New_Main_Page
I simply moved free pascal stuff to a new page on
http://wiki.freepascal.org/Free_Pascal_Documentation
And added a big entry for this on the main page.
So, what do you guys think? Can I move that to the main page?
I think that even my trivial solution is much better then the current
solution: No links to fpc stuff at all.
--
Felipe Monteiro de Carvalho
------------------------------
Message: 4
Date: Tue, 20 Feb 2007 20:47:34 +0100
From: Florian Klaempfl <[EMAIL PROTECTED]>
Subject: Re: [fpc-pascal] Wikies
To: FPC-Pascal users discussions <fpc-pascal@lists.freepascal.org>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Felipe Monteiro de Carvalho schrieb:
> Hello,
>
> I implemented a trivial solution for this. Take a look at:
>
> http://wiki.freepascal.org/New_Main_Page
>
> I simply moved free pascal stuff to a new page on
>
> http://wiki.freepascal.org/Free_Pascal_Documentation
>
> And added a big entry for this on the main page.
>
> So, what do you guys think? Can I move that to the main page?
>
> I think that even my trivial solution is much better then the current
> solution: No links to fpc stuff at all.
>
I added the important fpc stuff already to the main page?
------------------------------
Message: 5
Date: Tue, 20 Feb 2007 20:52:23 +0100
From: "Felipe Monteiro de Carvalho"
<[EMAIL PROTECTED]>
Subject: Re: [fpc-pascal] Wikies
To: "FPC-Pascal users discussions" <fpc-pascal@lists.freepascal.org>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 2/20/07, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> I added the important fpc stuff already to the main page?
Sorry, I don´t understand what you mean. Can you explain better?
I just went to the main page and couldn´t find fpc things:
http://wiki.freepascal.org/
--
Felipe Monteiro de Carvalho
------------------------------
Message: 6
Date: Tue, 20 Feb 2007 22:50:34 +0100
From: Florian Klaempfl <[EMAIL PROTECTED]>
Subject: Re: [fpc-pascal] Wikies
To: FPC-Pascal users discussions <fpc-pascal@lists.freepascal.org>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Felipe Monteiro de Carvalho schrieb:
> On 2/20/07, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
>> I added the important fpc stuff already to the main page?
>
> Sorry, I don´t understand what you mean. Can you explain better?
>
> I just went to the main page and couldn´t find fpc things:
> http://wiki.freepascal.org/
>
? Just read the about section?
------------------------------
Message: 7
Date: Tue, 20 Feb 2007 20:02:39 -0300
From: Joao Morais <[EMAIL PROTECTED]>
Subject: [fpc-pascal] open array and 2.1.1
To: FPC-Pascal users discussions <fpc-pascal@lists.freepascal.org>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello,
the following code:
====
program testarray;
uses
classes;
procedure testparam(aarray: array of tclass);
begin
end;
begin
testparam([nil, tlist, tstringlist]);
end.
====
compiles under 2.0.4 but fails under 2.1.1 (rev 6583), the compiler
think that I have an array of const because of the nil argument.
Known problem? Something that was changed?
Thanks,
--
Joao Morais
------------------------------
Message: 8
Date: Wed, 21 Feb 2007 06:55:05 +0100
From: "Felipe Monteiro de Carvalho"
<[EMAIL PROTECTED]>
Subject: Re: [fpc-pascal] Wikies
To: "FPC-Pascal users discussions" <fpc-pascal@lists.freepascal.org>
Message-ID:
<[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 2/20/07, Florian Klaempfl <[EMAIL PROTECTED]> wrote:
> ? Just read the about section?
Ah,..... sorry =)
--
Felipe Monteiro de Carvalho
------------------------------
Message: 9
Date: Wed, 21 Feb 2007 09:03:36 +0100 (CET)
From: [EMAIL PROTECTED] (Marco van de Voort)
Subject: Re: [fpc-pascal] Advantages of Pascal
To: FPC-Pascal users discussions <fpc-pascal@lists.freepascal.org>
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset="US-ASCII"
> On 20 feb 2007, at 19:46, Patrick Leslie Polzer wrote:
>
> > 1) "No Makefiles"
> > ...and yet you ship a Makefile generator with FPC. Why?
>
> Because you cannot tell the compiler to compiler run time library,
> then itself with the rtl that was just compiled, then recompile the
> run time library with the newly compiled compiler, then itself with
> the newly compiled compiler etc. fpcmake is a tool developed for
> internal use, but everyone is free to use it. You don't strictly need
> it except in complex cases like the above, though.
Also FPC uses it more as a script to get actions done in an order. (make
being one single .exe, small and easy to install), So in other words make
with FPC is a bit less about laying out how to build an .exe/library, and a
bit more to specify which exe's/libraries should be built.
> > 2) "Pascal compilers are Fast with a big F [...]"
> > Why is that?
>
> Because you do not need a preprocessor pass, and compiled unit
> interfaces can be reused much more often than e.g. C pre-compiled
> headers because no external defines can influence them (and therefore
> you also need much less checking to see whether or not a unit needs
> to be recompiled).
(Personally I think one probably could get an enormous way with precompiled
headers, specially _IF_ the headers are not to murky. But it requires a
great lot of extra work on the compiler side, and is much less
comprehendable for end users than the more well defined Pascal system. The
fact that gcc doesn't have a precompiled header system yet after 20 years of
development says enough I think)
> > 3) "Great integration with assembler"
> > Is being able to use Assembler easily inline really that much
> > better as opposed to having the code in separate object files?
> Personal preference.
Pro: integration between pascal code and assembler is much tighter. Even GCC
resorts to a form of inline assembler, just less readable and userfriendly.
Con: people might inadvertedly use assembler when not necessary. THis is
clearly visible in Delphi and TP source. OTOH in practice I don't think that
this is such a big problem anymore with Delphi srcs, since people already
have become more reluctant to use assembler. A minor annoyance when porting
delphi sources. But in TP times it was _bad_.
> > 4) "Smartlinking"
> > Ah, I think you can have that one in C with some obscure linker
> > flags, too.
>
> Nowadays you can indeed, yes.
I'm not entirely sure if the granularity is the same.
> > 5) Why use Pascal instead of Ada?
>
> Personal preference.
Ditto, and in my case : Ada seems overly complex for every day use to me.
But
if I ever develop something nuclear, I'll keep it in mind.
------------------------------
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
End of fpc-pascal Digest, Vol 30, Issue 25
******************************************
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.441 / Virus Database: 268.18.3/694 - Release Date: 2/20/2007
1:44 PM
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
