Re: [fpc-pascal] Program not running
Hi, On Wed, 2013-05-29 at 14:01 +0200, Koenraad Lelong wrote: Op 27-05-13 21:20, Koenraad Lelong schreef: Hi, .. A suggestion on the hardkernel-forum said it might be an armhf problem. Is it prossible to compile fpc from armhf ? There's snapshot on the ftp. Should I do this native ? Why not? I mean, I have an fpc running on the hardware, but it's an armel, at least I think it is. My ppcarm says Compiler CPU target arm. Then : supported targets : linux for ARMEL. Seems so, and explains the issue, i.e. unrecognized executable. Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Program not running
On Wed, 2013-05-29 at 18:48 +0200, Koenraad Lelong wrote: Op 29-05-13 18:16, Thomas Schatzl schreef: There's snapshot on the ftp. Downloaded ftp://ftp.freepascal.org/pub/fpc/snapshot/v27/arm-linux-armhf/ Should I do this native ? Copied the contents to /usr Tried fpc -i, shows fpc 2.6.2, for armel. Is there some mistake ? Yes, you need to fix some symlink so that fpc uses the new compiler. I think there is a symlink in /usr/bin/ppcppc that still points to the old compiler. This is probably wrong, don't remember the exact location of the symlink that is used by the fpc wrapper. Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC x86+x64 win trunk failing to build (using fpcup): 2 different errors
Hi, On Fri, 2012-09-21 at 08:42 +0200, Tomas Hajny wrote: On Thu, September 20, 2012 17:30, Reinier Olislagers wrote: On 20-9-2012 17:25, Jonas Maebe wrote: On 20 Sep 2012, at 17:18, Reinier Olislagers wrote: Would looking into the actual fpmake bug make sense (i.e. is it doable for mere mortals like me?) Where would I look? It's probably related to how the makefiles clean the packages since fpmake was introduced. Pierre posted a not really clean workaround recently to the core list, see below (I don't think the patch will apply as is though, because the formatting was changed by the mail client). Thanks a lot Jonas, looks like I'll stick to adding a workaround to fpcup... Actually, I believe that looking into the fpmake bug should make more sense and yes, I think that it should be doable for mere mortals since it is written in standard (Object) Pascal rather than requiring some Makefile wizardry. Cleaning directories is partially the responsibility of the makefiles though - who else cleans the fpmake executables themselves? Looking at comments in packages/Makefile.fpc, the issue is apparently known. # In case of a distclean, perform an 'old'-style distclean. This to # avoid problems when the package is compiled using fpcmake prior to # running this clean using fpmake. It does not work well, though, since # the sub-directories are not cleaned at all. Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Inline bytes
Hi,
On 08/ 9/12 03:09 PM, Rainer Stratmann wrote:
How is it possible to put some inline bytes in the code like the former
inline( $1f , $ef , $1A );
instruction?
Not sure if it is the official way, but the following works:
with {$asmmode att}
asm
.byte 0x1f, 0xef, 0x1a
end;
and with {$asmmode intel}
asm
db $1f, $ef, $1a
end;
Hth,
Thomas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Label
Hi, On 08/ 9/12 05:08 PM, Rainer Stratmann wrote: Just because it sounds that way: is it possible inside the procedure? Yes, if the label declaration is also inside the procedure. You can only take the address of a globally declared label iff a) the label is also defined in the global scope (begin .. end., initialization, finalization) b) the label's address is also taken in one of those blocks. It doesn't have to be the same one though, because the compiler keeps the code for all of those blocks in memory at the same time and hence a label defined in one of those is still valid while generating the code for another one. That's more a compiler implementation aspect than a conscious design decision though If you have a label in a procedure and declare this procedure as inline procedure then it gives also problems (Fatal: compilation aborted!). just fyi, generally the inline keyword is only a suggestion to the compiler. There is no guarantee whatsoever that it will actually inline that particular method. There are, as you found out, several limitations for that. Actually, there are more, like size of the inlined method, possible use of exception handling, etc. (I'm not sure about the exact conditions btw, maybe there's some documentation in the manuals) Do not use it if you code something that relies on actual inlining - it seems to me that you require that in whatever you're trying to achieve. Only macros are guaranteed to be inlined - because they are simple text replacement instructions to the compiler. Hth, Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: UnicodeString comparison performance
HI, On Mon, 2012-07-23 at 16:58 +0200, OBones wrote: Jonas Maebe wrote: On 23 Jul 2012, at 10:58, OBones wrote: leledumbo wrote: I look at the generated code and in the direct one there's additional overhead of decrementing the reference counter on each iteration. I see it too now (I forgot about the -a option). I can understand why there is a call to the decrementer outside the loop when using the variable, but I don't understand why it pushes it completely out of the loop. I mean, isn't there a reference count problem here? Reference counted data types are returned by reference in a location passed to the function by the caller. The compiler here passes the address of S to the function, so that when assigning something to the function result inside the function, S' reference count gets decreased. The fact that when the result is returned in a temp, this temp also gets finalized on the caller side before the call is just a code generator inefficiency. I've changed that in trunk. Thanks for the explanation and the fix. Because the finalization happened too early, those memory allocations and deallocations were very costly and I found the direct code to be 30 times slower. Doing it this way has the advantage of being inherently thread safe, but considering the performance penalty, I have moved to doing it this way: var Buffer: array [0..1024*1024-1] of WideChar; BufferLock: NativeInt; function GetSomeString(Index: Integer): UnicodeString; begin while BufferLock 0 do Sleep(1); InterlockedIncrement(BufferLock); try CallToAnAPIThatWritesBackAWideString(@Buffer[0], Length(Buffer) - 1); Result := PWideChar(@Buffer[0]); finally InterlockedDecrement(BufferLock); end; end; This works, with an equivalent penalty on both methods and is threadsafe (I believe). This code is not thread safe at all. A thread switch after the while loop and before the increment will not prevent progress on other threads, so multiple threads can enter the critical section. Use EnterCriticalSection/LeaveCriticalSection from the RTL if you need that. If you could somewhat decrease the size of your buffer to something reasonable - do you really expect to translate a string with 1M chars? - use the stack. Actually even a 2M data object on the stack might be reasonable. Further, in any case you'll need some code that works in all cases anyway - what if your string does exceed 1M chars after all? I mean, on a 1M string, heap allocation will probably be the least of your performance worries. This will completely avoid use of any synchronization primitive. E.g. function GetSomeString(index : integer) : UnicodeString; const bufsize = 1024; // as you wish var buffer : array[0..bufsize-1] of WideChar; pbuffer : PWideChar; islongstring : boolean; lengthofstring : integer; begin lengthofstring := length(stringfromindex(integer)); islongstring := lengthofstring bufsize; if (islongstring) then pbuffer := getmem(lengthofstring * sizeof(WideChar)); else pbuffer := @buffer; CallToAnAPIThatWritesBackAWideString(stringfromindex(integer), pbuffer, lengthofstring); if (islongstring) then freemem(pbuffer); result := pbuffer; end; You may want to improve the code further by e.g. checking whether the memory allocation has been successful or not; or factor out the case when the string is big into a separate method to improve readability. Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Database problem on Solaris SPARC
Hi, On Thu, 2012-07-12 at 09:47 +, Mark Morgan Lloyd wrote: Ludo Brands wrote: Builds OK on SPARC Solaris 10 using 2.6.0, but on running get a consistent error Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 4] 0x004b08b8 in TPQCONNECTION__LOADFIELD (CURSOR=0xfad601a0, FIELDDEF=0xfad30f20, BUFFER=0xfa5f00bc, CREATEBLOB=fa 803 if FIntegerDatetimes then dbl^ := pint64(buffer)^/100; Not sure if it applies to your case, but afaik SPARC requires natural alignment for memory accesses. buffer is not aligned to 8 bytes here... (0xfa5f00bc ---) Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : [fpc-pascal] Reversing bit-order of byte
Hi, On Fri, 2012-05-04 at 14:14 +0200, Koenraad Lelong wrote: On 03-05-12 13:27, Thomas Schatzl wrote: ... function reverse(b : byte) : byte; assembler; nostackframe; asm .long 0xe6ff0f30 // rbit r0, r0 lsr r0, r0, #23 end; Hi, I've been looking a bit further at this. I disassembled the code and this is the result : 8000150: e6ff0f30rbitr0, r0 8000154: ea4f 50d0 mov.w r0, r0, lsr #23 The constant is wrong here, it should be #24, not #23 imo... typo. 8000158: 46f7mov pc, lr It might be good to compile with -Cparmv6 (or -Cparmv7, do not know what type the processor you use is), this generates a better return instruction (bx lr) - and for the rbit instruction you need armv6 already. Wouldn't it be possible to do rbitr0, r0, lsr #23 When reading the ARM programming manual I believe it should. No, rbit does not allow the flexible operand encoding. But do I gain something ? If it were possible, at most a few cpu cycles. Compared to the other variants (e.g. with the multiplies, except for the table lookup) you already save a lot of cycles - although I guess they would be sufficiently fast anyway, considering the typical uart speeds. Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reversing bit-order of byte
Hi, On Thu, 2012-05-03 at 07:55 +, Mark Morgan Lloyd wrote: Koenraad Lelong wrote: Hi, I'm porting a driver, originally written in C, for an LCD to be used with an embedded arm-processor (STM32). The original driver uses SPI, my driver will use a USART in synchronous mode because the STM32 has no SPI for 9-bit. Unfortunately, the bit-order is reversed between SPI and USART transmission. Does anyone knows an efficient way to reverse bit-order of a byte for the arm-processor ? I'm going to look into the assembly language of the arm-processor, but maybe someone knows this immediately. For old processors like 8085 or Z80 I know how to do this, but arm-assembler is new to me. E.g. see http://graphics.stanford.edu/~seander/bithacks.html#ReverseByteWith64BitsDiv (which, in addition to the above way also gives other examples; then there is http://www.tekpool.com/node/208 which shows even more of them if you do not like 64 bit math) I think I'd use a lookup table (making sure it's cacheable), particularly since what you're doing is going to be called frequently and you're likely to have much more than 64K memory. ... however I guess that a precomputed table is likely best for your application. Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : [fpc-pascal] Reversing bit-order of byte
Hi, On Thu, 2012-05-03 at 12:54 +0200, Ludo Brands wrote: Thanks all for your replies. I already found the RBIT-instruction. I also found out I need to study the arm assembly language ;-) But how do I get my variable ? Is that in some register ? Is there any documentation about such things ? Then I can use inline assembly. ARM has different ABI's. A pragmatic solution is to create a full pascal We use the standard ARM EABI as gcc uses; for the purpose of this code, it should be sufficient to know that r0 contains the first parameter value, and function values are returned in r0 as well. Without testing, something like the following should be sufficient: function reverse(b : byte) : byte; assembler; nostackframe; asm rbit r0, r0 // rbit reverses the whole word, so now you have // your value in bits 31-24... so shift right by that amount // should fix this up (bits 23-0 contain junk, we shift that out // anyway) lsr r0, r0, #24 end; However, this may not compile because fpc may not recognize the rbit instruction. Following is a version that encodes the instruction directly, retrieved from disassembling some gcc code: function reverse(b : byte) : byte; assembler; nostackframe; asm .long 0xe6ff0f30 // rbit r0, r0 lsr r0, r0, #24 end; Hope this helps; I could not test due to lack of hardware. It may help to use -Cparmv6 and have your (cross-)assembler configured for armv6 code emission. Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] making FPC more code optimized
Hi On Sun, 2012-04-29 at 15:50 +0200, Florian Klämpfl wrote: Am 29.04.2012 15:13, schrieb Jorge Aldo G. de F. Junior: If you deploy one executable, ok, but if you want to create a handfull of executables (following unix logic of many small programs) then you have a problem. Indeed, but I don't think this is the way FPC programs are typically used. EVERY executable will have the same code again again again, i think libraries have been created to address exactly this issue. about the library hell, why we cant use lib versions ? Because nobody is interested in doing so? Else we got already patches for the install builders to contain .so as well. FPC can create shared libs on unixes and with small flaws, it even works ;) florian@ubuntu32:~$ ldd ./test libfprtl-2.7.1.so = /home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7, Actually, this output shows the bug already: for some reason it does not link to ld.so as well. I thought I had fixed that some time ago. .1.so (0x008d3000) florian@ubuntu32:~$ ls -la /home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7.1.so -rw-r--r-- 1 florian florian 2026701 2012-04-29 15:42 /home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7.1.so florian@ubuntu32:~$ ./test Hello world Inconsistency detected by ld.so: dl-fini.c: 194: _dl_fini: Assertion `ns != 0 || i == nloaded' failed! And that's exactly what happens if the library is missing the reference to ld.so on ubuntu ... I will have a look why this broke (again). Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] making FPC more code optimized
Hi, On Sun, 2012-04-29 at 17:38 +0200, Florian Klämpfl wrote: Am 29.04.2012 17:34, schrieb Thomas Schatzl: Hi florian@ubuntu32:~$ ldd ./test libfprtl-2.7.1.so = /home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7, Actually, this output shows the bug already: for some reason it does not link to ld.so as well. I thought I had fixed that some time ago. .1.so (0x008d3000) florian@ubuntu32:~$ ls -la /home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7.1.so -rw-r--r-- 1 florian florian 2026701 2012-04-29 15:42 /home/florian/./fpc/svn/rtl/units/i386-linux/libfprtl-2.7.1.so florian@ubuntu32:~$ ./test Hello world Inconsistency detected by ld.so: dl-fini.c: 194: _dl_fini: Assertion `ns != 0 || i == nloaded' failed! And that's exactly what happens if the library is missing the reference to ld.so on ubuntu ... I will have a look why this broke (again). Does libfprtl have to reference ld.so or the main program? iirc it is sufficient that libfprtl references it. But that error message is just what you get if it does not. So maybe my reply was too quick. I will have a try and see anyway; further thinking about it, if there were changes to that code, the corresponding testsuite programs should fail too, so maybe the original changes just work for some cases or cover up the real issue. Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC for ARM
Hi, On Mon, 2011-12-19 at 13:16 +0200, Juha Manninen wrote: 2011/11/28 Henry Vermaak henry.verm...@gmail.com There is an arm release for 2.6.0rc1, but it was built using old binutils (last time I checked, at least): ftp://freepascal.stack.nl/pub/fpc/beta/2.6.0-rc1/arm-linux/ I finally got into installing and testing FPC in the ARM-gadget. Other people had replaced the original Debian with Ubuntu 9.something. I was able to copy and install your FPC 2.6.0-rc1 package there. It was easier than I thought! The compiler itself works but assembler is missing. See : --- root@ubuntu:/usr/share/doc/fpc-2.6.0/examples/text# fpc hello.pp Free Pascal Compiler version 2.6.0rc1 [2011/10/20] for arm Copyright (c) 1993-2011 by Florian Klaempfl and others Target OS: Linux for ARMEL Compiling hello.pp Assembling hello hello.pp(19,27) Error: Assembler as not found, switching to external assembling hello.pp(19,27) Fatal: There were 1 errors compiling module, stopping --- Does it mean an assembler is always needed with ARM? In my understanding x86 based PCs don't need a separate assembler with FPC. apt-get install as didn't install anything. Afaik only the Windows platforms have an internal assembler and linker. At least arm/ppc*-linux needs GNU binutils. The solution is to install the binutils package on Debian systems. The error reported by the original poster (H. Vermaak) seems to be caused by some compiler internal error observed when running the bootstrap compiler on that system, which may have various reasons. (http://permalink.gmane.org/gmane.comp.compilers.free-pascal.general/25299) ... What setup issue do you think can cause an *internal error* in the bootstrap compiler? (emphasis mine) Since you already reached the assembling/linking stage with the bootstrap compiler, you did not encounter it. Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC for ARM
Hi, Am 28.11.2011 15:18, schrieb Henry Vermaak: On 28/11/11 13:41, Juha Manninen wrote: Hi Is FPC 2.2.2 really the latest native release for ARM processors? I guess it can build the more recent versions. (?) There is an arm release for 2.6.0rc1, but it was built using old binutils (last time I checked, at least): ftp://freepascal.stack.nl/pub/fpc/beta/2.6.0-rc1/arm-linux/ What OS/version are you using? Maybe some OS setup issue? On an HP Touchpad and a Sheevaplug-like system, which are both eabi5, the bootstrap compiler and fpc produced executables work just fine. The eabi4 type of the bootstrap compiler originates from the build machine running on the latest debian lenny (5.0.9) which unfortunately only has very old binutils from 2008 (2.18.x) in its distro, or defaults to eabi4 output. At least its GNU as seems to simply ignore a -meabi=5 assembler switch. However even that build machine seems to be able to run eabi5 executables fine. E.g. I copied over the bzip2 executable from an eabi5 machine to the build machine. $ objdump -x ./bzip2 | grep ersion Version References: private flags = 502: [Version5 EABI] [has entry point] $ ./bzip2 --version bzip2, a block-sorting file compressor. Version 1.0.4, 20-Dec-2006. Copyright (C) 1996-2006 by Julian Seward. This program is free software; you can redistribute it and/or modify it under the terms set out in the LICENSE file, which is included in the bzip2-1.0.4 source distribution. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the LICENSE file for more details. bzip2: I won't write compressed data to a terminal. bzip2: For help, type: `bzip2 --help'. $ objdump -x /bin/bzip2 | grep ersion Version References: private flags = 402: [Version4 EABI] [has entry point] Might not be representative, but it seems to me that your system is somewhat oddly configured. (Maybe its some debian thing?) I do not mind trying to switch to eabi5 by default, but there might be systems which absolutely require eabi4 which seems to be some lowest common denominator, i.e. also eabi5 setups seem to be able to run them anyway. Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Working Free Pascal android JNI example
Hi, On Wed, 10 Aug 2011 11:09:26 +0200, Felipe Monteiro de Carvalho wrote: Hello, I am ressuscitating this ancient thread because I'd like to continue the talk about it =) My main doubt here is if androidprt0.as is really required, which would mean that I can only produce android libraries if I make changes to the compiler. Note that there is no dedicated android/arm support (or any arm support) for freepascal yet. In some circumstances the arm/linux stuff works. Benjamin, couldn't one just declare the missing simbols in code? This would simplify things a bit. An improved dllprt0.as has been created since, which works fine at least for arm/linux. However, you might want to use the hack from http://mantis.freepascal.org/view.php?id=18833 on android for now. If you can give me some documentation how/if argc/argv/envp are passed to a shared library on android, one could see if support can be added. I assume that some sort of new target may need to be added though. You might want to check whether proper initialization and finalization is performed for those libraries correctly for arm/android. At least when using dlopen and friends on arm/linux (and others) this works. When linking a FPC library using $LINKLIB, initialization/finalization is not called on several linux platforms (ppc/ppc64/arm) or crashes badly on unload at least on some linuxes (x86/amd64 on ubuntu). It contains also a own JNI header port from the Android NDK, and own ARM Toolchain hook binaries to inject some command line parameters to the original as and ld binary calls. For as: --march=armv7-a -mfloat-abi=softfp -mfpu=vfp3 and for ld: --fix-cortex-a8 And important FPC parameters are -CpARMv6 -CfVFPV3 Not sure whether the as/ld issues have been fixed in the meantime. Hth, Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Working Free Pascal android JNI example
Hi, On Wed, 10 Aug 2011 11:59:03 +0200, Thomas Schatzl wrote: Hi, On Wed, 10 Aug 2011 11:09:26 +0200, Felipe Monteiro de Carvalho wrote: Hello, I am ressuscitating this ancient thread because I'd like to continue the talk about it =) My main doubt here is if androidprt0.as is really required, which would mean that I can only produce android libraries if I make changes to the compiler. Note that there is no dedicated android/arm support (or any arm support) for freepascal yet. In some circumstances the arm/linux stuff works. meant or any android support here. Hth, Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] android share library with classes unit
Hi, On Tue, 12 Apr 2011 02:56:39 -0700 (PDT), herux wrote: I managed to compile and run the library for android on emulator, which I compile the project just a libhellojni.so compile using paramater like this ppcarm -Scghi -O1 -Parm -gl -b -B -XX -Xc -XD -CpARMv6 -CfSOFT -dandroid -vewnhi -l -XParm-linux- -Fi/home/herux/workspace/hellojni/jni/lib/arm-linux/ -Fu. -FUlib/arm-linux/ -o../libs/armeabi/libhellojni.so -FD/usr/share/fpcsrc/binutils/ hellojni.lpr [...] then I try to use classes unit or sysutils, the project succeeded in compiling, but the library did not loaded by the emulator. there is an error SIGSEGV Fyi, there is an unresolved issue with Android shared library initialization code which affects the use of the sysutils unit, see http://bugs.freepascal.org/view.php?id=18833 for more details. Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Converting 32bit intel asm to Pascal or 64bit att asm
Hi, On Wed, 09 Mar 2011 11:58:08 -0500, Andrew Haines wrote: if Tmp Im then begin //Tmp := ln(Tmp)*LogBase+Shift; // same as the following asm proc? asm FLD LogBase; FLD Tmp; FYL2X; FYL2X calculates the log to the base 2 of tmp, not log to the base e of tmp? Just a guess. Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Converting 32bit intel asm to Pascal or 64bit att asm
On Wed, 09 Mar 2011 13:23:55 -0500, Andrew Haines wrote: On 03/09/11 12:26, Thomas Schatzl wrote: Hi, On Wed, 09 Mar 2011 11:58:08 -0500, Andrew Haines wrote: if Tmp Im then begin //Tmp := ln(Tmp)*LogBase+Shift; // same as the following asm proc? asm FLD LogBase; FLD Tmp; FYL2X; FYL2X calculates the log to the base 2 of tmp, not log to the base e of tmp? Just a guess. Thomas I originally used log2(Tmp) but switched to ln to check if it was correct. Thanks for noticing that, I changed it back to log2. The current output with the pascal code looks like it did when FLDS was used instead of FLDL to load (%rdi). The intel code was FLD QWORD[EDI] I changed this to FLDQ (%edi). on x32 it became FLDL and on x64 it became FLDS. changing the line to FLDL (%rdi) on x86_64 fixed the last problem I had with the asm translation. Suffixes for gas for floating point are (from http://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax) -s 32 bit/single -l 64 bit/double -t 80 bit/extended With Intel syntax you can only hope that the compiler guesses correctly, or add an explicit override. So you suggest that the assembler changes an inlined fldq (%edi) into flds (%edi) on x86-64? This looks like a bug if true - it should reject the q suffix for floating point operations. At least gas 2.19 on solaris x64 rejects fldq; actually the 2.4.2 release compiler transforms fldq into fld here, which gas rejects too :) I will write a bug report. Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpc and armv5-android
Hi, On Sun, 27 Feb 2011 04:32:14 -0800 (PST), Dejan Boras de_jean_7...@yahoo.com wrote: Is there anyone on this list who uses fpc with android under windows and the android emulator(armv5) without problems(e.g. basic functionality at least like sysutils, ansistrings, ...)? I'm just trying to figure out if I'm doing something wrong. No, you aren't - you are probably only the first one who is using shared libraries on arm/linux :) I tried to fix the shared library startup code again in the meantime, please try again (r17033). Actually, I'd expect that there are still other platforms than arm/linux where shared libraries do not work. Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Ansistrings under Android
Hi, On Tue, 22 Feb 2011 13:34:06 -0500, Andrew Haines andrewd...@aol.com wrote: On 02/22/11 12:06, de_jean_ wrote: Now that I have a working fpc crosscompiler for Android, and all the code runs ok, I encountered another problem. Namely working with ansistrings causes crashes. For example, in a simple test, calling the str() routine will cause a crash due to a run-time 216 error (general protection fault). I've also noticed that crashes can occur upon routine exit, when ansistrings are freed automatically. I thought that using the C memory manager (cmem) might help, but there is no difference. For some reason, units are not initialized under a android shared library, so I call internal_initializeunits() myself in the JNI_OnLoad which is called automatically by the JNI, and is called before any other routine. The shared library startup code for ARM is broken (well, from the svn it seems that it never worked), it does not set up the environment variables and call the pascal unit initialization routine. This is a known issue in so far as there are some testsuite tests (tw8730) that fail because of that. Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Need help fixing leaks
Hi, On Mon, 20 Dec 2010 19:33:51 -0800 (PST), leledumbo leledumbo_c...@yahoo.co.id wrote: [...] Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x00406c32 in SYSTEM_TOBJECT_$__FREE () #2 0x0040d916 in TFPGOBJECTLIST$TLLVMVALUE__DEREF (ITEM=0x55138, this=error reading variable) at llvmirbuilder.pp:362 #3 0x00421451 in FGL_TFPSLIST_$__DEREF$LONGINT$LONGINT () #4 0x in ?? () That line is the end of a method and I have no idea why the item got dereferenced. At least one issue seems to be that all your TFPGObjectLists are owners of their respective instances. This leads to multiple attempted Free() calls to the objects in the list. If I am correct, there are/will be up to three Free() calls for some objects in your example code. I may be wrong, I did not really debug the code, just from looking at it. Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Endian issues when porting FPC programs from x86 to other platforms
Hi, On Tue, 02 Nov 2010 23:49:03 +0100, Bo Berglund bo.bergl...@gmail.com wrote: On Tue, 02 Nov 2010 22:53:21 +0100, Vinzent Höfler jellyfish.softw...@gmx.net wrote: On Tue, 02 Nov 2010 21:39:31 +0100, Felipe Monteiro de Carvalho felipemonteiro.carva...@gmail.com wrote: On Tue, Nov 2, 2010 at 7:04 PM, Bo Berglund bo.bergl...@gmail.com wrote: Thanks, that helps a lot! Are there also overloaded BEtoN functions for floating point values? I think that single and double have always the same binary layout. Mostly, I'd guess. But I wouldn't count on that. I know for sure that on the Motorola system the floats are 4 bytes (single precision) and have to be swapped in order to be used on Windows. I have done it on Delphi already so I know this is a fact. So now I need to find an endian corrector working with floating point values as well... Coming back to the suggestion from jonas: function BEtoN(const AValue : single) : single; type TData = packed record case integer of 0 : (s : single); 1 : (l : longint); end; var d : TData; begin d.s := AValue; d.l := system.BEtoN(d.l); result := d.s; end; A BEtoN function for doubles is similar, just replace the single type by double, and longint by int64. Hth, Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Endian issues when porting FPC programs from x86 to other platforms
Hi, Or maybe this is a moot question if FPC is only so far running on platforms that have the same endian as x86 CPU:s? I have no information on this though... I can see at least these targets: - Windows and Linux on x86 CPU:s - Embedded Linux on ARM CPU:s Sparc, PowerPC are big endian, there is an ARM big endian target too. Use BEtoN, NtoBE if the source is known to be big endian. (http://www.freepascal.org/docs-html/rtl/system/beton.html) (http://www.freepascal.org/docs-html/rtl/system/ntobe.html) Hth, Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ARM-Cortex port
Hi, On Tue, 24 Aug 2010 10:53:55 +0100, Geoffrey Barton m...@periphon.net wrote: Date: Mon, 23 Aug 2010 13:57:30 -0300 Thanks Jonas and Jeppe for your answers. I will probably wait then to switch (or try to convince the company to use an ARM-9) using Jonas and Jeppe's answers to my idiot questions in this forum, and Jeppe's startup code for the STM32F, I have FPC cross-compiling for the LM3S9B92, one of the TI Luminary processors. Getting interrupts working took some time. I think the next thing for me is to try calling the rom code from FPC. Then it should be possible to re- use all the library of C code supplied by TI and it will no longer be necessary to try and fathom lines such as:- *((void (*)(void))(*(unsigned long *)0x2c)))(); which occurs in the USB example code :-) I am not quite sure how to write that in FP, but I am sure someone will have an idea. Something like this should work for that case: type TMyProcedure = procedure; // if the procedures/functions you want to invoke have parameters // use something like this: // // TMyFunction = function(arg1 : type1; arg2 : type2) : result_type; var x : TMyProcedure; begin x := TMyProcedure(0x2c); x; // to invoke it. Or x() if you prefer that end. Hth, Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: fast sqrt routine
Andrew Bennett Sat, 11 Mar 2006 17:24:51 -0800 On Sat, 11 Mar 2006 13:44:52 +0100, Pianoman wrote: Hi, I need to perform very fast squareroot (sqrt) operations on double type nukmbers. I tried this function mysqrt(a:double):double; [...] yn:=(y*y+a)/(2*y); until abs(yn-y) 10e-16; mysqrt:=yn; end; but it is quite slow (FPC uses Heron iterations) which is 10 times faster than this code but I need even faster sqrt routin. Any ideas for optimizing the function written above would be appreciated. Pianoman Once upon a time, I did this in single precision: 1) I made a crude 1st guess by manufacturing, in Assembler, a linear fit mantissa - 2 different fits depending if exponent was odd or even - and the appropriate exponent. The worst case error of this is easily calculated. Process takes 2 floating ops and some integer stuff taking out and putting back the exponent. 2) I then explicitly coded the iterations required to converge in this worst case: just 3 floating ops per (or is it 2 plus integer exponent manipulation?) and it didn't take very many. No test. Saving the test saved more time than was wasted doing unnecessary iterations, at least on the machine I did it on. This may not be so in double precision ... For some reason I recently have been interested in fast sqrt computation as well, and found the following (C) pseudo-code, which looks quite fast. It approximates 1/sqrt(x), which can be done without a divide, just multiplies. Maybe it is of help, don't know the Heron iteration thing you mention... (See especially section B. sqrt(x) by Reciproot Iteration, http://www.netlib.org/fdlibm/e_sqrt.c) Regards, Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] is
Hello, Michael Van Canneyt schrieb: On Thu, 7 Apr 2005, Thomas Schatzl wrote: Summing MI with interfaces up: - interfaces are only specifications, so there is no clash of implementations - they neither have some initialization, so there's no problem about constructing the instance either - they provide means to model your world naturally All this is nice, but it boils down to: MI for interfaces is shorthand notation. No more, no less. It introduces no added value (other than notational) or functionality. You suggest that you simply treat the interfaces seperately and use clever single inheritance to simulate all that stuff by clever thought out checks. In short: that's plain stupid (Please forgive me for that and please tell me that you meant something else). Long version: it works if you're a really quick typist: - you add lots of tiny mini-interfaces (actually _all_ interfaces which can be reached by that particular root node) to the list of implemented interfaces. Bad. Obsfucating code. What was the idea with inheritance again? Updating all that stuff when changing the hierarchy is hopefully done magically. - regarding checks: if you change the hierarchy, you need to revisit all of your checks in the code whether they are reflected properly in the hierarchy. Do you really believe anyone will check and update a few hundred kb of code with tons of such checks, and test them all again? - additionally, to be truely equal, all ancestors must manually aggregate all methods of child interfaces (otherwise you don't get the same functionality, look at the eat_just_something() example again). Changing the hierarchy comes to my mind again... - you can optimize (e.g. so that you don't need to aggregate method names by hand) the hierarchy manually by defining single inheritance paths through the MI hierarchy (for every leaf node one, additional if there are diamond shapes in the hierarchy). But this leads to the problem that you actually need additional interface names IJumpingMouseEatsEverythingMeatEaterPath and IJumpingMouseEatsEverythingPlantEaterPath are _really_ descriptive, don't you think too? Wasn't it you who was complaining about good naming...? What about hierarchy change again? - you might need additional paths for the other examples to work (stopped counting here, numbers got too high). This may work for a model hierarchy of five interfaces in total (and even then you do not do it that way). Actually already really small OO-models easily have over thirty interfaces with all kinds of inheritance relations. Larger ones I know have a few hundred (e.g. CWM, MOF, UML). Note to myself: I should give real world models as examples next time, not a carefully cleaned up one... people might start thinking that the problem is exactly like this, only with changed names. Where IC would simply be IA and IB conmbined. In IC, you hide what actually is. (the names are not always as descriptive as in your example.) This is not a problem of MI-inherited interfaces, but a problem of the programmer. You can do bad naming everywhere and anytime. It's simply the designer's job to do this properly, a good design includes good naming. Btw, interface MI actually requires exactly the same amount or less names, for every interface exactly one (because otherwise you won't get the same functionality). [Btw. same argument applies for single inheritance, every additional level hides the methods the ancestor implements in the same way. Is single inheritance bad because of that now?] I find it more clear to have if (A is IA) and (A is IB) then .. Instead of If (A is IC) then .. If you need to check for IA and IB regularly in your code, then it is easy to write a general-purpose function Function SupportsInterfaces(A : TInterfacedObject; Interfaces : Array of Interface) : Boolean; And then write if SupportsInterfaces(A,[IA,IB]) then Which is much more explicit about the properties you are actually querying. This is maybe more explicit for two interfaces, or maybe five. But please do _not_ tell me that for a hundred interface hierarchy (ok, you probably won't have to check all hundred at once). The compiler won't help you here, because he does not know that IA and IB have a logical connection and can't warn you that a (potentially) new ID is somehow related to IA and IB too and you missed it. Outright unrealistic what you suggest. Also, if your component needs more than, say, 5 interfaces, then I think you need to do some serious rethinking of your design. Even in OpenOffice (one of the more elaborate collections of interfaces I've encountered so far) there are few objects with SO many interfaces. It's not the number of interfaces the object actually exposes, it's the number of interfaces and the hierarchy itself which requires the shorthand notation. I don't know OOo code, or what particular part of the code you refer to, but I think I am able to counter your argument
Re: [fpc-pascal] is
Hello, Thomas Schatzl schrieb: Michael Van Canneyt schrieb: For example; MI for interfaces for me is strange (to say the least) because interfaces were introduced to avoid the mess of MI in the first place. So why on earth would you want to introduce it ?? Since interfaces do not have/inherit implementations by definition this is not an issue, they simply aggregate function *specifications* (no code). This is multiple _interface_ inheritance. Commonly considered good =) Maybe an elaboration of the Rat-example (well, grew to a mouse-example :) helps to clarify some problems you have with interface-MI: I marked the comments which talk about advantages this feature gives the programmer with (+) type TWasAcceptable = Boolean; IMammal = interface procedure sleep(); // a mammal can sleep end; IMeatEater = interface // a meat eater can eat function eat(m : TMeal) : TWasAcceptable; end; IPlantEater = interface // a plant eater can eat too function eat(m : TMeal) : TWasAcceptable; end; // something that can eat both plants and meat IEatsEverything = interface(IMeatEater, IPlantEater); IJumping = interface procedure jumparound(); end; // a mouse can sleep, eat something and wiggle with its // tail (and certainly much more =) IMouse = interface(IMammal, IEatsEverything) procedure wiggleWithTail(); end; Now I have several types of mice: // a mouse can do everything what a mouse is supposed to do // this class _implements_ the abilities TMouse = class(TAnimal, IMouse) procedure sleep(); procedure eat(m : TMeal); procedure wiggleWithTail(); end; (+) Don't need to specify that TMouse implements IMammal, IPlantEater, IMeatEater and 10 other interfaces as well. I hope you don't forget one. Can be remedied by a hierarchy of singly inherited interfaces, e.g. IPlantEatingMammal, IMeatEatingMammal, IAllEatingMammal, IMouseMammal, IJumpingMouseMammal, ... // for example's sake although Micky Mouse looks like a mouse // and can do the same things as the animal with the same // name it is not derived from TMouse (it is not an animal // after all) TMickeyMouse = class(TCartoonCharacter, IMouse, IJumping) procedure sleep(); procedure eat(m : TMeal); procedure wiggleWithTail(); procedure jumparound(); end; [...] Implement methods of classes. Certainly in completely different ways - while the mouse animal accepts maybe rotten meat, Mickey Mouse may not, but it eats edible meals. Maybe due to the ancestors (single inheritance!) the methods are already partially implemented as well. [...] (+) You may notice that although there's a name clash in the interface specification. Does not matter at _all_, because it's only a specification, e.g. has that method, don't care how it's implemented (***). (+) There's no problem with instantiation either because you simply do _not_ instantiate interfaces at all. It's only a specification of what this type can do. In the code using these classes I can now use instances of both classes (no news here, you could that with single inherited interfaces too). E.g. // gives *any* plant eater a meal to eat. Consider we have some cow // class which implements IPlantEater as well (and hence can eat too!) procedure eat_a_plant(obj : IPlantEater; plant : TPlantMeal); ... // gives the given object a meal. Since this is a generic meal, only // objects which can eat everything can eat here. No need to check // further in the code of the procedure whether the meal is of meat or // plant type, we can be sure it accepts it. procedure eat_just_something(obj : IEatsEverything; meal : TMeal); ... (+)Can't do that with singly inherited interfaces... (in this case it might be reasonable to check whether the meal is edible for planteaters/meateaters and maybe throw an exception) but actually it'd be natural. Consider the case when there's not only two types of things animal can eat... remember that case'ing doesn't work with interfaces. (+) Again: The fact that IEatseverything is multiply inherited (and the method signatures overlap) does not even matter. Interfaces are just specifications which are always bound on runtime // gives the mouse a meal and forces tail wiggling if it was // acceptable procedure eat_some_meat_and_wiggle_with_tail_if_ok(obj : IMouse; meat : TMeal); ... // lets the given mammal walk around procedure walkaround(obj : IMammal); ... --- What happens if you add another completely different animal? IFish = interface procedure swim(); end; IShark = interface(IFish, IEatsEverything); TShark = class(TFish, IShark) procedure swim(); procedure eat(m : TMeal); end; any method (which were originally designed for the hierachy of mammals) still work. You can feed the shark independent of being a shark (only interested that it can eat everything
Re: [fpc-pascal] is
Hello, I think I have to make some things more clear why I am in favor of that foreach: Thomas Schatzl schrieb: Features being developed now are: MI interfaces 90% (MI=multiple inheritance) Inclasses 15% (embedded classes) foreach 0% (well, we know you hate it) It's a useless statement if used for arrays, enumerations etc. It blows up the language for no gain. You are right, for arrays, enumerations etc. there is little to no gain. But I see the application of foreach on these types as added bonus, not the main thing. As far as I understand the proposal the main point for this construct is the use in iterable container classes (implementing a certain interface). And there it can show it's advantages (or what I think that are advantages): Instead of a very longish (syntax made up just now): var x : IIterable; someCollection : TSomeCollection; elem : TSomeElement; [...] x := (someCollection as IIterable).initIterator(); while (x.hasNextElement()) do begin elem := (x.nextElement() as TSomeElement).next(); do something with elem end; x.doneIterator(); [...] you could write: x : TSomeElement; someCollection : TSomeCollection; [...] foreach elem in someCollection do begin do something with elem end; [...] which is imo far easier to read. (Please don't mind the word foreach, I think it's only because it's already used in other languages for that purposes). The former is also less error prone in regard to using the iterator for the appropriate element (think of nested foreach's). It is typesafe too. It makes it easier to quickly change the actual type of (OO-)container if needed. And if basic Pascal types (arrays, sets, etc.) were allowed to be used in the same construct, then the programmer won't have to worry about syntax differences in using these basic types and OO-collections too. E.g. elem : Integer; someArray : array[X...Y] of Integer; [...] foreach elem in someArray do begin do something with elem, e.g. inc(elem); end; [...] or elem : TSomeEnumeration; someSet : set of TSomeEnumeration; [...] foreach elem in someSet do begin do something with elem end; [...] In case of sets this may not only be an abbreviation for the for-loop, but also element testing: for elem := low(someSet) to high(someSet) do begin if (elem in someSet) then begin dosomething end; end; Probably this also gives some additional opportunities for code optimizations. But in the end you're right, it's only an abbreviation for already existing functionality; I'd consider it useful though. Regards, Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] is
Hello, Probably this also gives some additional opportunities for code optimizations. Well, I bet people would cry if the iterator works randomly and not element by element :) Don't know why you're so focused at this point, but certainly, yes, they would =) but as I already mentioned, there's nothing against defining a natural iteration order for certain types which of course must be preserved during optimization. And this was just an idea. Maybe I'm misunderstanding you too, I'm not proposing optimizations which change iteration order (where it hurts, e.g. for arrays). In that specific cases more things like e.g. automatically knowing that any internal indices can never be referenced by the program. If this answer is not sufficient, I'd like to ask you to explain what you meant in other words; probably my English is too bad to understand you here, sorry. But in the end you're right, it's only an abbreviation for already existing functionality; I'd consider it useful though. I don't like those iterators anyways, they are too unspecific. What happens if you delete element where the iterator points to? What happens, if you delete an element while iterating? From what I read about STL problems (some forums, some tutorials), the STL iterator doesn't care about element deletion and element removal at all, their value must be considered unusuable after a structural modification of the container (and partially from what I see from simple element modification :). And there's also no indication of some notification returned if the iterator is accessed after a structural modification. So the STL doesn't give a good example in this matter too. For the unspecificness: well, we're currently discussing the options, don't we? My suggestion was to simply use the compatible way of Delphi/.NET as far as I remember it (which is specified and easily accessable via the web). But in the end I think it's manageable to get at least the same behaviour as the STL - by simply not caring about that at all... :-) Please correct me if I'm wrong, if possible with some definite reference, couldn't find one. Have a look at the STL, it has imo a much better iterator design. You're right, STL iterators are more powerful, but this is not because of their representation or their safety, but due to their other functionality not needed in this case. All those functions (even this comparison stuff) could be implemented using iterator interfaces (similar to STLs iterator types) and operators as well imo. Or similar to STL there's the possibility of using an iterator object. The IIterator _interface_ as used was just a proposal, which was given because Delphi/.NET has a similar one. The other drawback I can see is mostly due to FPC not having generics - certainly taking this into account this proposal is _really_ inferior, but better than nothing atm. And as soon as FPC supports generics, they can be used to remove unneeded dynamic type checks too. Maybe somebody else has more insight in the STL or knows other iterator implementations for more ideas. Either way, the original point was foreach after all, which is just a shorthand for a special type of traversal, using a special type of iterator (STL lingo: forward-iterator). It doesn't *need* a complete STL to do that. It's definitely not the ultimate concept solving every problem either ;) Another problem is probably that people would underestimate the overhead of the foreach statement. I don't see any overhead for basic types, since it's more or less an advanced macro for a for i := low(array) to high(array) do And in OO element access usually means calling some read method or some similar (forward-)iterator (in STL-lingo) method anyway... (even STL iterator methods result in method calls in the end) This is in my experience the case for at least anything else than a simple list backed up by an array (Borland's TList) where you can directly access the element via indices; and if you actually care about OO programming, e.g. doing information hiding. It's not slower than doing it manually either, or am I wrong? I guess you remember the list/resourcestring overhead trouble. If I may ask, what was the problem with tlist/resourcestring issue again? As far as I can remember, the real problem was something about FPC creating too much/inefficient exception support code, and/or the exception code generated by FPC optimizes for the (uncommon) exception case which slows down the app in the (common) non-exception case too (which is not needed). I don't see the connection here right now. You, as programmer, have the responsibility to choose the appropriate data structure for your task - definitely nothing new. This won't change that easily =) Regards, Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] interface is patch (finished and included)
[EMAIL PROTECTED] schrieb: Quoting Michael Van Canneyt [EMAIL PROTECTED]: On Thu, 31 Mar 2005, ml wrote: I have downloaded and checked the patch, however I'm not a compiler person. The RTL patch looks OK to me. have you checked what happens with an object passed through COM ? COM? as I already said. COM objects have assigned GUID, And refcount gets incremented by 2 for those (and refcount is handled by fpc, and not COM), off course if it would be the case of COM object there's nothing easier than check against IDispatch, as I see IDispatch should be the root of COM objects with no object in fpc behind No, the root of COM objects is IUnknown, IDispatch is optional for any COM object afaik. Regards, Thomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Question about interfaces and patch
Hello,
note in advance: if I mention CORBA interfaces, I actually mean CORBA
style or Java/.net like interfaces (which are not real CORBA interfaces
anyway) in the following (too lazy to do a searchreplace or find
another term).
[EMAIL PROTECTED] schrieb:
ml schrieb:
Hmmm, Delphi gives a compile time error if as is used on an interface
[...]
This is doable, patch can contain both with compiler directive for selection
(ok, usage of compiler error is not done yet). One other possibility is checking
some IClassUnknown (inherited from IUnknown) support and auto assign guid (at
least if not defined in interface) to it.
This check for COM-interfaces could be done on compile time saving
runtime (and code, and... :) if supports() or as is used in the code. Or
simply automatically assign a reasonable GUID for every COM interface
(probably easier =)
I don't know if checking for some class IClassUnknown is actually
required...
Maybe handle operators for CORBA interfaces completely differently (the
compiler already recognizes the type of the interface at compile time
from what I can see from the compiler code).
E.g. avoid using standard QueryInterface() (which may not be available
for CORBA interfaces anyway) for this type and completely rely on other
means for that.
But this would require more compiler tinkering.
In fpc sources there's a comment
if guid is 0 then corba_interface otherwise com_interface (I don't have my
notebook here so this is not copy pasted from source, just the meaning). Are
corba interfaces really guid 0 (if that would be the case then support and as
wouldn't work on corba interfaces in Delphi)
This is not true, since COM interfaces which don't have a GUID assigned
also have the default zero GUID.
But interfaces support seems to be at least partially broken for both
COM and CORBA interfaces, especially the supports() and as operators
(in the 1.9.8 compiler).
Btw, to implement unnamed properties of (non-COM) interfaces (as the one
available in objfpc mode) there's imo need for more sophisticated rtti;
e.g. so that this would work, you'd need a way to query the read and
write methods of the particular class of the instance and call them.
Neither querying of properties nor getting info on the read/write
methods of properties is possible atm since Object Pascal does not store
this info anywhere by default afaik (for all visibility types of
properties, for all Pascal objects).
[Maybe I'm wrong, I'm not so into rtti]
It is doable and in my plan. But I suspect it will just stay my own patch
for me
and whoever wants it (as some others interface patches of mine, like multiple
inheritance).
Actually I'd love to see a more complete RTTI in Pascal (say, e.g. in
OBJFPC mode), not minding the increased binary sizes (maybe optional).
Although I don't need it very often, the introspection information
offered by Delphi is quite limited (e.g. exactly to the explicitely
published things which Borland needed for the IDE).
Btw, MI for interfaces is completely fine for Corba interfaces, I had a
peek at the spec (well, I needed it for other things too ;). E.g. it's
completely fine to specify this:
interface A { ... }
interface B: A { ... }
interface C: A { ... }
interface D: B, C { ... }
interface E: A, B { ... };
[From the Corba core spec, v3.0: interface declaration, pg. 3-23]
Since an interface is only a specification without implementation I
don't see any troubles concerning multiple inheritance as pointed out in
another message of this thread (going towards Java/c# like interfaces).
Some additional safety things should be put into place to not allow
mixing them though (e.g. similar to not allow mixing old style objects
with new style classes).
appreciate some help by suggesting. And yes, this is a bug not a
feature.
Either automatically create a good GUID for the interface (there should
be a CreateGUID() method in fpc), or error out like Delphi (to be
compatible).
and good guid would be? If I remember correctly I saw GUID calculator for Delphi
Ones created by CreateGUID()? =)
but I don't remember where and if method implemented was official way of
calculating GUID (if this exists).
I think there's an RFC out there to calc UUIDs (which is the same as a
GUID) for DCE/RPC or so. But as far as I'm concerned it should be fine
to rely on the OS for that.
Usually part of the RPC implementation - for Windows I know that RPC is
used in any version. In case of some Unix (or other OS), if the required
libs are not available (can't really imagine that there's no standard
RPC implementation for that), use a good 128 bit random number from
somewhere.
for now I just assign max possible interface and decrement for every type.
This is bad, because this GUID is stored in every ppu file for the types
too. So if you use some external lib they will certainly clash (actually
I think they already do, probably making using interfaces quite
interesting for the person who debugs that code =)
But all this is only my
Re: [fpc-pascal]Compiler switches
Hello, I'd like to try using JEDI-SDL but the directions only tell how to set up the IDE... not how to use the command line compiler under Linux. I'm stumped on a few of them. I condensed the following from the JEDI-SDL Yahoo Group instructions and added what I think the corresponding command-line switch should be: Compiler switches page Delphi 2 extensions to ON Delphi compatibility to ON -Mobjfpc -Mdelphi -Mobjfpc and -Mdelphi are different things and mutually exclusive (when given as compiler switch). I guess that -Mdelphi is appropriate. - These I have no idea!! Assembler Reader to Intel style Assembler -Rintel Assembler Output to precoff. Probably this means pecoff, not precoff: -Apecoff Don't think that this compiler switch is required in this case. It just controls the output format - In this case generates win32 pe coff files, which is probably not suitable for a Linux environment. Add FPC to the conditional defines box at the bottom of the page. -dFPC Options | Linker. Preferred Library Type to Smart Libraries. The closest thing I could find for this is: -CXcreate also smartlinked library Should be correct. - Options | Directories. Unit directories box add path to where JEDI-SDL units exist. USE -Fi Yes. Regards, Thomas ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Delphi 9 language features...
Hello, Exactly, which is why I prefer the idea Borland has gone for. The STL is not a good idea. The behaviour of the d9 iterators appear to me very unspecific. In which I think this is because the origin of this information is only a blog entry, no specification... order does it iterate through the elements? What happens if I delete an element while iterating, maybe even the current. Does an iterator stay valid if I remove the element from the container? See below. How can I change how the iterator behaves? etc. Implement the interface methods for iterating over the class according to one's wishes I suppose. --- For Arrays: as indicated it's just a shorthand for a for i := low(arr) to high(arr) For IEnumerable: I guess they'll comply to the behaviour of the IEnumerable interface of .NET, so have a look there: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemcollectionsienumeratorclasstopic.asp Outline: - if the collection is changed while iterating over it, IEnumerable throws an exception - no inherent thread safety - behaviour (e.g. iteration order) specific to implementation I think this syntactic sugar construct is better than nothing: At least I make a lot of mistakes regarding lost -1 when specifying the upper bound when writing code to iterate over a TStringList or similar - or the imo stupid and repetitive for i := low(xy) to high(xy) do begin sequences all over the place in case of normal arrays. What's more interesting for me is that it seems that there will be a Delphi compiler emitting native code again... :-) Regards, Thomas One cent... ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Default calling convention
Hello, I noticed that, with FPC 1.9.4, the (default) calling convention register depends on the fact that a routine is or is not embedded in an other routine. With proc(A,B,C: Longint);, if proc is not embedded then eax = A, edx = B and ecx = C but if proc is embedded then edx = A, ecx = B and C is on the stack. Is this convention definitive or temporary? I am not sure it is definitive since it makes the code of assembler routines dependent on their status: embedded or not. This is exactly the same as Delphi (7) behaves. procedure nx_fill(P: PLongword; Count: Longint; Value: Longword); assembler; asm pushl %edi movl%eax,%edi // edi - P movl%ecx,%eax // eax - Value movl%edx,%ecx // ecx - Count rep stosl popl%edi end; In this case procedure nx_fill(P: PLongword; Count: Longint; Value: Longword); assembler; asm pushl %edi movlP,%edi // edi - P movlValue,%eax // eax - Value movlCount,%ecx // ecx - Count rep stosl popl%edi end; works both as embedded and non-embedded assembler procedure because the order of assignments is ok in both cases. Btw, there's already a method in the system unit which does the same thing as your routine: filldword()... Regards, Thomas ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Default calling convention
Marcel Martin schrieb: Peter Vreman a écrit : Check what Delphi does for nested procedures. If it is different from FPC then FPC will be adapted. Overall, no :-) Delphi (at least the version 5.01) is bugged. [example code snipped] Interestingly, D7 has the same bug. I think the best thing that could be done would be to manage so that FPC always makes use of [ebp-something] to access a parameter when the programmer makes use of the parameter name, i,e., with any calling convention the instruction mov eax,param should never be coded as mov eax,reg but always as mov eax,[ebp-something]. See the other answer about the 'pascal' modifier. Regards, Thomas ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Default calling convention
Hello, In this case procedure nx_fill(P: PLongword; Count: Longint; Value: Longword); assembler; asm pushl %edi movlP,%edi // edi - P movlValue,%eax // eax - Value movlCount,%ecx // ecx - Count rep stosl popl%edi end; works both as embedded and non-embedded assembler procedure because the order of assignments is ok in both cases. Yes, but this way a program becomes a mineland. You write this, a few weeks later, for some reason, you change the line order, and you waste time to find why, suddenly, your program crashes (and yet, assuming you immediately activate the bug). :( That's true. I usually add a 'pascal' procedure modifier to most (if not all) assembler routines exactly because of that. This forces parameter passing on the stack. This is a little slower, but if your hand-coded assembler proc is only faster if the parameters are passed through registers, it might be a good idea to use Pascal right away... Regards, Thomas ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Windows unit problems
Hello, I'm attempting to retrieve information about the current resolution settings, but I'm not having much luck. I've downloaded the Borland Win32 API, but I'm still stuck with creating the device context, and so on. I need some massive help with this... =( Because the Borland help file is really outdated... use either the online MS-Platform SDK help (or alternatively the search engine of your choice =) or download it from MS. Here's a small program which prints the screen characteristics you need to the console (no need to fiddle around with device contexts, no error handling): program PrintScreenCharacteristics; uses Windows; var mode : TDevMode; const // this constant does not seem to be defined in my FPC distro ENUM_CURRENT_SETTINGS = $; begin EnumDisplaySettings(nil, ENUM_CURRENT_SETTINGS, mode); writeln(mode.dmPelsWidth, 'x', mode.dmPelsHeight, 'x', mode.dmBitsPerPel, '@',mode.dmDisplayFrequency); readln; end. See the MS-docs for this function for further explanation. Compiles and runs with FPC 1.9.3 - 2004/04/09. Regards, Thomas ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Message methods - DefaultHandler
Hello,
I have some problem with DefaultHandler method. When I pass a
message for which is special handler defined everything is ok, but when
it should be passed to DefaultHandler (which is overriden) it does
nothing. Here is some sample code:
{$MODE OBJFPC}
type TMyMessage = record
MSGID : cardinal;
text : string;
end;
TTest=class(TObject)
constructor Init;
procedure Handle (var MyMessage : TMyMessage); Message 1; virtual;
procedure DefaultHandler(var MyMessage : TMyMessage); virtual;
destructor Done;
end;
It should write two times the Hello world message. For the first time
from
method TTest.Handle, and for the second time from method
TTest.DefaultHandler. But TTest.DeafultHandler doesn't do anything
(it writes only one message).
The DefaultHandler method has a wrong signature and so your method is not
called. You have to override
procedure Dispatch(var Message); override;
and use a typecast in the method implementation, e.g.
procedure TTest.DefaultHandler(var MyMessage);
begin
writeln(TMyMessage(MyMessage).Text);
end;
Note that Delphi (don't have FPC installed on this machine, sorry) complains
that message methods may not be declared as virtual (doesn't make much sense
imo, since dispatching a message to an object always is bound dynamically
using the message identifier).
Hth,
Thomas
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Farpointers Was: Re: RE: [fpc-pascal]Problem with CASE statement
Hello, Second - new FPC v1.9.x for statement var p:pointer p:=Ptr(a,b); shows error Incompatible types: got FarPointer expected Pointer. I found i can declare var p:farpointer; but i did not found any description for this type of pointer how can i use it. It seems that the syntax and semantics of this function changed with later FPC-versions to something actually useful... ;-) A Farpointer is a pointer consisting of a 16 bit selector and 32 bit offset, while in BP the Ptr() function expected a 16bit/16bit segment:offset. This is due to different memory models in 32 bit protected mode of FPC and 16 bit real mode in BP/TP. There is no fully compatible automatic way to handle these problems. In short, you usually don't ever need the Ptr() - function in FPC because all memory is addressed linearly through a single 32 bit address, just use p := @avariable if you want to create a pointer to some memory area. It was sometimes required in BP/TP because of memory segmentation in BP programs. Otoh if you want to access specific memory areas in the real mode memory area (lower 1MB of memory) you need to do some sort of translation. See the go32 - documentation for further details (there is some information about the farpointer stuff as well iirc) if you just want to port your TP/BP DOS application to the go32v2 target. For the others such a way of accessing memory will not be allowed by the OS anyway (or is limited) and is impossible to do without lots of application and OS specific code. Eventually this will give you a farpointer to the DOS memory location you want to access: uses go32; var p : farpointer; // this syntax is just a guess. p := Ptr(getfs(), a shl 4 + b); getfs() returns a selector which by default describes the DOS memory area. Note that while constructing a pointer to this area might work in all cases, any NT-based OS might prevent access. At least it will be slow. Don't even consider using this on e.g. *nix systems. Regards, Thomas ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]high performance counter for dos/tp7
Hello, But ehm... it seems your website is locked... unable to view/download code etc :) I thought I'd let you know just in case you forgot to unlock it =D No, this is a public website and I checked the URL I gave you, it works fine from my place. Same goes for the links to the sources, none of them is broken. Regards, Thomas ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]high performance counter for dos/tp7
Hello, So a computer calling an interrupt routine a million times (for microsecond accuracy) that does not seem like a good idea performance wise. Also calculating the control word (?) can be inaccurate (?): control_word := $1234DD div frequency; ( ??? what about the remainder ??? ) So I don't really need any interrupts... I only need to be able to read some sort of thing that gives me a tick count and possible a tick frequency. What are my alternatives for dos/turbo pascal 7 ? Off topic. ( What about 32 bit free pascal :D ? ) Search for Thomas Schatzl's (originally zen-)timer and CPU units. Probably a link is on the contributed units page. For FPC/Delphi on a few platforms there is my CPU unit, always available via my homepage at http://members.yline.com/~tom_at_work/index.html . On the same site there's reasonable good documentation available for it; although it dates back to '2001, it's still up to date since nothing else except that it can detect a few more hardware capabilities. All these changes can be found in the accompanying docupd.txt text file... Basically it offers an OOP timing interface with microsecond accuracy (well, depending on your machine due to some calculation overhead and the usual OS considerations) for most supported x86 FPC platforms I think. Since it is based on the processor's TSC, which counts clock cycles, it is quite useable imo. For the purists it offers direct access to the TSC value as well. For BP/TP the situation is as follows (as far as I remember it now and can trace it back from my sources)... history, skip if not interested; hopefully not too off-topic either Once upon a time =) there had been some C library called ZenTimer (by M. Abrash iirc, if you ever heard that name), which used the DOS BIOS timer tick counter you mention, and by accident I came across a BP conversion (iirc done by some demo coder whose name I don't know anymore and I can't finde the original sources anymore either). Since at that time FPC was still in its infancy *g* I ported it for the go32v1 target (a predecessor to the current go32v2) with the same name, added a few things (most notably more accurate TSC support for Pentiums) until it came to version 1.15 (this had been 8.11.'98...) - at that time I decided to give it a little more flexible OO interface, the first incarnation of the CPU unit was born (still FPC only, but with time additional OS/2 + Linux support as I can see from history logs) Some time later (actually nearly exactly 4 years ago), at the time the cpu vendors (AMD, Cyrix, Intel, ...) started to go in different directions concerning CPU features, detection etc. so there had been a new instance of my CPU unit with a different API + core that requires much less adaptions for new processors / processor generations. This version still serves its purpose and should work fine with current FPC releases. Basically meaning that... /history ... there has never been an official CPU or Zentimer unit for TP/BP from me (except probably very early non-public versions of the ZenTimer unit which I don't have anymore)... ... but afair S. Goehler backported a some version of my CPU unit to TP/BP for his Grafx-unit, can't remember which version (so use your favourite search engine on these keywords :-) Regards, Thomas ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]feature request: enhanced pos
Hello,
x := pos ('Hello', my_str, 6);
PosEx() from strutils?
Cant find it in strutils..
Just checked the sources again, at least the 1.9.x branch contains a PosEx
method, line 93ff, from today's sources =)
Regards,
Thomas
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]exception handling
Hi again, spent a few moments going over the docs in the manual re: exception handling. for some reason it just doesn't seem to be sinking in, as nothing i've tried as of yet has managed to stop prog from crashing when data in input that's of a different type than program is expecting (string as opposed to integer, for example). [...] - did you include the sysutils unit? - afaik readln just raises runtime error which is unspecified according to the docs; eventually an EIOError (or similar if this does not exist) because this behaviour can be turned on/off with $I+/-. But to be sure, you might want to catch general exceptions. - do the following: s: String; i : Integer; code : Word; try readln(s); i := StrToInt(s); catch on EIOError ... end; Obviously it should mean on EConvertError... here because StrToInt raises an EConvertError when the string does not represent a valid integer (see docs) Not an EIOError, this one probably slipped in because I was talking about catching an I/O Error in the other variants... Sorry, Thomas ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]exception handling
Subject: [fpc-pascal]exception handling
spent a few moments going over the docs in the manual re: exception
handling. for some reason it just doesn't seem to be sinking in, as
nothing i've tried as of yet has managed to stop prog from crashing when
data in input that's of a different type than program is expecting
(string as opposed to integer, for example).
as i said, i'm pretty sure that its something really small and obvious,
i'll include a few lines here ... maybe someone can spot my mistake ...
pretty sure its the EConvertError and that there's a pre-defined error
type that I just haven't come across yet.
try
readln(NewAlbum.Year);
except
on EConvertError do NewAlbum.Year := 0;
end;
- did you include the sysutils unit?
- afaik readln just raises runtime error which is unspecified according to
the docs; eventually an EIOError (or similar if this does not exist) because
this behaviour can be turned on/off with $I+/-.
But to be sure, you might want to catch general exceptions.
- do the following:
s: String;
i : Integer;
code : Word;
try
readln(s);
i := StrToInt(s);
catch
on EIOError ...
end;
or
{$I-}
readln(i);
{$I+}
if (IOResult 0) then ... // IOResult (hopefully) contains an error
number in case of an I/O error
or
readln(s);
val(s, i, code);
if (code 0) then Error...
But this has not been verified but it should be about right
Regards,
Thomas
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]several questions
Hi,
Can you only have 2 files open with FP? As above, I fixed my problem
with opening the third file by closing another, and only having 2 open at
once. My config.sys has FILES=20, so it's not a DOS limitation by the
look of it (unless my FP program is opening up another 18 related system
files behind the scenes. e.g. units or something).
Probably another 18 files have already been opened by the OS (device drivers
etc) - try setting FILES higher and test again. FPC programs don't allocate
any new file resources by default afaik.
I also wanted to know if there's a colour palette somewhere? Or a list
of the text-names that can be used with textcolor?
Try the constants in crt.pp - you can set the color of a specific cell by
setting textattr to the value of (background-color shl 4) or
foreground-color.
E.g. have a look at the output of the following program:
uses
crt;
var
i, j : Integer;
begin
for i := 0 to 15 do begin
for j := 0 to 15 do begin
textattr := i shl 4 + j;
Write('A');
end;
WriteLn;
end;
readln;
end.
Iirc in DOS the character cell blinks if the high bit of textattr is set
(meaning that you're basically stuck with the first 7 background colors).
You can disable blinking by calling int 10h with ax=$1003 and bl=$1 (enable
again with bl=$0)
When I run pascal programs (not just FP, but other compilers too), the
last text-colour I used stays even after the program is finished. The
original default colour only returns after I call something else. e.g.
DR-DOS editor.
FPC doesn't use the BIOS functions for drawing text characters in DOS - so
the original text attributes should be preserved after exiting for new text.
It leaves the current contents as they are by default though, this is
normal.
Regards,
Thomas
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]EOF function
Hi,
The following (attached) is a programming problem I've implemented.
Now I know the way I've done the EOF test is not correct, otherwise it
would not crash with a runtime error of 106.
It doesn't crash here as long as only valid integers are entered. The doc
for RTE 106 reads: Invalid numeric format: Reported when a non-numeric
value is read from a text file, when a numeric value was expected.
The standard input is never closed during the program - so you will never
get an eof from it (by entering normal characters).
Could someone show me the correct way of reading from stdin until there
is no more input ?
You have to parse the input yourselves, for example like this (beware:
quickdirty code and assuming that with no more input you mean an empty
line):
procedure ParseString(s : String; var i, j : Integer);
begin
val(Copy(s, 1, Pos(' ', s)-1), i);
Delete(s, 1, Pos(' ', s));
s := TrimLeft(s);
val(s, j);
WriteLn(i, ' ', j );
end;
var
i: longInt;
j: longInt;
s : String;
begin
repeat
readln(input, s);
s := TrimLeft(TrimRight(s));
if (s '') then begin
ParseString(s, i, j);
writeLn(getMaxCycle(i, j));
end;
until (s = '');
end.
This is required when using stdin only - on normal text files the eof is
reported properly and your way of reading in data using read(ln) works. (As
long as the input is correct).
Hth,
Thomas
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]class variable
Hi, Great! But does -St also contain the parameters of -S2/-Sd? Or can we use them at them at the same time? fpc -St -Sd aaa.pp? Yes you can. Regards, Thomas ___ fpc-pascal maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal]Classes/Objects/Pointers / Pointer Help
From: James Mills [EMAIL PROTECTED]
Sent: Monday, February 10, 2003 2:04 PM
Subject: Re: [fpc-pascal]Classes/Objects/Pointers / Pointer Help
Hi,
Yes ok, fair enough, this much is in my knowledge of Pascal :) hehe, but
the real question is, how do you create these objects on the fly in a
program, ie: dynamic array...
I have tried using plain objects, and have failed in frustration. When
you suggested using classes, it worked right away (of course :P).
If you're bound to 1.0.6 which doesn't support dynamic arrays by using
compiler magic you have to do it like this:
---
program Project1;
uses
SysUtils; { IntToStr() }
type
PMyObject = ^TMyObject;
{ note: this is our template for our object container array. With the
upper bound set to zero you might get range check errors while
compiling and run time errors if you turn runtime range checking on...
You could set the upper bound to a ridiculously high value if this
disturbs you (since it's just a template and not really allocated
anywhere). I assume that the number of elements is dynamic though, so
if you *know* that you only need 5 elements max it's better to say
that here.
Better might be using dynamic arrays available in FPC 1.1 than this
construct. And even better might be (depending on your needs)
other concepts to store data dynamically, e.g. linked lists (see
the 'net or any introductionary algorithm book).
}
TMyObjectArr = array[0..0] of PMyObject;
{ big note: better use the Object pascal 'classes' concept instead of
'objects'... see FPC reference guide chapter 4 and 5 respectively - but
I'll stick to old-fashioned objects here :-) }
TMyObject = object
private
fString : String;
public
constructor Init(s : String);
{ note: the empty brackets after methods are sort of personal coding
convention }
destructor Done();
procedure DoSomething();
end;
constructor TMyObject.Init(s : String);
begin
Writeln('Calling Init...');
fString := s;
end;
destructor TMyObject.Done();
begin
Writeln('Calling Done...');
end;
procedure TMyObject.DoSomething();
begin
Writeln(fString);
end;
var
dynObjArr : ^TMyObjectArr;
i : Integer;
begin
{ initialize container (assume we need 5 elements) }
getmem(dynObjArr, sizeof(PMyObject) * 5);
{ since we overwrite all elements later on this isn't really required }
for i := 0 to 5-1 do begin
dynObjArr^[i] := nil;
end;
for i := 0 to 5-1 do begin
dynObjArr^[i] := new(PMyObject, Init('Hello World (' + IntToStr(i) +
')'));
end;
{ []
display a few of the elements in the array... }
Writeln('Looking what''s inside...');
for i := 2 to 5-1 do begin
dynObjArr^[i]^.DoSomething();
end;
{ []
free the 2nd element (index 1) }
Writeln('Freeing one element...');
dispose(dynObjArr^[1], Done());
{ convention: invalid element entries are nil'ed; if you iterate
over the element to do something with them *don't* call nil'ed
elements... (didn't check this here in all the output loops at all
though) }
dynObjArr^[1] := nil;
{ stick another one in its place }
Writeln('Putting another element into the array...');
dynObjArr^[1] := new(PMyObject, Init('Good Bye'));
{ display them all again }
Writeln('Looking what''s inside...');
for i := 0 to 5-1 do begin
dynObjArr^[i]^.DoSomething();
end;
Writeln('Removing everything...');
for i := 0 to 5-1 do begin
dispose(dynObjArr^[i], Done());
end;
{ remove container }
freemem(dynObjArr, sizeof(PMyObject) * 5);
readln;
end.
-
I hope this addresses your questions.
Regards,
Thomas
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
