|Did you know ...
|Status and compiler versions (version 2)
The current interface can be entirely defined in the
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. However, inlining
everything can lead to code bloat, so the larger functions and methods
have been put into a
.cpp file that can be either compiled
separately (by the same compiler as used by the foreign predicate) or
inlined as if it were part of the
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.
As of 2023-04, some details remain to be decided, mostly to do with
encodings. A few methods have a
parameter (e.g., PlTerm::as_string()),
but this hasn't yet been extended to all methods that take or return a
string. Also, the details of how the default encoding is set have not
yet been decided.
As of 2023-04, the various error convenience classes do not fully
match what the equivalent C functions do. That is,
does not result in the same context and traceback information that would
Plx_instantiation_error(A1. unwrap()); throw PlFail().
The Plx_*() wrappers may require small adjustments in whether their
return values require
[[nodiscard]] or whether their return
values should be treated as an error.
The implementation of
PlException is likely to change
somewhat in the future. Currently, to ensure that the exception term has
a sufficient lifetime, it is serialized using PL_record_external().
In future, if this proves unnecessary, the term will be stored as-is.
The API will not change if this implementation detail changes.