Could you enchange the 'C'-styled operator support so that &=, %=, ^= and |= would be supported. This would be quite usefull. (They aren't at least in 1.00)

Btw. How flexible the macro-support is in FPC?
Can you have parameters like in C (aka.
#define foo(x) prinf("baz %s\n", x);
)

Keep up the good work!

= ccr/TNSP - | http://www.tnsp.org/ =
= Foo is a synonym for Bar, but not vice versa. =

Could you enchange the 'C'-styled operator support so that &=, %=, ^= and |= would be supported. This would be quite usefull. (They aren't at least in 1.00)

Should be possible, i'll add it to the tasklist

Btw. How flexible the macro-support is in FPC? Can you have parameters like in C (aka. #define foo(x) prinf("baz %s\n", x); )

There is no parameter support yet, maybe in the future. Currently it's not planned. Inlined functions across units have higher priority to implement since they do also some type checking

Hello 2 all,

first of all: I tried the new FPC version 1.0.4 under DOS, and it is working fine (and better than previous ones). This is unvaluable for me, so thanks for the good job.

I have seen some messages about macros and C/C++ features missing in this compiler; I have my ideas about this. I think that a pascal compiler should be *pascal* compiler, and not something else. Some extensions could be welcome if they eliminated some intrinsic limit, but thinking twice about it. I prefer pascal over C because pascal is:

1) Clean
2) Easy readable
3) Fast (-very- fast)

At this time I don't see any thing missing in fpc (some bugs), and I don't think that C-style operators are really necessary. I can write 'flags := flags or $5' and I'm happy with it.

On the other hand, macros are bad, because they create an abstraction layer on top of the program. I know they are useful, but still not enough to justify them. Everything has good and bad aspects; for example, what happens when I try to single step a macro? I've never tried, but I think they screw up things.

And finally... if I wanted C-style operators and powerful macros, I could use C compilers (there are too many of them). Compiling a linux kernel takes twice the time needed if the kernel was written in pascal. May be pascal is not suitable to write a kernel (never tried, but who knows?)

May be I am in error, but the turbo pascal style is the best I ever see in programming. Delphi is good too, but there is too much windows in, and too much support for it.

It is certainly true that I could simply avoid to use macros and C operators (apart from the fact that supporting them slows down and brings complexity. Turbo pascal 3 was a good IDE, with editor and compiler, and was 39K. It simply was a jewel). But a good pascal program is portable. I ported a lot of code from TP to FPC, without problems; why? Because that code was true pascal.

Anyway, do the best you think. Thank you.

_________________________________________________________ Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

startx wrote

is portable. I ported a lot of code from TP to FPC, without problems; why? Because that code was true pascal.

<smartass-mode>
Probably the only 'true' pascal is the ANSI-pascal standard, which is old and does practically unusable. TP is certainly not ANSI, although I believe that it is possible to compile some ANSI code with it.

Same (probably) applies for FPC since it has been made TP/BP-compatible. </smartass-mode>

Whew. ;-)

= ccr/TNSP - | http://www.tnsp.org/ =
= Foo is a synonym for Bar, but not vice versa. =

Macro's can be usefull for multiple platform import units. Example:

Instead of having everytime:

{$ifdef win32}stdcall;{$endif}{$ifdef unix}cdecl;{$endif}

You can write

{$ifdef win32}
  {$define decl:=stdcall}
{$endif}
{$ifdef unix}
  {$define decl:=cdecl}
{$endif}

and then use 'decl' like:

procedure importedproc();external;decl;

For debugging code with macro's: the file position is the same line, so a next operation will go to the next line. A step operation will debug the first called procedure.

Macro's with parameters aren't implemented becuase they can be replaced better with inline functions. IIRC there was also a note from Linus on the kernel list prefere a solution with static;inline functions above a macro, because inlining also adds more type safety.

Peter

Peter Vreman wrote

Macro's with parameters aren't implemented becuase they can be replaced better with inline functions. IIRC there was also a note from Linus on the kernel list prefere a solution with static;inline functions above a macro, because inlining also adds more type safety.

How are the inline-functions implemented in FPC? When using macros, I can have (for example) two versions of it, one stub (empty) and one having some code on it. Good for debugging, since when compiled with no debug, no extra code gets generated.

As far as I understand, the above is not possible (in exactly same way) with inlined functions, since a reference to a function (which would not exist) generates an error.

So the question is: Does an stub inline function with no code except for "begin end;" generate 'extra' code?

If not, then you (I) could replace macros with inline functions.

(Yes, I know that I could check this myself, but I'm just too lazy ;-)

= ccr/TNSP - | http://www.tnsp.org/ =
= Foo is a synonym for Bar, but not vice versa. =

> Macro's with parameters aren't implemented becuase they can be replaced better with

inline

> functions. IIRC there was also a note from Linus on the kernel list prefere a solution > with static;inline functions above a macro, because inlining also adds more type

safety.

How are the inline-functions implemented in FPC? When using macros, I can

inline should already work (but not tested by the masses yet) within units/programs. But can't be placed yet in the interface section to be inlined across units.

function debugstr(s:string);inline;
begin
{$ifdef DEBUG}
  writeln(s:string);
{$endif}
end;

With optimization the empty inlined function can then be removed. But that afaik not yet in the compiler

So the question is: Does an stub inline function with no code except for "begin end;" generate 'extra' code?

Not yet, but it can be added