Recent

Author Topic: [CLOSED] TP/BP compatibility  (Read 9366 times)

julkas

  • Guest
[CLOSED] TP/BP compatibility
« on: August 01, 2019, 05:24:10 pm »
What is best approach for  TP (turbo Pascal)/BP compatibility fu1 or  fu2
Code: Pascal  [Select][+][-]
  1. program ide;
  2. {$mode tp}
  3. type
  4.   prec = ^rec;
  5.   rec = record
  6.     a: longint;
  7.   end;
  8. function fu1(var x: rec): longint;
  9. begin
  10. end;
  11. function fu2(x: prec): longint;
  12. begin
  13. end;
  14. begin
  15. end.
« Last Edit: August 28, 2019, 06:05:22 pm by julkas »

440bx

  • Hero Member
  • *****
  • Posts: 6462
Re: TP/BP compatibility
« Reply #1 on: August 01, 2019, 05:30:51 pm »
What is best approach for  TP (turbo Pascal)/BP compatibility fu1 or  fu2
As far as compatibility goes, I think they should be the same.

I believe most people would prefer fu1 over fu2 because explicit pointer dereferencing is not necessary (the compiler does it for you.)
FPC v3.2.2 and Lazarus v4.0rc3 on Windows 7 SP1 64bit.

Thaddy

  • Hero Member
  • *****
  • Posts: 19123
  • Glad to be alive.
Re: TP/BP compatibility
« Reply #2 on: August 01, 2019, 07:33:18 pm »
Except when passing nil, that is.
objects are fine constructs. You can even initialize them with constructors.

440bx

  • Hero Member
  • *****
  • Posts: 6462
Re: TP/BP compatibility
« Reply #3 on: August 01, 2019, 07:47:44 pm »
Except when passing nil, that is.
Good point.  fu2 allows nil whereas fu1 doesn't.  That's a consideration that may matter depending on what the function is supposed to do. 

As far as compatibility, I don't think it makes any difference.
FPC v3.2.2 and Lazarus v4.0rc3 on Windows 7 SP1 64bit.

julkas

  • Guest
Re: TP/BP compatibility
« Reply #4 on: August 02, 2019, 08:31:53 am »
Except when passing nil, that is.
Good point.  fu2 allows nil whereas fu1 doesn't.  That's a consideration that may matter depending on what the function is supposed to do. 

As far as compatibility, I don't think it makes any difference.
Ok, thanks. I am porting C code to Free Pascal. I want BP/TP compatibility (at least TP7). Original code has many functions in the following form
Code: C  [Select][+][-]
  1. obj * fun(obj * x) {
  2.   if (x == null} {
  3. ...
where obj is struct. Can I use my fu1 or not?

440bx

  • Hero Member
  • *****
  • Posts: 6462
Re: TP/BP compatibility
« Reply #5 on: August 02, 2019, 08:44:45 am »
Ok, thanks. I am porting C code to Free Pascal. I want BP/TP compatibility (at least TP7). Original code has many functions in the following form
Code: C  [Select][+][-]
  1. obj * fun(obj * x) {
  2.   if (x == null} {
  3. ...
where obj is struct. Can I use my fu1 or not?
The test "if (x == NULL)" indicates that the function can accept a NULL/nil pointer, in that case, fu2 would be the better match to the C function because, fu2 allows a nil/NULL parameter as your C function currently does.

Again, as far as compatibility goes, that doesn't make any difference.

If I were you, I'd use fu2 because that way, the Pascal code will likely be completely parallel to the C code, that would not be the case if you used a declaration like fu1.

When I port C code to Pascal, except in the case of really simple programs, I normally do it in two passes.  In the first pass, I make the Pascal code as parallel to the C code as possible (that's usually fairly straightforward), once that port is working correctly then, I look at the resulting Pascal code and determine what parts of it are better re-written using Pascal features.

ETA:

where obj is struct. Can I use my fu1 or not?
The answer to that question is, yes you can, but, if you go that route, the Pascal code for C functions that accept nil as a parameter won't be "parallel".  Here is an example of passing nil to a Pascal function declared to take a "var" parameter:
Code: Pascal  [Select][+][-]
  1. type
  2.   TStruct = record
  3.     i : integer;
  4.   end;
  5.   PStruct = ^TStruct;
  6.  
  7. function a(var p : TStruct) : boolean;
  8. begin
  9.   writeln(IntToHex(ptruint(@p), 0));
  10.   result := true;
  11. end;
  12.  
  13.  
  14. begin
  15.   a(PStruct(nil)^);
  16.  
To pass nil/NULL, you have to typecast nil and dereference it (personally, I find that to be very "unclean" - see line 15), then in the function you have to test not against "p" but "@p".

IMO, if a C function accepts nil/NULL as a parameter value, it is often not the best way to declare the parameter as a "var" because it unnecessarily complicates the code.

As far as compatibility, both are compatible with BP/TP but, using "var" results in an implementation that is likely more complicated than it should be.

« Last Edit: August 02, 2019, 09:13:39 am by 440bx »
FPC v3.2.2 and Lazarus v4.0rc3 on Windows 7 SP1 64bit.

Thaddy

  • Hero Member
  • *****
  • Posts: 19123
  • Glad to be alive.
Re: TP/BP compatibility
« Reply #6 on: August 02, 2019, 12:07:57 pm »
Small addition:
When interfacing with C code containing structures always use {$PACKRECORDS C} otherwise you will get bitten.
objects are fine constructs. You can even initialize them with constructors.

julkas

  • Guest
Re: TP/BP compatibility
« Reply #7 on: August 02, 2019, 05:51:20 pm »
Small addition:
When interfacing with C code containing structures always use {$PACKRECORDS C} otherwise you will get bitten.
I don't use C binding (interfacing), I just traslate C source code to Pascal.

Thaddy

  • Hero Member
  • *****
  • Posts: 19123
  • Glad to be alive.
Re: TP/BP compatibility
« Reply #8 on: August 02, 2019, 05:54:44 pm »
Still it might be a good idea to pack your records if you are writing a library.
In a stand-alone program it does not matter too much unless you store on file.

TP and BP alignment can be 1 or 2 bytes. Make sure you are consistent.
objects are fine constructs. You can even initialize them with constructors.

julkas

  • Guest
Re: TP/BP compatibility
« Reply #9 on: August 03, 2019, 03:46:37 pm »
I compiled unit with Free Pascal and {$mode tp} without errors.
TP7 compiler fails on //.
So // comment not supported in TP7?

Quote
The following constructs are comments and are ignored by
the compiler:
{ Any text not containing right brace }
(* Any text not containing star/right parenthesis *)
« Last Edit: August 03, 2019, 04:23:46 pm by julkas »

lucamar

  • Hero Member
  • *****
  • Posts: 4217
Re: TP/BP compatibility
« Reply #10 on: August 03, 2019, 06:09:59 pm »
I compiled unit with Free Pascal and {$mode tp} without errors.
TP7 compiler fails on //.
So // comment not supported in TP7?

No, they aren't. C++ style comments weren't supported by any of Borland's Pascal compilers until almost the 21st century--somewhen between Delphi 3 to 5, don't remember exactly.
« Last Edit: August 03, 2019, 06:26:13 pm by lucamar »
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

440bx

  • Hero Member
  • *****
  • Posts: 6462
Re: TP/BP compatibility
« Reply #11 on: August 03, 2019, 06:33:42 pm »
No, they aren't. C++ style comments weren't supported by any of Borland's Pascal compilers until almost the 21st century--somewhen between Delphi 3 to 5, don't remember exactly.
It's not quite that bad.  20th century Delphi 2 supports // comments.

I'm not sure if Delphi 1 (the 16 bit version of Delphi) supported them.  I don't have a handy installation to test it.

Unfortunately, there is no support for /* */, that would allow copy/paste of comments from ported C code to Delphi/FPC.  Easy to implement too but, it won't happen.
FPC v3.2.2 and Lazarus v4.0rc3 on Windows 7 SP1 64bit.

Thaddy

  • Hero Member
  • *****
  • Posts: 19123
  • Glad to be alive.
Re: TP/BP compatibility
« Reply #12 on: August 03, 2019, 06:51:25 pm »
Serious answer part:
TP/BP mode only supports {...} and even older (* .... *)
That's because it is supposed to do that. It does not recognise other modes without a modeswitch, which makes it incompatible with the original compilers.....(THINK!)
TP and BP (and ISO and Extendedpascal) mode should not contain // at all. Not part of the language.

And indeed Delphi 2 introduced single line comments.

Comics starts here:
All for the bad: curly bracket style languages are one big comment in Pascal. So they have to write comments with slashes. :P :D O:-)

They also have the divide by comment ( /# ) and comment divided (#/) option, which they miss-use for multi-line comments.
Alas, # is not an operator you can override.... <  %) %) %) >

(About the above: there is a precedent: ** which has no default implementation....why not /# and #/...?)

I am tired of typing  /#.... #/ when I can do this {...} It is the one part of Pascal where it is 100% more efficient.  :D ;) :) 8) :-X 8-) O:-)
« Last Edit: August 03, 2019, 07:14:14 pm by Thaddy »
objects are fine constructs. You can even initialize them with constructors.

julkas

  • Guest
Re: TP/BP compatibility
« Reply #13 on: August 03, 2019, 08:16:52 pm »
Ok, so search and replace.
I found also this -  program lines have a maximum length of 126 characters.
O great old Pascal!
Who knows - why 126?

Thaddy

  • Hero Member
  • *****
  • Posts: 19123
  • Glad to be alive.
Re: TP/BP compatibility
« Reply #14 on: August 03, 2019, 09:06:59 pm »
It is usually 80, not 126. That may have been a limitation of a type of terminal, just like the 80 is on CP/M, DOS and Apple IIe
objects are fine constructs. You can even initialize them with constructors.

 

TinyPortal © 2005-2018