Re: [fpc-devel] New language idea: Unified types(assignmentsize-compatible types).
On 21 June 2011 13:09, Hans-Peter Diettrich drdiettri...@aol.com wrote: A LongWord will always have 32 bits, because it's a concrete type. Instead Integer, Cardinal, Char, String or Real can vary with every compiler version or target platform, because these are *generic* types. Um, I think you are mistaken. Integer is *always* 32-bits on either 32-bit or 64-bit target platforms. NativeInt is different sizes on different target platforms. I think LongWord also varies in size based on target platform, though not 100% sure on this one. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New language idea: Unified types(assignmentsize-compatible types).
On 26.06.2011 09:49, Graeme Geldenhuys wrote: On 21 June 2011 13:09, Hans-Peter Diettrichdrdiettri...@aol.com wrote: A LongWord will always have 32 bits, because it's a concrete type. Instead Integer, Cardinal, Char, String or Real can vary with every compiler version or target platform, because these are *generic* types. Um, I think you are mistaken. Integer is *always* 32-bits on either 32-bit or 64-bit target platforms. NativeInt is different sizes on different target platforms. I think LongWord also varies in size based on target platform, though not 100% sure on this one. No, LongWord does not vary. It's always 32-Bit. But Hans-Peter is right so far that Integer was originally considered a generic type. You can still see this if you do a SizeOf(Integer) once in mode FPC (2 bytes) and in mode ObjFPC (4 bytes). I didn't test SizeOf(Cardinal) in mode FPC yet though... Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New language idea: Unified types(assignmentsize-compatible types).
Graeme Geldenhuys schrieb: On 21 June 2011 13:09, Hans-Peter Diettrich drdiettri...@aol.com wrote: A LongWord will always have 32 bits, because it's a concrete type. Instead Integer, Cardinal, Char, String or Real can vary with every compiler version or target platform, because these are *generic* types. Um, I think you are mistaken. No. Integer is *always* 32-bits on either 32-bit or 64-bit target platforms. It *happens* to have 32 bit there. On 16 bit platforms (TP, Delphi 1) it was 16 bit. I'm not sure when Delphi changed that to 32 bit, perhaps not before D3. NativeInt is different sizes on different target platforms. I think LongWord also varies in size based on target platform, though not 100% sure on this one. In Delphi (XE) NativeInt has the CPU register size, assuming that data and address registers have the same size (i.e. unsegmented pointers). LongWord still is documented as a fundamental (non-generic) 32 bit type. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New language idea: Unified types(assignmentsize-compatible types).
In our previous episode, Graeme Geldenhuys said: Um, I think you are mistaken. Integer is *always* 32-bits on either 32-bit or 64-bit target platforms That's because FPC currently only supports LP64 and LLP64 systems. There are some systems (IIRC some AIX editions) that are ILP64 (iow in C int is 64-bit). What FPC will do there is probably still undecided, since it will be a dilemma between compatibility with the OS it is running on vs compatibility with other FPC targets. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New language idea: Unified types(assignmentsize-compatible types).
On 26 June 2011 14:03, Hans-Peter Diettrich wrote: Integer is *always* 32-bits on either 32-bit or 64-bit target platforms. It *happens* to have 32 bit there. On 16 bit platforms (TP, Delphi 1) it was 16 bit. I'm not sure when Delphi changed that to 32 bit, perhaps not before D3. The point I was trying to make is that it is NOT going to become a 64-bit type in Delphi 64-bit (one day when it actually arrives). And neither is it a 64-bit type under current 64-bit FPC as far as I remember. It might have been a generic type in the 16/32 bit days, but it isn't any more in the 32/64 bit FPC/Delphi compilers. Anyway, this is what I remember from a discussion a few months back with Michael van Canneyt. He even pointed me to the newly updated docs for the FPC types mentioning the same thing - I still had older FPC documentation printed out which was wrong at the time (hence my confusion). -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New language idea: Unified types(assignmentsize-compatible types).
On 26 Jun 2011, at 13:35, Marco van de Voort wrote: What FPC will do there is probably still undecided, since it will be a dilemma between compatibility with the OS it is running on vs compatibility with other FPC targets. I'm fairly sure we'd keep the definition the same as on other platforms. For OS interoperability we have the ctypes unit. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New language idea: Unified types(assignmentsize-compatible types).
In our previous episode, Jonas Maebe said: What FPC will do there is probably still undecided, since it will be a dilemma between compatibility with the OS it is running on vs compatibility with other FPC targets. I'm fairly sure we'd keep the definition the same as on other platforms. As long as a majority platform doesn't change, probably indeed. (if only that it would require a significant hardening of the RTL and core packages) Anyway, for me it is hard to predict what will work and what will break. Do we know how gcc deals with such targets? For OS interoperability we have the ctypes unit. Hmm. I just looked around a bit, and noticed that the ctypes unit doesn't alias the C types (unix/ctypes.inc) the *nix rtl exports. (via e.g. unixtype and aliasctp.inc). In such case where RTL and external interpretations vary this might have to be fixed. (I'm wondering if it originally were aliases) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New language idea: Unified types(assignmentsize-compatible types).
On 26/06/2011 13:03, Hans-Peter Diettrich wrote: It *happens* to have 32 bit there. On 16 bit platforms (TP, Delphi 1) it was 16 bit. I'm not sure when Delphi changed that to 32 bit, perhaps not before D3. The change was in D2. Delphi 2 was the first 32 bits Delphi. Paulo Costa ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpVectorial PDF Writer
Hello, If you are willing to work on it too, I can help you write a pdf exporter. It should be easy, you just have to take an example document plus the Adobe documentation. PDF is just text plus an eventual zip compression. The drawing itself is just plain PostScript which is also simple. -- Felipe Monteiro de Carvalho ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpVectorial PDF Writer
- Original Message - From: Felipe Monteiro de Carvalho felipemonteiro.carva...@gmail.com To: Leonardo M. Ramé martinr...@yahoo.com; FPC developers' list fpc-devel@lists.freepascal.org Cc: Sent: Sunday, June 26, 2011 2:54 PM Subject: Re: [fpc-devel] fpVectorial PDF Writer Hello, If you are willing to work on it too, I can help you write a pdf exporter. It should be easy, you just have to take an example document plus the Adobe documentation. PDF is just text plus an eventual zip compression. The drawing itself is just plain PostScript which is also simple. Ok, I'll try to start the exporter as my next weekend project. Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpVectorial PDF Writer
Felipe Monteiro de Carvalho schrieb: If you are willing to work on it too, I can help you write a pdf exporter. It should be easy, you just have to take an example document plus the Adobe documentation. PDF is just text plus an eventual zip compression. Be warned, the Adobe documentation is incomplete in some subtle details. E.g. the Length of an Stream is specified so vaguely, that the stored Length (observed) frequently is something between the number of data bytes with or without embedded EOL markers. See the PDF spec, 7.3.8.2 Steam Extent. Such flaws can prevent the decoding of a PDF document, because the exact stream decoder is a secret of Adobe (like details of .NET are Microsoft secrets). Please let me know when somebody finds source code of an PDF parser, that e.g. allows to extract the exact page count from any PDF document. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
