Re: [fpc-devel] integer, cardinal
Ales Katona wrote: > I think that pascal typesystem requires a bit overhaul when it comes to > integers. > > First of all Integer should be size independent, that is, xy bits > depending on the platform. All others should be specific. I agree with an application wide integer/cardinal type, but there should exist a way to get integers of a minimum size, as required by a specific program. One may use range types for that purpose, which the compiler can extend to the next "optimal" byte count, but doing so should not result in too much range checking. > Second, we should "force people in a friendly way" to use more readible > names like: > sint32, uint64, etc. than "cardinal" Not necessarily, when integer and cardinal for themselves are sufficient. What's the reason for using explicitly sized variables, of different sizes? I can see only one purpose, in the I/O of records in binary files. But with regards to different byte orders, reading structured blocks of binary information is not portable. > In a few years when 64 bits are normal, what will cardinal become? who > knows.. 32 bit integers will continue to be sufficient for most purposes. Arrays with more elements are not very likely in the next few years, 64 bit integers will be restricted to few special purposes (file size). DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] problem with "is" operator
Linuxer Wang wrote: > > Hello, > > Can anybody tell me how can I know which specific type an instance of > class is? Check the ClassType or ClassName. > The "is" operator seems weird when interface is used. Add a GetObject method to your interfaces, that returns the object that implements the interface. Then you can use the class specific checks. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] problem with "is" operator
> >Sometimes I added a GetUnderObject() to my interfaces to get the actual > >object. But it's a choice up to the interface author. > >BTW I needed it to release the object through the interface. > >I suspect that if you shouldn't ever need to know the actual class when > > using interfaces (maybe apart debug reasons). > > I don't agree with you fully. Let's have a look at java, its > "instanceof" semantic is complete. But the "is" semantic of FPC is not > complete. > What you said maybe true in design patterns, but not so true in language > sematics. Java, .net, python use "late binding". Delphi, fpc and C++ no. "late binding" is very useful but definitely slow. Maybe Delphi interfaces could have retained a pointer to the underlying object, but they didn't. As a matter of fact there was an article on DelphiMagazine to show how to grab the vmt of the object of an interface, via dirty magic of pointers arithmetics. Maybe in fpc it'd be in a cleaner way, but why? Bye Uberto ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bugreport: FPC 1.9.8 installer, i386-FreeBSD
On Mon, 18 Apr 2005, Andres K. Foerster wrote: > Am Montag, dem 18. Apr 2005 schrieb Marco van de Voort: > > > > > > Or better rewrite it to be usable with a standard-shell. > > > > > > > > I prefer not, it is not worth the effort. > > > > > > I'm going have a look at it this week. > > > Shall I send it to the list, or to whom? > > > > Look first what needs to be done. The result must be maintainable. (keep in > > mind that most other devels must be able to maintain and test it) > > Oh, I'm surprised myself. There are just few things to fix: > > The script sometimes uses one "=" and sometimes two "==" for comparisions. > The /bin/sh of FreeBSD accepts just one "=" in comparisions. > See test(1). > > "echo -n" is supported in the shell of FreeBSD, but it's not standard. > You could use "printf" instead of "echo -n". That seems more > standardized. > > Also the tar parameter "--directory" is a extension of GNU-tar. > You could use "-C" instead of "--directory", but be careful with that. > It seems "-C" is implemented differently. > (My FreeBSD still comes with GNU tar, but I've heard that they switch > to their own version of tar... I'll have a look at it.) > > That's all as far as I can see. > Then you can use "#!/bin/sh". Changed #!/bin/sh to #!/usr/bin/env sh And applied all suggested changes. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bugreport: FPC 1.9.8 installer, i386-FreeBSD
> Am Montag, dem 18. Apr 2005 schrieb Marco van de Voort: > > > > Shall I send it to the list, or to whom? > > > > Look first what needs to be done. The result must be maintainable. (keep in > > mind that most other devels must be able to maintain and test it) > > Oh, I'm surprised myself. There are just few things to fix: Thnx. Added to the wiki: http://www.freepascal.org/wiki/index.php/FreeBSD_specific_Release_Engineering I'll keep it in mind while building next release. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] integer, cardinal
> Vinzent Hoefler wrote / nap?sal (a): > >>In a few years when 64 bits are normal, what will cardinal become? > >>who knows.. > >> > >> > > > >That's why Pascal has range types. Define the range you need, and don't > >use "just some type" which has the range you think you will need. > > > And how about ABI and API compatibility? Is no problem. Simply define API's using the full types, and conversions and checks are automatic. The mapping of subranges to sizes is automatic (and typically the size is simply the base type, integer) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] problem with "is" operator
Uberto Barbini wrote: It does not seem right to declare var inst: TMyInterface if you want inst to have circles and squares as values. I would expect that you also have a class TFigure, of which TCircle and TSquare both are descendants. These could also implement TMyInterface. You then declare var inst: TFigure and can do inst := TCircle.Create. If so, why bother with Interfaces? You need interfaces exactly when you cannot define a common ancestor for two classes with similar behavior. The classical example is IFly implented by TBat and TSwallow. TCircle.Create. How can I know which instance is inst? The following code can not even compile: if inst is TCircle then ... class type expected, but got "TMyInterface" Incompatible type for arg no. 2: Got "TMyInterface", expected "TObject" The type of inst needs to be a class type (such as TFigure above), not an interface object type. If you do as I suggest above, it should work. if inst is TCircle then ... I don't think this can possibly work in fpc or Delphi. Apart tecnical problems, it'd be plainly wrong: using interfaces you lost the rights to know the original class. Sometimes I added a GetUnderObject() to my interfaces to get the actual object. But it's a choice up to the interface author. BTW I needed it to release the object through the interface. I suspect that if you shouldn't ever need to know the actual class when using interfaces (maybe apart debug reasons). I don't agree with you fully. Let's have a look at java, its "instanceof" semantic is complete. But the "is" semantic of FPC is not complete. What you said maybe true in design patterns, but not so true in language sematics. Bye Uberto ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bugreport: FPC 1.9.8 installer, i386-FreeBSD
Am Montag, dem 18. Apr 2005 schrieb Marco van de Voort: > > > > Or better rewrite it to be usable with a standard-shell. > > > > > > I prefer not, it is not worth the effort. > > > > I'm going have a look at it this week. > > Shall I send it to the list, or to whom? > > Look first what needs to be done. The result must be maintainable. (keep in > mind that most other devels must be able to maintain and test it) Oh, I'm surprised myself. There are just few things to fix: The script sometimes uses one "=" and sometimes two "==" for comparisions. The /bin/sh of FreeBSD accepts just one "=" in comparisions. See test(1). "echo -n" is supported in the shell of FreeBSD, but it's not standard. You could use "printf" instead of "echo -n". That seems more standardized. Also the tar parameter "--directory" is a extension of GNU-tar. You could use "-C" instead of "--directory", but be careful with that. It seems "-C" is implemented differently. (My FreeBSD still comes with GNU tar, but I've heard that they switch to their own version of tar... I'll have a look at it.) That's all as far as I can see. Then you can use "#!/bin/sh". -- AKFoerster ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] problem with "is" operator
> It does not seem right to declare var inst: TMyInterface if you > want inst to have circles and squares as values. I would expect > that you also have a class TFigure, of which TCircle and TSquare > both are descendants. These could also implement TMyInterface. > > You then declare var inst: TFigure and can do inst := TCircle.Create. If so, why bother with Interfaces? You need interfaces exactly when you cannot define a common ancestor for two classes with similar behavior. The classical example is IFly implented by TBat and TSwallow. > > TCircle.Create. How can I know which instance is inst? The following > > code can not even compile: > > > > if inst is TCircle then ... > > > > class type expected, but got "TMyInterface" > > Incompatible type for arg no. 2: Got "TMyInterface", expected "TObject" > > The type of inst needs to be a class type (such as TFigure above), not > an interface object type. If you do as I suggest above, it should work. if inst is TCircle then ... I don't think this can possibly work in fpc or Delphi. Apart tecnical problems, it'd be plainly wrong: using interfaces you lost the rights to know the original class. Sometimes I added a GetUnderObject() to my interfaces to get the actual object. But it's a choice up to the interface author. BTW I needed it to release the object through the interface. I suspect that if you shouldn't ever need to know the actual class when using interfaces (maybe apart debug reasons). Bye Uberto ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] integer, cardinal
Vinzent Hoefler wrote / napísal (a): On Sunday 17 April 2005 10:45, Ales Katona wrote: First of all Integer should be size independent, that is, xy bits depending on the platform. I second that. Second, we should "force people in a friendly way" to use more readible names like: sint32, uint64, etc. than "cardinal" No. Such stuff is only needed when you do hardware-interfacing. And that's the _only_ reason someone would need types with defined bit-sizes. In a few years when 64 bits are normal, what will cardinal become? who knows.. That's why Pascal has range types. Define the range you need, and don't use "just some type" which has the range you think you will need. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel And how about ABI and API compatibility? Ales ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] integer, cardinal
On Monday 18 April 2005 10:32, Marco van de Voort wrote:
> > On Monday 18 April 2005 09:02, Marco van de Voort wrote:
> > >
> > > I typically use enums. They suffer from the same to-disk problem
> > > though, but that can be remedied using the proper directives.
> >
> > Well, I don't think I will ever use enums to define things like
> > frequency limits.
>
> Since I don't use 16-bit systems, and frequencies above 2GHz are not
> my domain that is not really a problem for me.
That's not what I meant. The problem arises when the actual code is
wrong and the supposed limit is reached. That's what a range check
really is for. :)
I consider:
|type
| Crossfeed_Ramp = 300 .. 1000;
still more readable than the declaration of explicit constants and the
use of "just some int" variables. The point is in such cases I even
don't care what size any variable of that type would be, because here
it simply doesn't matter. Of course, such types are definitely not
useful when you want to store them in files, exactly for the same
reason.
> There are similar things already defined in unit ctypes. This way you
> can for FPC make even this unit independant of what happens with
> integer/qword etc, because the unit is adapted per platform.
>
> So
>
> {$ifdef FPC} // 1.9.x +
> mysint8type = ctypes.cint8;
> myuint8type = ctypes.cuint8;
> {$ELSE}
> // inferior compilers ( :-) )
> {$endif}
Yeah. But I'm somehow afraid of the "C" in it. ;-)
> > Alas, AFAICS there is no way to define the range and the storage
> > size of a type independent from each other in FPC?
>
> No. Only 1,2,4,8 sized integer types exist, in both flavours, and in
> ctypes identifiers are predefined.
Yes. I understand that FPC has no notion of biased representation, but
sometimes it still can be useful to define a constrained type with a
certain range but still give the size independently (and set it to four
bytes for instance, even if the type definition itself would allow a
smaller size).
> Other sizes are rarely used (3 byte sometimes in RGB handling code),
Hmm, rarely, yes. Still I once had to interface to a DSP56K, which has a
native word size of 24 bits.
> and would only unnecessarily complicate the codegeneration.
Agreed, but usually I am looking at all that stuff from the view point
of the programmer and not of the compiler-writer.
> > > And it is a lot more laborous.
> >
> > Well, that's not really an argument (at least not on its own). The
> > work *can* pay off, even for pure documentation purposes.
>
> IMHO not really. I'd rather spend some time on the fileformats and
> their docs. Such code is typically near-mechanically creating
> conversions for data formats, hardly worth item-per-item
> documentation.
See my small example above. The type is almost self documenting. Some
more comments would be needed, if I just declared it as word/LongInt/
$whatever or (to not introduce too many "different" types) not at all.
> > I kind of agree with that. My bad experience comes from the fact
> > that (some of) the people who wrote the code I am maintaining and
> > moved to Linux now just wasn't done that way. Binary formats where
> > used for almost everything, nobody cared for alignment and so on...
> > So every once in a while some internal structures changed and
> > *kaboom* the new version couldn't read the old data.
>
> IOW the problem was bad programmers, not evil binary formats ;-)
If you'd like to put it that way, yes. But that's why we use Pascal (or
in my case, even Ada): To protect ourselves from doing bad things too
easily. :)
> I learned a lot of the tricks with dealing with binary files in my
> BBS era days. This due to the 16->32bit changes, different compilers,
> the large amounts of versions of binary files floating around, and
> the danger of truncation by modem.
I didn't realize you were that old.
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] PPC64 port
> Hello, > >I've been working on the PPC64-port for the Linux on Power contest > for some time now, and finally have some questions I'd like to ask for > here: > > Some introduction: I am trying to use the PPC64-ELF ABI for all > generated methods, first because of compatibility issues (I believe it's > needed anyway) and it imo does not really matter which to choose > initially. > There are two problems with that though; I didn't fix them yet because > I'm hesitating to change stuff in the compiler-directory (all ppc64 > specific things are in a subdirectory at the moment), and that's why I'm > asking: > > *) functions are not simple adresses anymore, but references to a so > called function descriptor (if I remember the name correctly). Problem > is that the assembly generator seems to hardcode the method > specification prologue to: > > .globl > .type , @function > : >... method assembly ... > > Problem is that this does not seem to work on PPC64 (tried on some > hand-made assembly code); the GNU linker assumes that > is a function pointer, mangles it, and the resulting > programs always crash on calling a method... ;-) Check the output of 'gcc -S' with a simple example. The code to write the function prologue/epilogue can be moved to a virtual function and be overriden for ppc64 if needed. > I found that in aggas.pas this behaviour seems to be hardcoded. Is there > another way to change the function specification prologue? > (Btw, there's a similar problem with the epilogue) > > There is a way to specify "local" methods without those function > pointers, but... this works for local methods only. :( > > *) as far as I understand PPC64 ELF ABI assumes that at if there's a > stack, the area which holds the register contents R3-R10 is always > available (e.g. the 8x8 bytes for saving register contents). Is there a > way to specify a minimum size for the stack without changing something > in the method which calculates stack layout? > (I thought of something like dummy local variables if needed) See sparc > *) How do I add a symbol/constant to the TOC? I'd like to avoid certain > really time consuming operations on constants... > > *) one really minor thing: what should the platform be called? PPC64? > POWERPC64? POWERPC_64 (like x86_64)? =) What the Linux kernel returns with 'uname -m' ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] PPC64 port
Hello, I've been working on the PPC64-port for the Linux on Power contest for some time now, and finally have some questions I'd like to ask for here: Some introduction: I am trying to use the PPC64-ELF ABI for all generated methods, first because of compatibility issues (I believe it's needed anyway) and it imo does not really matter which to choose initially. There are two problems with that though; I didn't fix them yet because I'm hesitating to change stuff in the compiler-directory (all ppc64 specific things are in a subdirectory at the moment), and that's why I'm asking: *) functions are not simple adresses anymore, but references to a so called function descriptor (if I remember the name correctly). Problem is that the assembly generator seems to hardcode the method specification prologue to: .globl .type , @function : ... method assembly ... Problem is that this does not seem to work on PPC64 (tried on some hand-made assembly code); the GNU linker assumes that is a function pointer, mangles it, and the resulting programs always crash on calling a method... ;-) I found that in aggas.pas this behaviour seems to be hardcoded. Is there another way to change the function specification prologue? (Btw, there's a similar problem with the epilogue) There is a way to specify "local" methods without those function pointers, but... this works for local methods only. :( *) as far as I understand PPC64 ELF ABI assumes that at if there's a stack, the area which holds the register contents R3-R10 is always available (e.g. the 8x8 bytes for saving register contents). Is there a way to specify a minimum size for the stack without changing something in the method which calculates stack layout? (I thought of something like dummy local variables if needed) *) How do I add a symbol/constant to the TOC? I'd like to avoid certain really time consuming operations on constants... *) one really minor thing: what should the platform be called? PPC64? POWERPC64? POWERPC_64 (like x86_64)? =) Finally I've got some more general question on the challenge: What does "must be optimized for 64-bit platforms" in the challenge details mean? In the same sense I'd like to ask if you could specify some sort of minimum requirements for the port in a little more detail? (E.g. must cycle using the makefiles, must integrate into fpc distro, must compile + run IDE, must successfully run x tests, etc..., whatever) Regards, Thomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bugreport: FPC 1.9.8 installer, i386-FreeBSD
> > > bash is a superset of a sh shell, the .sh extension for bash scripts is > > common, and has nothing to do with GNU. It was already that way on 4.4BSD. > > 4.4BSD had bash??? No. Even FreeBSD still has bash as port. However it was commonly installed. > And why do you say, it has nothing to do with GNU? I meant GNU orientation of OS/distro's in general. > Okay, bash is very common nowadays. But for example zsh is also a > superset of sh, but if you use it's extentions without mentioning it, > you also might get very irritated reactions. ;-) zsh is much less common than bash. E.g. FreeBSD comes without it, but if you install a handful of ports, you already have it. > > > Or better rewrite it to be usable with a standard-shell. > > > > I prefer not, it is not worth the effort. > > I'm going have a look at it this week. > Shall I send it to the list, or to whom? Look first what needs to be done. The result must be maintainable. (keep in mind that most other devels must be able to maintain and test it) > > Define _properly_? The IDE is not configured by the installer. Does it > > start? > > Okay I could install it by hand... > But nevertheless it's a bug in the installer-script. > > I had a deeper look at it. > The script says: > | rm -f $EXECDIR/fp > | ln -sf $LIBDIR/fp $EXECDIR/fp > but the package has the binary in bin/, not in lib/... > So the binary is deleted and the symlink points to nowhere. Ok. Will try to see if we can do something about that for the next release. > > Pascal is said to be a B&D language by people that don't grasp certain > > concepts, usually newbies using Basic, or even plain C because it is l33t. > > Even ESR says so. ESR is also commonly considered to be a gunwielding maniac :-) More importantly though, ESR is a C centric, and thus he inherits the lingo. No surprise that he doesn't see the merits of Pascal. > Well, okay, I can live with it, I just was surprised, because I was used > to do so. I think it is best to simply inventarise what the bash specific parts are. If they are details, and relatively non-intrusive, we can adapt it, and add it to the wiki for future package builders. If it is problematic, then we simply keep it bash. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] integer, cardinal
> On Monday 18 April 2005 09:02, Marco van de Voort wrote:
> > > Well, and I actually do this in a major app at work. Not on
> > > everything, of course, but it can heavily simplify some stuff, for
> > > instance because I can use the Low and High-attribu^Wfunctions on
> > > the type which is safer than using constants, because the compiler
> > > can do the work for me.
> >
> > I typically use enums. They suffer from the same to-disk problem
> > though, but that can be remedied using the proper directives.
>
> Well, I don't think I will ever use enums to define things like
> frequency limits.
Since I don't use 16-bit systems, and frequencies above 2GHz are not my
domain that is not really a problem for me.
> Ok, in that case you're probably out of luck and have to use fixed size
> types in almost any case. Still, you probably want to define them
> separately and explicitely instead of relying on some compiler
> behaviour. At least that's what I do:
There are similar things already defined in unit ctypes. This way you can
for FPC make even this unit independant of what happens with integer/qword
etc, because the unit is adapted per platform.
So
{$ifdef FPC} // 1.9.x +
mysint8type = ctypes.cint8;
myuint8type = ctypes.cuint8;
{$ELSE}
// inferior compilers ( :-) )
{$endif}
> Alas, AFAICS there is no way to define the range and the storage size of
> a type independent from each other in FPC?
No. Only 1,2,4,8 sized integer types exist, in both flavours, and in ctypes
identifiers are predefined. (actually ctypes is defined as containing types
for the reference C compiler on that platform for header purposes, but the
size-invariant types are also defined and commonly reused)
Other sizes are rarely used (3 byte sometimes in RGB handling code), and would
only unnecessarily complicate the codegeneration.
> > And it is a lot more laborous.
>
> Well, that's not really an argument (at least not on its own). The work
> *can* pay off, even for pure documentation purposes.
IMHO not really. I'd rather spend some time on the fileformats and their
docs. Such code is typically near-mechanically creating conversions for data
formats, hardly worth item-per-item documentation.
> Yes, I think I can understand that. In that case I too would use binary
> formats, I guess.
(a nice example is also the game angband. x86 savegames work on ppc systems
etc, and IIRC I tried a 64-bit alpha running OpenBSD too once)
> I kind of agree with that. My bad experience comes from the fact that
> (some of) the people who wrote the code I am maintaining and moved to
> Linux now just wasn't done that way. Binary formats where used for
> almost everything, nobody cared for alignment and so on... So every
> once in a while some internal structures changed and *kaboom* the new
> version couldn't read the old data.
IOW the problem was bad programmers, not evil binary formats ;-)
I learned a lot of the tricks with dealing with binary files in my BBS era
days. This due to the 16->32bit changes, different compilers, the large
amounts of versions of binary files floating around, and the danger of
truncation by modem.
Adapting to endianess was only a small change.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bugreport: FPC 1.9.8 installer, i386-FreeBSD
Hello, first of all, please don't get me wrong. I didn't want to complain. All in all I find FPC is really great. I wrote this just to show how it could be further improved. Am Montag, dem 18. Apr 2005 schrieb Marco van de Voort: > bash is a superset of a sh shell, the .sh extension for bash scripts is > common, and has nothing to do with GNU. It was already that way on 4.4BSD. 4.4BSD had bash??? And why do you say, it has nothing to do with GNU? Bash is the Boune Shell replacement from GNU. Okay, bash is very common nowadays. But for example zsh is also a superset of sh, but if you use it's extentions without mentioning it, you also might get very irritated reactions. ;-) > Maybe. Note that the shellscript _is_ human readable, Okay. But there should IMHO also be a hint in the docs. > > Or better rewrite it to be usable with a standard-shell. > > I prefer not, it is not worth the effort. I'm going have a look at it this week. Shall I send it to the list, or to whom? [ports tree] > I could use some help there. Errm, sorry > > You cannot silently expect, that everyone in the world is using GNU! > > We never did such thing Again: bash is from GNU. > Define _properly_? The IDE is not configured by the installer. Does it start? Okay I could install it by hand... But nevertheless it's a bug in the installer-script. I had a deeper look at it. The script says: | rm -f $EXECDIR/fp | ln -sf $LIBDIR/fp $EXECDIR/fp but the package has the binary in bin/, not in lib/... So the binary is deleted and the symlink points to nowhere. > Pascal is said to be a B&D language by people that don't grasp certain > concepts, usually newbies using Basic, or even plain C because it is l33t. Even ESR says so. Well, okay, I can live with it, I just was surprised, because I was used to do so. -- AKFoerster ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] integer, cardinal
On Monday 18 April 2005 09:02, Marco van de Voort wrote:
> > > > That's why Pascal has range types. Define the range you need,
> > > > and don't use "just some type" which has the range you think
> > > > you will need.
> > >
> > > I actually tried this in a major app at work.
> >
> > Well, and I actually do this in a major app at work. Not on
> > everything, of course, but it can heavily simplify some stuff, for
> > instance because I can use the Low and High-attribu^Wfunctions on
> > the type which is safer than using constants, because the compiler
> > can do the work for me.
>
> I typically use enums. They suffer from the same to-disk problem
> though, but that can be remedied using the proper directives.
Well, I don't think I will ever use enums to define things like
frequency limits.
> > Yes, of course, that's the outside world.
>
> But if you have only business data, nearly everything is directly
> connected to it. One only moves the problem (from declaring types
> fixed size to data-spooling).
Ok, in that case you're probably out of luck and have to use fixed size
types in almost any case. Still, you probably want to define them
separately and explicitely instead of relying on some compiler
behaviour. At least that's what I do:
-- 8< -- snip --
unit
Interfaces;
{/\}
{ }
{ hardware interface types with specific sizes }
{ }
{ PLEASE use these types in real hardware interfacing stuff only, not }
{ as C-like integer replacements! }
{ }
{\/}
interface
type
Signed_8= ShortInt; // -2**7 .. 2**7 - 1
Unsigned_8 = byte; // 0 .. 2**8 - 1
Signed_16 = SmallInt; // -2**15 .. 2**15 - 1
Unsigned_16 = word; // 0 .. 2**16 - 1
Signed_32 = LongInt; // -2**31 .. 2**31 - 1
Unsigned_32 = LongWord; // 0 .. 2**32 - 1
Signed_64 = Int64; // -2**63 .. 2**63 - 1
Unsigned_64 = QWord; // 0 .. 2**64 - 1
implementation
end {Interfaces}.
-- 8< -- snip --
Alas, AFAICS there is no way to define the range and the storage size of
a type independent from each other in FPC?
> And it is a lot more laborous.
Well, that's not really an argument (at least not on its own). The work
*can* pay off, even for pure documentation purposes.
> > Maybe, you have to do such things more often, but - no offense
> > meant - earlier experience led me to believe that binary file
> > formats are evil.
>
> Textformats vary with systems too. No solution either. (e.g.
> encodings, lineendings and other control characters).
Well, for the lineendings you already did the job for me and anything
else here is currently bound to be either pure ASCII or XML (where I
can stand the bloat that comes with it ;-).
> And besides
> that, I'm spooling millions of objects to disc during startup and
> shutdown. Cooked I/O is magnitudes slower. (I work with
> readers/writers, text-IO output is supported for debug purposes)
Yes, I think I can understand that. In that case I too would use binary
formats, I guess.
> Binary formats are IMHO not evil. It's more that the simple basic
> rule of programming applies to it, think things through thoroughly
> before starting, and then the best effort deals with the bulk of the
> problems, and for the rest make custom solutions if the problems
> actually arise. One simply can't tailor to every possibility without
> making things costly or usuable.
I kind of agree with that. My bad experience comes from the fact that
(some of) the people who wrote the code I am maintaining and moved to
Linux now just wasn't done that way. Binary formats where used for
almost everything, nobody cared for alignment and so on... So every
once in a while some internal structures changed and *kaboom* the new
version couldn't read the old data.
> > They tend to change too often, they tend to use types that don't
> > even survive half a decade, and even if this doesn't matter known
> > size types won't save you from the Hell of Endianess. And if you
> > don't have that problem, you don't have it all. ;-)
>
> How do read in EBDIC textfiles btw?
I don't, luckily our platforms don't include ancient IBM mainframes. ;-)
And if they would, I'd either use COBOL or write a translation unit for
it.
> And unicode files in some transient standard?
Again. I don't. I just use plain old 7-Bit-ASCII. If I'd want to be
non-portable, I'd use binary files, you know. ;-)
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] integer, cardinal
On Monday 18 April 2005 08:46, Jonas Maebe wrote: > They are, but ptrint and ptruint are just regular types. The compiler > cannot know they are properly defined in each RTL unit, and you can > override them to be something completely different. That's why it > gave and still gives a warning. Yep. And IMHO that is - even under the usual circumstances - just the right thing to do. Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] integer, cardinal
> > > That's why Pascal has range types. Define the range you need, and > > > don't use "just some type" which has the range you think you will > > > need. > > > > I actually tried this in a major app at work. > > Well, and I actually do this in a major app at work. Not on everything, > of course, but it can heavily simplify some stuff, for instance because > I can use the Low and High-attribu^Wfunctions on the type which is > safer than using constants, because the compiler can do the work for > me. I typically use enums. They suffer from the same to-disk problem though, but that can be remedied using the proper directives. > > However quite a lot of datastructures get written to disc sooner and > > later, and to get fileformats size independant, you need a lot of > > datastructure conversions (from records with fields that have arch > > dependant size to packed records with fields with fixed sized integer > > types). > > Yes, of course, that's the outside world. But if you have only business data, nearly everything is directly connected to it. One only moves the problem (from declaring types fixed size to data-spooling). And it is a lot more laborous. > For instance, I have to read > Image-files (and if you know TIFF, you know the beast) and have to > write binary structures to a connected embedded system and there I > badly need known size types, but that's about it. > > Maybe, you have to do such things more often, but - no offense meant - > earlier experience led me to believe that binary file formats are evil. Textformats vary with systems too. No solution either. (e.g. encodings, lineendings and other control characters). And besides that, I'm spooling millions of objects to disc during startup and shutdown. Cooked I/O is magnitudes slower. (I work with readers/writers, text-IO output is supported for debug purposes) Binary formats are IMHO not evil. It's more that the simple basic rule of programming applies to it, think things through thoroughly before starting, and then the best effort deals with the bulk of the problems, and for the rest make custom solutions if the problems actually arise. One simply can't tailor to every possibility without making things costly or usuable. Some simple things: - use endian indicators somewhere near the top of the file. - store size of records. - use magic numbers to detect possible problems (more a testsuite thing, but still a good thing) - use an alignment supported by a lot of compilers. (packed, C or 4 byte) - be a bit smart with your types, and don't have too many. > They tend to change too often, they tend to use types that don't even > survive half a decade, and even if this doesn't matter known size types > won't save you from the Hell of Endianess. And if you don't have that > problem, you don't have it all. ;-) How do read in EBDIC textfiles btw? And unicode files in some transient standard? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] integer, cardinal
> Oh, but while we're at it: fpc1.9.6 still gives me the Hint, that this
> PtrUInt/Address-Conversion isn't portable:
>
> | WriteLn ('Runtime error ', ExitCode,
> | ' at 16#',
> | SysUtils.IntToHex (PtrUint(ErrorAddr),
> | 2 * SizeOf (ErrorAddr)),
> | '#');
>
> Is that fixed in the current version? Or am I thinking wrong when I
> think, this should - by definition - be portable? ;-)
It is only a hint. And Typecasting pointer <-> integer will always trigger
such a hint. It is usefull for ppl compiling on 32bit that they need to
look at thing carefully if it is what they intended. Typecasting a pointer
to longint on a 64bit target will give a warning instead.
But this hint/warning is independent of the first question about
integer/cardinal sizes. Please stay to the topic of the thread.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] integer, cardinal
On 18 apr 2005, at 10:40, Vinzent Hoefler wrote:
Oh, but while we're at it: fpc1.9.6 still gives me the Hint, that this
PtrUInt/Address-Conversion isn't portable:
| WriteLn ('Runtime error ', ExitCode,
| ' at 16#',
| SysUtils.IntToHex (PtrUint(ErrorAddr),
| 2 * SizeOf (ErrorAddr)),
| '#');
Is that fixed in the current version? Or am I thinking wrong when I
think, this should - by definition - be portable? ;-)
They are, but ptrint and ptruint are just regular types. The compiler
cannot know they are properly defined in each RTL unit, and you can
override them to be something completely different. That's why it gave
and still gives a warning.
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] integer, cardinal
On Monday 18 April 2005 07:29, Peter Vreman wrote:
> > On Sunday 17 April 2005 10:45, Ales Katona wrote:
> >> First of all Integer should be size independent, that is, xy bits
> >> depending on the platform.
> >
> > I second that.
>
> This is useless. Your code
That doesn't matter. If I'd want the same code on all platforms I'd use
Java.
> and runtime checks
That can indeed be a problem, especially when this size is used in
intermediate calculations (in correct programs, it should not have an
effect on the result or you are out of luck already. Go fix your code
then.).
> will then vary for the
> kind of processor (32 or 64bit) you are compiling for.
That's some of the reasons I personally discourage using such types
unless perhaps for loop-counters where you know it will never overflow
some way or another.
> Even 'int' in C is always 4 bytes.
Huh? Since when? Last time I checked the C99 standard, int was only
guaranteed to be able to hold the values -32767 to 32767 and that makes
"int" at best a "must at least be 16 bit"-type. C doesn't even specify
that that thing they call "byte" is actually the usual 8-bits wide.
> The 'long' type is most of the time equal to the
> size of a pointer.
You say it: "Most". And on platforms where it doesn't (and I know some),
code that relies on that will break. So someone would be better off to
assume nothing about such types. The problem in C is: there are no
range types, you are _bound_ to use some of the predefined ones.
> Don't expect that we change anything in this part. If you want to use
> an integer with the natural size of the processor you can use ptrint
> or ptruint.
I think that's a bad suggestion and you know it.
Oh, but while we're at it: fpc1.9.6 still gives me the Hint, that this
PtrUInt/Address-Conversion isn't portable:
| WriteLn ('Runtime error ', ExitCode,
| ' at 16#',
| SysUtils.IntToHex (PtrUint(ErrorAddr),
| 2 * SizeOf (ErrorAddr)),
| '#');
Is that fixed in the current version? Or am I thinking wrong when I
think, this should - by definition - be portable? ;-)
Vinzent.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] integer, cardinal
On Monday 18 April 2005 07:22, Marco van de Voort wrote: > > On Sunday 17 April 2005 10:45, Ales Katona wrote: > > > First of all Integer should be size independent, that is, xy bits > > > depending on the platform. > > > > I second that. > > It is now. It just happens to be the same. :) Ok, good point. > > > Second, we should "force people in a friendly way" to use more > > > readible names like: > > > sint32, uint64, etc. than "cardinal" > > > > No. Such stuff is only needed when you do hardware-interfacing. > > And that's the _only_ reason someone would need types with defined > > bit-sizes. > > That's a bit simplistic; Network/system interfacing, binary > fileformats ? Oh sorry, in that context, I'd call that "hardware", too. It belongs to the "outside world's" interface. > > > In a few years when 64 bits are normal, what will cardinal > > > become? who knows.. > > > > That's why Pascal has range types. Define the range you need, and > > don't use "just some type" which has the range you think you will > > need. > > I actually tried this in a major app at work. Well, and I actually do this in a major app at work. Not on everything, of course, but it can heavily simplify some stuff, for instance because I can use the Low and High-attribu^Wfunctions on the type which is safer than using constants, because the compiler can do the work for me. > In theory it is nice Well, in practice it works. :-) > However quite a lot of datastructures get written to disc sooner and > later, and to get fileformats size independant, you need a lot of > datastructure conversions (from records with fields that have arch > dependant size to packed records with fields with fixed sized integer > types). Yes, of course, that's the outside world. For instance, I have to read Image-files (and if you know TIFF, you know the beast) and have to write binary structures to a connected embedded system and there I badly need known size types, but that's about it. Maybe, you have to do such things more often, but - no offense meant - earlier experience led me to believe that binary file formats are evil. They tend to change too often, they tend to use types that don't even survive half a decade, and even if this doesn't matter known size types won't save you from the Hell of Endianess. And if you don't have that problem, you don't have it all. ;-) Vinzent. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] problem with "is" operator
On Sun, Apr 17, 2005 at 12:01:36PM -0700, Linuxer Wang wrote: > > Can anybody tell me how can I know which specific type an instance of > class is? The "is" operator seems weird when interface is used. > > Suppose TMyInterface is a interface, and classes TCircle and TSquar > both implements TMyInterface, and inst:TMyInterface, inst := It does not seem right to declare var inst: TMyInterface if you want inst to have circles and squares as values. I would expect that you also have a class TFigure, of which TCircle and TSquare both are descendants. These could also implement TMyInterface. You then declare var inst: TFigure and can do inst := TCircle.Create. > TCircle.Create. How can I know which instance is inst? The following > code can not even compile: > > if inst is TCircle then ... > > class type expected, but got "TMyInterface" > Incompatible type for arg no. 2: Got "TMyInterface", expected "TObject" The type of inst needs to be a class type (such as TFigure above), not an interface object type. If you do as I suggest above, it should work. Tom -- E-MAIL: T.Verhoeff @ TUE.NL | Fac. of Math. & Computing Science PHONE: +31 40 247 41 25| Eindhoven University of Technology FAX:+31 40 247 54 04| PO Box 513, NL-5600 MB Eindhoven http://www.win.tue.nl/~wstomv/ | The Netherlands ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] integer, cardinal
Some notes. > This is useless. Your code and runtime checks will then vary for the kind > of processor (32 or 64bit) you are compiling for. Even 'int' in C is > always 4 bytes. This is not true. Most recent 64-bit machines indeed are LP64, but e.g. several Crays are ILP64. Moreover, the C standard afaik doesn't exclude it. (but did weaken the wording on not relying on int=32bit in C99) > The 'long' type is most of the time equal to the size of a > pointer. Not in LLP64, which e.g. win64 uses. There long is kept equal in size to int, and longlong is introduced for pointer. There are more OSes that do this btw, IIRC several commercial unices did too. > Don't expect that we change anything in this part. If you want to use an > integer with the natural size of the processor you can use ptrint or > ptruint. Agree fully. Or use the new -Fa parameter which is specially for such cases. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] integer, cardinal
> On Sunday 17 April 2005 10:45, Ales Katona wrote: > >> First of all Integer should be size independent, that is, xy bits >> depending on the platform. > > I second that. This is useless. Your code and runtime checks will then vary for the kind of processor (32 or 64bit) you are compiling for. Even 'int' in C is always 4 bytes. The 'long' type is most of the time equal to the size of a pointer. Don't expect that we change anything in this part. If you want to use an integer with the natural size of the processor you can use ptrint or ptruint. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] integer, cardinal
> On Sunday 17 April 2005 10:45, Ales Katona wrote: > > First of all Integer should be size independent, that is, xy bits > > depending on the platform. > > I second that. It is now. It just happens to be the same. However keep in mind that the strict integer=wordsize bond of the past no longer goes. On most 64-bit systems, integer is _not_ 64-bit. Mostly because it only unnecessary drives up memory consumption. > > Second, we should "force people in a friendly way" to use more > > readible names like: > > sint32, uint64, etc. than "cardinal" > > No. Such stuff is only needed when you do hardware-interfacing. > And that's the _only_ reason someone would need types with defined > bit-sizes. That's a bit simplistic; Network/system interfacing, binary fileformats ? > > In a few years when 64 bits are normal, what will cardinal become? > > who knows.. > > That's why Pascal has range types. Define the range you need, and don't > use "just some type" which has the range you think you will need. I actually tried this in a major app at work. In theory it is nice However quite a lot of datastructures get written to disc sooner and later, and to get fileformats size independant, you need a lot of datastructure conversions (from records with fields that have arch dependant size to packed records with fields with fixed sized integer types). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bugreport: FPC 1.9.8 installer, i386-FreeBSD
> I really had trouble installing FPC on FreeBSD. Ah? > I downloaded the big tar archive and unpacked it. Then I saw the > file "install.sh" there. Because of the file-extension ".sh" I > thought it was a simple shellscript for sh. So I tried to start it with > "sh install.sh". That didn't work. So I looked into the script and saw, > that it needs a special shell, namely bash. The extension ".sh" is very > misleading! bash is a superset of a sh shell, the .sh extension for bash scripts is common, and has nothing to do with GNU. It was already that way on 4.4BSD. > Well, bash wasn't installed on my system, so I had to install it. You > should say so in the docs. Maybe. Note that the shellscript _is_ human readable, and the bash is on the first line, and the script is fixed so that it doesn't hardcode the location of bash. > Or better rewrite it to be usable with a standard-shell. I prefer not, it is not worth the effort. I prefer to work on the ports tree entries more, which are IMHO more important than the tgzs. Unfortunately, I haven't had much time for that. It is still on the 1.9.2 level. I could use some help there. > You cannot silently expect, that everyone in the world is using GNU! We never did such thing, the script is already made more generic for all kinds of non linux distro's in multiple ways: - the script properly lists bash as the shell - further, the location of bash is not hardcoded - some GNU sed specific constructs have been replaced by awk We could maybe add a small footnote somewhere, but the chances are slim that it will help anyone, since any decent sysadmin would look at a script before he runs it anyway. > But then again it didn't work. I looked into the script again and > replaced the line "VERSION=%version%" with "VERSION=1.9.8". Then at > last it worked. Just still the IDE seems not to be installed properly, > but I don't use it anyway. Define _properly_? The IDE is not configured by the installer. Does it start? > Apropos GNU: You still use the old Cambridge address for the FSF. They > are now in Boston. As I've heard, they plan to move again within Boston > this summer. So look out for their actual address on their homepage: > http://www.fsf.org > > And another comment on a new "feature". FPC doesn't let me manipulate > the for-loop-variable anymore. That's annoying! That's by design. The whole purpose of the for loop construct is optimization. Changing the loopvar frustrates that. Use while or repeat > Well Pascal was always said to be a bondage-and-discipline-language, but > please don't force that any further. Pascal is said to be a B&D language by people that don't grasp certain concepts, usually newbies using Basic, or even plain C because it is l33t. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
