Hello!
I would like to write some code that will be static linked with C application. In addition, I would like to avoid linking system and rtl units and would use only routines that come with C app and library (I heard that combining fpc rtl with C application is not a good idea and there are problems with initialization/finalization sections). I know that some of language constructs and types require additional code (such as memory management, etc.), which I would avoid. I know that following types require extra code:
object, class, sting, dynamic array, try..except.
What else should I avoid?

Regards,
Michał.

The system unit implements parts of the language that are too complex to generate directly in the compiler. Which parts these are depend, a.o., on the target architecture and the target operating system.

It is therefore not possible to give an answer to your question that is generally valid. Furthermore, the answer could become wrong at any time because all of that is implementation-dependent.

Jonas

I was hoping that maybe there is an easy answer. But I understand. Thanks.

Michał.

W dniu 2017-01-19 o 20:28, Jonas Maebe pisze:

gabor wrote

problems with initialization/finalization sections).

...

I know that following types require extra code: object, class, sting, dynamic array, try..except. What else should I avoid?

I think it is a huge exaggeration to rule out all of that. I think that most of this stuff from basic language or system unit should work just fine. Indeed some might not work, but most should work.

If you use the unit cmem (or even better if you make your own memory manager that redirects to the C side), I don't see why object/class/string/dynamic arrays should fail, when used internally in the Pascal side.

try...except will probably indeed not work, because C often uses a different exception mask than FPC or something like that.

I didn't try it myself recently, but instead of going bare-bones I would rule out stuff that fails when they fail, not beforehand suppose they won't work.

gabor wrote

I was hoping that maybe there is an easy answer. But I understand. Thanks.

The easy answer is just to use the system unit and have no fear...

The main issue with using fpc with C is when you try to use classes or try to use C++ classes

As objects are not so portable across languages.. Every language has their own object format. Also strings, being reference counted, will cause some issues unless you convert them to pchar when sending in as a read only to C, or if C writes to the string buffer you have to send a buffer in that is allocated by you (or a fixed buffer) rather than sending in an Ansistring. Memory managers will conflict. Or use shared memory manager. But C knows nothing about what a modern pascal reference counted ansistring is.. it has no information about it.

Forgot to mention, you can also write your own system unit and swap it in place (in delphi and fpc). You can modify existing system unit or even rewrite your own system unit from scratch..

KOL/mck project does this sort of thing to decrease executable size to a miniature size. Embedded programmers sometimes write their own system unit too, for size constraints or special situations on embedded systems.

So don't feel that you are limited to the system.pp unit that you are provided with delphi for fpc, as you can modify it... or even rewrite it from scratch (not for faint of heart, but Kol/mck does something like it)

This significantly complicates my project. I would avoid this. After a few tests, I can say that it works correctly with the linked system unit and cmem. Unfortunately, this greatly complicates build process which is disproportionate to amount of code. So I decided to do it in C for now.

Thanks.
Michał.

W dniu 2017-01-22 o 08:01, Lars pisze:

Forgot to mention, you can also write your own system unit and swap it in place (in delphi and fpc). You can modify existing system unit or even rewrite your own system unit from scratch..