Marco van de Voort wrote:
I did not try that one - for me compatibility with standard library and ease of linking with c, c++ is important.
FPC can link with c and C++.
I think one main issue is type compatibility, i.e. can you be sure that, say `int' in C always matches `Integer' in Pascal in size --
I don't see why this would have be like that. I already use special identifiers (like Cint Clong etc) in all my headers for a decade, from my M2 times.
I include a ctypes.inc in each header file. Till now this is not standard (I have to implement that file for each platform, but if FPC starts to support 64-bits processors, it could be supplied with each target, we are talking about plusminus 6-10 types here)
Pascal's typing will save you from errors, as long as you are consequent. Side benefit of this is that you can use a different programming model if desired. (e.g. if you major use is to interface with an application/system that uses a different convention than C/GCC). So you can be LP64 in an ILP64 world.
If you map 1:1 you are stuck with what C does, even it is difficult.
otherwise (if that depends on the platform), translations of C headers would be bound to a particular platform.
Or would need a 5 minute global replace before work can really start? As long as I'm consequent (translate C-int with longint etc) I can reverse the process.
FPC or GPC depends on your task and system. In general:
- Non x86? Then GPC. (m68k FPC in beta)
So maybe this issue hasn't arisen yet for FPC,
It hasn't arisen directly, but we also read C faqs from time to time. I also know about endianess, alignment etc :-)
We have to implement a n-bit clean CG from scratch, and I'm sure we can handle such details in the RTL.
but if I'd translate a header now, I'd also want to know if I'll have to do it again on each platform ...
[evil mode on]
Hmm, substitutions are not necessary. FPC supports qualified identifiers.
{$ifdef 64bit} {not complete} type longint=System.int64; shortint=System.longint; int64=System.int128; {problem. int64 is used as "long long", but int64 as type could exist in C too) {$endif} [evil mode off]
I had the problem with int64 above already years ago under Modula- 2 (where "CARDINAL" is a base type, which also exists under C. I had a 16-bit M2 (M2-CARDINAL=16-bit), and interfaced to DJGPP written structures (CARDINAL=32-bit)
It is the reason why I keep C and Pascal types strictly apart, and prefix c types with "c" in headers. Typing saves the day again :_)
In general, 64-bit problems were not that bad as I expected. This is probably due to the average lower use of pointers (specially strings), and cleaner code in Pascal.
I think endianess and alignment causes much more problems (when porting old x86 codebases to other processors) long term than 64-bit problems, specially for people that need cross platform binary compability from time to time. How does GPC deal with that?