login

12 Considerations

12.1 The C++ versus the C interface

Not all functionality of the C-interface is provided, but as PlTerm and term_t are essentially the same thing with automatic type-conversion between the two, this interface can be freely mixed with the functions defined for plain C.

Using this interface rather than the plain C-interface requires a little more resources. More term-references are wasted (but reclaimed on return to Prolog or using PlFrame). Use of some intermediate types (functor_t etc.) is not supported in the current interface, causing more hash-table lookups. This could be fixed, at the price of slighly complicating the interface.

12.2 Static linking and embedding

The mechanisms outlined in this document can be used for static linking with the SWI-Prolog kernel using plld(1). In general the C++ linker should be used to deal with the C++ runtime libraries and global constructors. As of SWI-Prolog 3.2.9, PL_register_foreign() can be called before PL_initialise(), which is required to handle the calls from the global PlRegister calls.

12.3 Status and compiler versions

The current interface is entirely defined in the .h file using inlined code. This approach has a few advantages: as no C++ code is in the Prolog kernel, different C++ compilers with different name-mangling schemas can cooperate smoothly.

Also, changes to the header file have no consequences to binary compatibility with the SWI-Prolog kernel. This makes it possible to have different versions of the header file with few compatibility consequences. If the interface stabilises we will consider options to share more code.

12.4 Limitations

Currently, the following limitations are recognised: