Re: [fpc-pascal] exit ?
> exit with a parameter is not supported in other compilers afaik (e.g. > exit(5), equivalent to "return 5"). It may exist in Delphi Not in D6-D7 to my knowledge. D2005 unknown. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] generated exe file size
On 26 mei 2005, at 05:44, Bisma Jayadi wrote: The code is compiled using FPC with faster code optimization, generate exe file with size 435 KB. While it is compiled using Delphi with optimization, generate exe file with size (only) 83 KB. Why FPC generate that so big exe file? I only use Variants unit explicitely. Make sure you turn on smart linking (-XX). Also, stripping of debug information is broken in the current versions of the GNU linker, which we use. We cannot help that, and older versions in which this does work cannot link with certain libraries. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] generated exe file size
> On 26 mei 2005, at 05:44, Bisma Jayadi wrote: > > > The code is compiled using FPC with faster code optimization, generate > > exe file > > with size 435 KB. While it is compiled using Delphi with optimization, > > generate > > exe file with size (only) 83 KB. Why FPC generate that so big exe > > file? I only > > use Variants unit explicitely. > > Make sure you turn on smart linking (-XX). Also, stripping of debug > information is broken in the current versions of the GNU linker, which > we use. We cannot help that, and older versions in which this does work > cannot link with certain libraries. Note that stripping debuginfo via the "strip" utility works, at least better than via ld. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] type definitions etc
For quite some time I have been using FreePascal for occasional programming (windows programs); it works fine, so I don't post so many stupid questions to this list any more. But now I have downloaded the new version 2, driven by the enthusiasm in the announcement, and trying to compile some of my old programs with the new version rose a few questions. In a program I had a recursive definition like: type sometype = record n: longint; p: ^sometype end; This worked in version 1.0, but in version 2.0 the compiler complains that the type is not fully defined. Is there a good reason why that is not allowed any more.? It was practical for making chains of data structures. Also the following call to a win32 API function is not allowed any more: invalidaterect(windows, 0, true); The error is that the 2nd parameter should be of type 'rect'. I know that careful type checking is a fundamental part of pascal philosophy, and this is good for preventing many programming errors. But on the other hand some windows API functions make use of the rule that substituting null for some type makes the function use a default value. Is there a general way to get around this problem? The 2nd parameter in this example must be of 'var' type, which means that it is the pointer to the parameter that is transferred to the function. Transferring a nil pointer is in pascal language the same as leaving the parameter undefined. But that is not possible in FreePascal, is it? With the installation of version 2, I had the problem that the figures are missing from the html-documentation. I downloaded the zipped file from the special link and unpacked it to D:\FPC\2.0.0\ and it went into the already existing doc directory. But some (or may be all) of the figures are missing from the text. Finally I would like to ask about the following. The compiler does not allow a procedure definition like: procedure someproc(p: ^double); whereas the following is perfectly possible: type Tpdouble = ^double; procedure f(p: Tpdouble); Is there a good reason for this? Why isn't ^double a valid type everywhere? Hans Maartensson ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] type definitions etc
On Thursday 26 May 2005 12:06, Hans Maartensson wrote: > In a program I had a recursive definition like: > > type sometype = record >n: longint; >p: ^sometype >end; This was never allowed in Pascal, AFAIK. The standard solution is to define the pointer type first: |type | ptr_sometype = ^sometype; |type | some_type = | record | p : ptr_sometype; | ... | end; > Also the following call to a win32 API function is not allowed any > more: > > invalidaterect(windows, 0, true); > > The error is that the 2nd parameter should be of type 'rect'. Have you actually tried "InvalidateRect (windows, NIL, True);"? > The 2nd parameter in this example must be of 'var' type, which means > that it is the pointer to the parameter that is transferred to the > function. Transferring a nil pointer is in pascal language the same > as leaving the parameter undefined. But that is not possible in > FreePascal, is it? It is, because of function overloading: function InvalidateRect(hWnd:HWND; var lpRect:RECT; bErase:WINBOOL):WINBOOL; external 'user32' name 'InvalidateRect'; function InvalidateRect(hWnd:HWND;lpRect:LPRECT; bErase:WINBOOL):WINBOOL; external 'user32' name 'InvalidateRect'; So the second form takes a pointer, thus passing NIL should be perfectly allowed, AFAICS. > Finally I would like to ask about the following. > The compiler does not allow a procedure definition like: > > procedure someproc(p: ^double); > > whereas the following is perfectly possible: > > type Tpdouble = ^double; > procedure f(p: Tpdouble); > > Is there a good reason for this? Why isn't ^double a valid type > everywhere? Because type1 = ^double; type2 = ^double; should be considered different types. So if you define the type in the procedure declaration, you couldn't call it, just because you can't declare a variable of the same type for the argument. The only allowed argument would be NIL, which I think is a little bit pointless. BTW, why don't you use "procedure f(const/var/out p : double);" instead to get rid of as much pointers as possible and use the right parameter modes which also have the side effect of being more self documenting? Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] type definitions etc
At 14:50 26-05-2005, you wrote: > . > type sometype = record >n: longint; >p: ^sometype >end; This was never allowed in Pascal, AFAIK. FPC version 1.0.12 compiled it OK The standard solution is to define the pointer type first: |type | ptr_sometype = ^sometype; |type | some_type = | record | p : ptr_sometype; | ... | end; OK, I didn't try that, so it is allowed to define a type as a pointer to a type that is defined later. > Also the following call to a win32 API function is not allowed any > more: > > invalidaterect(windows, 0, true); Have you actually tried "InvalidateRect (windows, NIL, True);"? ... I have overlooked that, you are right, it works, due to function overloading, as you explain. So in the old version it was 0, now it is nil, OK. > Finally I would like to ask about the following. > The compiler does not allow a procedure definition like: > > procedure someproc(p: ^double); > > whereas the following is perfectly possible: > > type Tpdouble = ^double; > procedure f(p: Tpdouble); > > Is there a good reason for this? Why isn't ^double a valid type > everywhere? Because type1 = ^double; type2 = ^double; should be considered different types. So if you define the type in the procedure declaration, you couldn't call it, just because you can't declare a variable of the same type for the argument. The only allowed argument would be NIL, which I think is a little bit pointless. OK that makes sense. BTW, why don't you use "procedure f(const/var/out p : double);" instead to get rid of as much pointers as possible and use the right parameter modes which also have the side effect of being more self documenting? I do avoid pointers when I can, but sometimes it is not known, how many variables are needed before the program is running. So you let the program allocate some memory, put the values in there, and then you need pointers to keep track of then. On the other hand, I just read in the documentation that the new version of FPC (I used v.1.0.12 before) has something called dynamic array. Those arrays will fix that kind of problem, I really like that new feature. Thank you very much for the help. Hans Maartensson ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
