This document describes version 2 of the C++ interface. Version 1
is considered deprecated. Version 2 is implemented by
SWI-cpp2.h and SWI-cpp2.cpp. This is a much
more mature C++ interface has been designed and implemented by Peter
Ludemann.
Version 1 is in SWI-cpp.h; version 2 is in SWI-cpp2.h,
SWI-cpp2.cpp, SWI-cpp2-plx.h, and SWI-cpp2-atommap.h.
The overall structure of the API has been retained - that is, it is a
thin layer of lightweight classes on top of the interface provided by
SWI-Prolog.h. Based on experience with the API, most of the
conversion operators and some of the comparison operators have been
removed or deprecated, and replaced by “getter” methods; the
overloaded constructors have been replaced by subclasses for the various
types. Some changes were also made to ensure that the
[]PlTerm and PlTermv
doesn't cause unexpected implicit conversions.1If
there is an implicit conversion operator from PlTerm to term_t
and also to char*, then the []f is overloaded to accept a term_t
or char* in the code PlTerm t=...; f(t[0]).
Prolog errors are now converted to C++ exceptions (which contain the
exception term rather being a subclass of PlTerm as in
version 1), where they can be caught and thrown using the usual C++
mechanisms; and the subclasses that create exceptions have been changed
to functions. In addition, an exception type PlFail has
been added, together with PlCheckFail, to allow more
compact code by “short circuit” return to Prolog on failure.
A convenience class for creating blobs has been added, so that an existing structure can be converted to a blob with only a few lines of code. More specifically:
SWI-cpp2.cpp has been added, containing the
implementation of some functions. This is included by default from SWI-cpp2.h
or can be compiled separately.SWI-Prolog.h, and have the same names with the “PL” replaced
by “Plx” .2 “Pl” is
used throughout the SWI-cpp2.h interface, and the “x” is
for “eXtended with eXception handling.’ Where
appropriate, these check return codes and throw a C++ exception (created
from the Prolog error). See section
1.6.4. Many of these wrapper functions are also methods in the PlAtom
and PlTerm classes, with the arguments changed from
atom_t and term_t to PlAtom and PlTerm
and in some cases char* and wchar_t* changed
to std::string and std::wstring. These
wrappers are available if you include SWI-cpp2.h (they are
in a separate SWI-cpp2-plx.h file for ease of maintenance).false from a foreign predicate to
indicate failure, you can throw PlFail(). The convenience
function PlCheckFail(rc) can
be used to throw PlFail() if false is returned from
a function in
SWI-Prolog.h. If the wrapper functions or class methods are
used, Prolog errors result in a C++ PlException exception.3If
a “Plx_” wrapper is used to call a SWI-Prolog.h
function, a Prolog error will have already resulted in throwing PlException;
PlCheckFail(rc) is used to
additionally throw
PlFail, similar to returning false from the
top-level of a foreign predicate - Prolog will check for an error and
call throw/1 if
appropriate.PlException class is now a subclass of std::exception
and encapsulates a Prolog error. Prolog errors are converted into throw PlException(...).
If the user code does not catch the PlException, the PREDICATE()
macro converts the error to a Prolog error upon return to the Prolog
caller.(char*)t, (int64_t)t,
static_cast<char*>(t)) have been deprecated, replaced
by “getters” (e.g.,
t.as_string(), t.as_int64_t()).std::string, comparison operators. The PlTerm::as_string()
method allows specifying the encoding to use whereas the ==char* have been replaced by methods
that return std::string to ensure that lifetime issues
don't cause subtle bugs.4If you
want to return a char* from a function, you should not do return
t.as_string().c_str()
because that will return a pointer to local or stack memory. Instead,
you should change your interface to return a std::string
and apply the c_str() method to it. These lifetime
errors can sometimes be caught by specifying the Gnu C++ or
Clang options -Wreturn-stack-address or -Wreturn-local-addr
- as of 2023-04, Clang seems to do a better analysis.char*
or wchar_t* arguments also accept std::string
or std::wstring arguments. Where possible, encoding
information can also be specified.PlString has been renamed to PlTerm_string
to make it clear that it's a term that contains a Prolog string.PL_...(term_t, ...) methods have been added to PlTerm,
and PL_...(atom_t, ...) methods have been added to PlAtom.
Where appropriate, the arguments use PlTerm, PlAtom,
etc. instead of term_t, atom_t, etc.int for
true/false now return a C++ bool.term_t, atom_t,
etc.) have been renamed from handle, ref, etc.
to
C_.5This is done by
subclassing from Wrapped<term_t>, Wrapped<atom_t>,
etc., which define the field C_, standard constructors, the
methods is_null(), not_null(), reset(),
reset(v), reset_wrapped(v), plus the constant null.
This value can be accessed by the unwrap() and unwrap_as_ptr()
methods. There is also a “friend” function PlUnwrapAsPtr().PlControl::context_unique_ptr<ContextType>()
has been added, to simplify dynamic memory allocation in
non-deterministic predicates.PlStringBuffers provides a simpler interface for
allocating strings on the stack than PL_STRINGS_MARK() and PL_STRINGS_RELEASE().
However, this is mostly not needed because most functions now use std::string:
see section 1.6.9.1.PlStream provides a simpler interface for streams than
PL_get_stream(), PL_acquire_stream(), and PL_release_stream().
See section 1.6.9.2.record_t have been added. The
PlRecordExternalCopy class contains the opaque handle, as a
convenience.control_t has been added and the
PREDICATE_NONDET() has
been modified to use it.More details on the rationale and how to port from version 1 to version 1 are given in section 1.8 and section 1.9.
Here is the “simple example” in the Foreign Language Interface, rewritten in C++. As before, it is compiled by
swipl-ld -o calc -goal true calc.cpp calc.pl
#include <string>
#include <SWI-cpp2.h>
int main(int argc, char **argv) {
PlEngine e(argv[0]);
// combine all the arguments in a single string
std::string expression;
for (int n = 1; n < argc; n++) {
if (n != 1) {
expression.append(" ");
}
expression.append(argv[n]);
}
// Lookup calc/1 and make the arguments and call
PlPredicate pred("calc", 1, "user");
PlTerm_string h0(expression);
PlQuery q(pred, PlTermv(h0), PL_Q_NORMAL);
return q.next_solution() ? 0 : 1;
}
The file test_cpp.cpp contains examples of Prolog predicates written in C++. This file is used for testing (called from test_cpp.pl). Notable examples:
A3 is A1+A2, converting the sum to an integer if
possible.bagof(Sqrt, X^(between(0,4,X), Sqrt is sqrt(X)), A2).
The file
likes.cpp
contains a simple program that calls the Prolog predicate likes/2
and
happy/1 (these
predicates are defined in
likes.pl.
The usage and how to compile the code are in comments in likes.cpp
C++ provides a number of features that make it possible to define a more natural and concise interface to dynamically typed languages than plain C does. Using type-conversion (casting) and overloading, native data-types can be easily translated into appropriate Prolog types, automatic destructors can be used to deal with most of the cleanup required and C++ exception handling can be used to map Prolog exceptions and interface conversion errors to C++ exceptions, which are automatically mapped to Prolog exceptions as control is turned back to Prolog.
However, there are subtle differences between Prolog and C++ that can lead to confusion; in particular, the lifetime of terms do not fit well with the C++ notion of constructor/destructor. It might be possible to handle this with “smart pointers” , but that would lead to other complications, so the decision was made to provide a thin layer between the underlying C functions and the C++ classes/methods/functions.
More information on the SWI-Prolog native types is given in Interface Data Types.
It would be tempting to use C++ implicit conversion operators and
method overloading to automatically convert between C++ types such as
std::string and int64_t and Prolog foreign
language interface types such as term_t and atom_t.
However, types such as term_t are unsigned integers, so
many of the automatic type conversions can inadvertently do something
other than what the programmer intended, resulting in subtle bugs that
are difficult to find. Therefore Version 2 of this interface reduces the
amount of automatic conversion and introduces some redundancy, to avoid
these subtle bugs, by using “getter” methods rather than
conversion operators, and using naming conventions for explicitly
specifying constructors.
I would like to thank Anjo Anjewierden for comments on the definition, implementation and documentation of the original C++ interface. Peter Ludemann implemented the current version (2) of the interface (see section 1.1).
A foreign predicate is defined using the PREDICATE()
macro, plus a few variations on this, such as
PREDICATE_NONDET(), NAMED_PREDICATE(),
and
NAMED_PREDICATE_NONDET().
These define an internal name for the function, register it with the
SWI-Prolog runtime (where it will be picked up by the use_foreign_library/1
directive), and define the names A1, A2, etc.
for the arguments.6You can define
your own names for the arguments, for example: auto dir=A1, db=A2;
or PlTerm options(A3);. If a non-deterministic
predicate is being defined, an additional parameter handle
is defined (of type
PlControl).
The foreign predicate returns a value:
true - successfalse - failure or an error (see section
1.15 and Prolog
exceptions in foreign code).The C++ API provides Plx_*() functions that are the same as the PL_*() functions except that where appropriate they check for exceptions and thrown a PlException().
Addditionally, the function PlCheckFail()
can be used to check for failure and throw a PlFail
exception that is handled before returning to Prolog with failure.
The following three snippets do essentially the same thing (for
implementing the equivalent of =/2); however the first version (with
PlTerm::unify_term())
and second version (with Plx_unify()) throw a C++ PlExceptionFail
exception if there's an error and otherwise return true or false;
the third version (with PlCheckFail())
throws a PlFail exception for failure (and PlExceptionFail
for an error) and otherwise returns true - the PREDICATE()
wrapper handles all of these appropriately and reports the same result
back to Prolog; but you might wish to distinguish the two situations in
more complex code.
PREDICATE(eq, 2)
{ return A1.unify_term(A2);
}
PREDICATE(eq, 2)
{ return Plx_unify(A1.unwrap(), A2.unwrap()));
}
PREDICATE(eq, 2)
{ PlCheckFail(A1.unify_term(A2));
return true;
}
One useful area for exploiting C++ features is type-conversion.
Prolog variables are dynamically typed and all information is passed
around using the C-interface type term_t. In C++,
term_t is embedded in the lightweight class
PlTerm. Other lightweight classes, such as PlAtom
for
atom_t are also provided. Constructors and operator
definitions provide flexible operations and integration with important
C-types (char*, wchar_t*, long
and
double), plus the C++-types (std::string,
std::wstring). (char* and wchar_t*
are deprecated in the C++ API; std::string and
std::wstring are safer and should be used instead.)
Another useful area is in handling errors and cleanup. Prolog errors can be modeled using C++ exceptions; and C++'s destructors can be used to clean up error situations, to prevent memory and other resource leaks.
See also section 1.6.5 for more on naming conventions and standard methods.
The general philosophy for C++ classes is that a “half-created” object should not be possible - that is, the constructor should either succeed with a completely usable object or it should throw an exception. This API tries to follow that philosophy, but there are some important exceptions and caveats. (For more on how the C++ and Prolog exceptions interrelate, see section 1.15.)
Most of the PL_*() functions have corresponding wrapper methods. For example, PlTerm::get_atom() calls Plx_get_atom(), which calls PL_get_atom(). If the PL_get_atom() has an error, it creates a Prolog error; the Plx_get_atom() wrapper checks for this and converts the error to a C++ exception, which is thrown; upon return to Prolog, the exception is turned back into a Prolog error. Therfore, code typically does not need to check for errors.
Some functions return false to indicate either failure
or an error, for example PlTerm::unify_term();
for such methods, a check is made for an error and an exception is
thrown, so the return value of
false only means failure. (The whole thing can be wrapped
in
PlCheckFail(), in which case a PlFail
exception is thrown, which is converted to failure in Prolog.) For more
on this, see
section 1.6.4, and for handling
failure, see
section 1.13.1.
For PL_*() functions that take or return char* or
wchar_t* values, there are also wrapper functions and
methods that use std::string or std::wstring.
Because these copy the values, there is usually no need to enclose the
calls with
PlStringBuffers (which wraps PL_STRING_MARK() and
PL_STRING_RELEASE()). See also the rationale for string:
section 1.8.2.
Many of the classes (PlAtom, PlTerm, etc.)
are thin wrappers around the C interface's types (atom_t,
term_t, etc.). As such, they inherit the concept of “null” from
these types (which is abstracted as PlAtom::null,
PlTerm::null, etc., which typically is equivalent to
0). Normally, you shouldn't need to check whether the
object is “fully created” , for the rare situations where a
check is needed, the methods is_null()
and not_null() are provided.
Most of the classes have constructors that create a “complete” object. For example,
PlAtom foo("foo");
will ensure that the object foo is useable and will
throw an exception if the atom can't be created. However, if you choose
to create a PlAtom object from an atom_t
value, no checking is done (similarly, no checking is done if you create
a PlTerm object from a term_t value).
In many situations, you will be using a term; for these, there are special constructors. For example:
PlTerm_atom foo("foo"); // Same as PlTerm(PlAtom("foo"))
PlTerm_string str("a string");
To help avoid programming errors, some of the classes do not have a
default “empty” constructor. For example, if you with to
create a
PlAtom that is uninitialized, you must explicitly use
PlAtom(PlAtom::null).
This make some code a bit more cumbersome because you can't omit the
default constructors in struct initalizers.
Many of the classes have an as_string()
method7This might be changed in
future to to_string(), to be consistent with std::to_string(),
which is useful for debugging.
The method names such as
as_int32_t() were chosen itnstead of to_int32_t() because
they imply that the representation is already an int32_t,
and not that the value is converted to a int32_t. That is,
if the value is a float, int32_t will fail with an error
rather than (for example) truncating the floating point value to fit
into a 32-bit integer.
Many of the classes wrap long-lived items, such as atoms, functors,
predicates, or modules. For these, it's often a good idea to define them
as static variables that get created at load time, so that
a lookup for each use isn't needed (atoms are unique, so
PlAtom("foo") requires
a lookup for an atom foo and creates one if it isn't
found).
C code sometimes creates objects “lazily” on first use:
void my_function(...)
{ static atom_t ATOM_foo = 0;
...
if ( ! foo )
foo = PL_new_atom("foo");
...
}
For C++, this can be done in a simpler way, because C++ will call a
local “static” constructor on first use.
void my_function(...)
{ static PlAtom ATOM_foo("foo");
}
The class PlTerm (which wraps term_t) is
the most used. Although a PlTerm object can be created from
a term_t value, it is intended to be used with a
constructor that gives it an initial value. The default constructor
calls PL_new_term_ref() and throws an exception if this fails.
The various constructors are described in
section 1.6.6. Note that the
default constructor is not public; to create a “variable” term,
you should use the subclass constructor PlTerm_var().
The following files are provided:
SWI-cpp2.h - Include this file to get the C++ API. It
automatically includes
SWI-cpp2-plx.h and SWI-cpp2.cpp, unless the
macro _SWI_CPP2_CPP_SEPARATE is defined, in which case you
must compile SWI-cpp2.cpp separately.
SWI-cpp2.cpp - Contains the implementations of some
methods and functions. If you wish to compile this separately, you must
define the macro _SWI_CPP2_CPP_SEPARATE before your include
for SWI-cpp2.h.
SWI-cpp2-plx.h - Contains the wrapper functions for the
most of the functions in
SWI-Prolog.h. This file is not intended to be used by
itself, but is #included by SWI-cpp2.h.
SWI-cpp2-atommap.h - Contains a utility class for
mapping atom-to-atom or atom-to-term, which is useful for naming
long-lived blobs instead of having to pass them around as arguments.
test_cpp.cpp, test_cpp.pl - Contains
various tests, including some longer sequences of code that can help in
understanding how the C++ API is intended to be used. In addition, there
are test_ffi.cpp, test_ffi.pl, which often
have the same tests written in C, without the C++ API.
The list below summarises the classes defined in the C++ interface.
term_t (for more details on term_t,
see
Interface
Data Types).
This is a “base class” whose constructor is protected; subclasses specify the actual contents. Additional methods allow checking the Prolog type, unification, comparison, conversion to native C++-data types, etc. See section 1.11.1.
For more details about PlTerm, see section
1.6.6
PlTerm with constructors for building compound
terms. If there is a single string argument, then PL_chars_to_term()
or PL_wchars_to_term() is used to parse the string and create the
term. If the constructor has two arguments, the first is name of a
functor and the second is a PlTermv with the arguments.[]PlTermv
is used to build complex terms and provide argument-lists to Prolog
goals.atom_t in their internal Prolog representation for
fast comparison. (For more details on
atom_t, see
Interface
Data Types). For more details of PlAtom, see section
1.11.12.4.functor_t, which maps to the internal
representation of a name/arity pair.predicate_t, which maps to the internal
representation of a Prolog predicate.module_t, which maps to the internal
representation of a Prolog module.PlException object and throws it. If the
enclosing code doesn't intercept the exception, the PlException
object is turned back into a Prolog error when control returns to Prolog
from the PREDICATE() macros.
This is a subclass of PlExceptionBase, which is a subclass
of std::exception.return false instead
if failure is expected. An error can be signaled by calling
Plx_raise_exception() or one of the PL_*_error() functions
and then throwing PlFail; but it's better style to create
the error throwing one of the subclasses of PlException
e.g.,
throw PlTypeError("int", t). Subclass of PlExceptionFailBase.PlException object, so a PlExceptionFail
object is thrown. This is turned into failure by the PREDICATE()
macro, resulting in normal Prolog error handling. Subclass of PlExceptionFailBase.std::exception, to
allow catching
PlException, PlExceptionFail or PlFail
in a single “catch” clause.PlExceptionBase, to
allow catching
PlExceptionFail or PlFail in a single “catch” clause,
excluding PlException.
The various PL_*() functions in SWI-Prolog.h have
corresponding Plx_*() functions, defined in SWI-cpp2-plx.h,
which is always included by SWI-cpp2.h. There are three
kinds of wrappers, with the appropriate one being chosen according to
the semantics of the wrapped function:
false,
indicating an error. The Plx_*() function checks for this and throws a PlException
object containing the error. The wrapper uses template<typename
C_t> C_t PlEx(C_t rc),
where C_t is the return type of the PL_*() function.
true if it succeeds and false if it fails or
has a runtime error. If it fails, the wrapper checks for a Prolog error
and throws a PlException object containing the error. The
wrapper uses template<typename C_t> C_t PlWrap(C_t
rc), where C_t is the return type of the PL_*()
function.
A few PL_*() functions do not have a corresponding Plx*() function
because they do not fit into one of these categories. For example,
PL_next_solution() has multiple return values (PL_S_EXCEPTION,
PL_S_LAST, etc.) if the query was opened with the
PL_Q_EXT_STATUS flag.
Most of the PL_*() functions whose first argument is of type
term_t, atom_t, etc. have corresponding
methods in classes PlTerm, PlAtom, etc.
Important: You should use the Plx_*() wrappers only in the context of a PREDICATE() call, which will handle any C++ exceptions. Some blob callbacks can also handle an exception (see section 1.6.8). Everywhere else, the result of calling a Plx_*() function is unpredicatable - probably a crash.
See also the discussion on design philosophy in section 1.6.1.
The classes all have names starting with “Pl” , using CamelCase; this contrasts with the C functions that start with “PL_” and use underscores.
The wrapper classes (PlFunctor, PlAtom,
PlTerm), etc. all contain a field C_ that
contains the wrapped value (functor_t, atom_t, term_t
respectively). If this wrapped value is needed, it should be accessed
using the unwrap() or unwrap_as_ptr() methods.
In some cases, it's natural to use a pointer to a wrapper class. For
those, the function PlUnwrapAsPtr() returns nullptr
if the pointer is null; otherwise it returns the wrapped value (which
itself might be some kind of “null” ).
The wrapper classes, which subclass WrappedC<...>,
all define the following methods and constants:
null).
Some classes do not have a default constructor because it can lead to
subtle bugs - instead, they either have a different way of creating the
object or can use the “null” value for the class.PlAtom,
the constructor takes an atom_t value).C_ - the wrapped value. This can be used directly when
calling C functions, for example, if t and a
are of type PlTerm and PlAtom: PlEx(PL_put_atom(t.unwrap(),a.unwrap()))
(although it's better to do Plx_put_atom(t.unwrap(),a.unwrap()),
which does the check).null - the null value (typically 0, but
code should not rely on this).is_null(), not_null()
- test for the wrapped value being null.reset() - set the
wrapped value to nullreset(new_value) - set the wrapped value from the
wrapped type (e.g., PlTerm::reset(term_t new_value))reset_wrapped(new_value) - set the wrapped value from
the same type (e.g., PlTerm::reset_wrapped(PlTerm new_value))bool operator is disabled - you should use not_null()
instead.8The reason: a bool
conversion causes ambiguity with PlAtom(PlTterm)
and PlAtom(atom_t).
The method unwrap() can be used to access the C_
field, and can be used wherever a atom_t or term_t
is used. For example, the PL_scan_options() example code can be
written as follows. Note the use of &callback.unwrap()
to pass a pointer to the wrapped term_t value.
PREDICATE(mypred, 2)
{ auto options = A2;
int quoted = false;
size_t length = 10;
PlTerm_var callback;
PlCheckFail(PL_scan_options(options, 0, "mypred_options", mypred_options,
"ed, &length, &callback.unwrap()));
callback.record(); // Needed if callback is put in a blob that Prolog doesn't know about.
// If it were an atom (OPT_ATOM): register_ref().
<implement mypred>
}
For functions in SWI-Prolog.h that don't have a C++
equivalent in SWI-cpp2.h, PlCheckFail()
is a convenience function that checks the return code and throws a PlFail
exception on failure or PlException if there was an
exception. The enclosing PREDICATE()
code catches PlFail exceptions and converts them to the foreign_t
return code for failure. If the failure from the C function was due to
an exception (e.g., unification failed because of an out-of-memory
condition), the foreign function caller will detect that situation and
convert the failure to an exception.
The “getter” methods for PlTerm all throw an
exception if the term isn't of the expected Prolog type. The “getter” methods
typically start with “as” , e.g. PlTerm::as_string().
There are also other “getter” methods, such as PlTerm::get_float_ex()
that wrap PL_*() functions.
“getters” for integers have an additional problem, in
that C++ doesn't define the sizes of int, long,
or
size_t. It seems to be impossible to make an overloaded
method that works for all the various combinations of integer types on
all compilers, so there are specific methods for int64_t,
uint64_t, size_t.
In some cases,it is possible to overload methods; for example, this
allows the following code without knowing the exact definition of
size_t:
PREDICATE(p, 1)
{ size_t sz;
A1.integer(&sz);
...
}
It is strongly recommended that you enable conversion checking.
For example, with GNU C++, use these options (possibly with -Werror):
-Wconversion -Warith-conversion -Wsign-conversion
-Wfloat-conversion.
There is an additional problem with characters - C promotes them to int
but C++ doesn't. In general, this shouldn't cause any problems, but care
must be used with the various getters for integers.
As we have seen from the examples, the PlTerm class
plays a central role in conversion and operating on Prolog data. This
section provides complete documentation of this class.
There are a number of subclasses that exist only to provide a safe
way of constructing at term. There is also a subclass (PlTermScoped)
that helps reclaim terms.
Most of the PlTerm constructors are defined as
subclasses of
PlTerm, with a name that reflects the Prolog type of what
is being created (e.g., PlTerm_atom creates a term from an
atom;
PlTerm_string creates a term from a Prolog string). This is
done to ensure that the there is no ambiguity in the constructors - for
example, there is no way to distinguish between term_t,
atom_t, and ordinary integers, so there are constructors
PlTerm(), PlTerm_atom(), and PlTerm_integer. All of the
constructors are “explicit” because implicit creation of PlTerm
objects can lead to subtle and difficult to debug errors.
If a constructor fails (e.g., out of memory), a PlException
is thrown. The class and subclass constructors are as follows.
term_t. This is a
lightweight class, so no code is generated.PlTerm with constructors for building a term
that contains a Prolog integer from a
long.9PL_put_integer()
takes a long argument.PlTerm with constructors for building a term
that contains a Prolog integer from a int64_t.PlTerm with constructors for building a term
that contains a Prolog integer from a uint64_t.PlTerm with constructors for building a term
that contains a Prolog integer from a size_t.PlTerm with constructors for building a term
that contains a Prolog float.PlTerm with constructors for building a term
that contains a raw pointer. This is mainly for backwards compatibility;
new code should use blobs. A pointer is represented in Prolog
as a mangled integer. The mangling is designed to make most pointers fit
into a tagged-integer. Any valid pointer can be represented.
This mechanism can be used to represent pointers to C++ objects in
Prolog. Please note that MyClass should define conversion
to and from void *.
PREDICATE(make_my_object, 1)
{ auto myobj = new MyClass();
return A1.unify_pointer(myobj);
}
PREDICATE(my_object_contents, 2)
{ auto myobj = static_cast<MyClass*>(A1.as_pointer());
return A2.unify_string(myobj->contents);
}
PREDICATE(free_my_object, 1)
{ auto myobj = static_cast<MyClass*>(A1.as_pointer());
delete myobj;
return true;
}
PlTerm with constructors for building a term
that contains a Prolog string object. For constructing a term from the
text form, see
PlCompound.PlTerm with constructors for building Prolog
lists of character integer values.PlTerm with constructors for building Prolog
lists of one-character atoms (as atom_chars/2).PlTerm for building and analysing Prolog lists.The methods are:
std::string. If you use this, be sure to
wrap it with PlStringBuffers, and if you use the BUF_MALLOC
flag, you can use std::unique_ptr<char, decltype(&PL_free)>
to manage the pointer.std::wstring.
If you use this, be sure to wrap it with PlStringBuffers,
and if you use the BUF_MALLOC flag, you can use std::unique_ptr<char,
decltype(&PL_close)> to manage the pointer.PL_FILE_NOERRORS
- throws PlFail on failure, which is interpreted by the
enclosing PREDICATE as either failure or an error,
depending on the flag bit PL_FILE_NOERRORS.PL_VARIABLE, PL_ATOM,
etc, throwing an exception on Prolog error. bois_atom() or is_string().PlTypeError if PlTerm::is_attvar()
fails.PlTypeError if PlTerm::is_variable()
fails.PlTypeError if PlTerm::is_ground()
fails.PlTypeError if PlTerm::is_atom()
fails.PlTypeError if PlTerm::is_integer()
fails.PlTypeError if PlTerm::is_string()
fails.PlTypeError if PlTerm::is_atom_or_string()
fails.PlTypeError if PlTerm::is_float()
fails.PlTypeError if PlTerm::is_rational()
fails.PlTypeError if PlTerm::is_compound()
fails.PlTypeError if PlTerm::is_callable()
fails.PlTypeError if PlTerm::is_list()
fails.PlTypeError if PlTerm::is_dict()
fails.PlTypeError if PlTerm::is_pair()
fails.PlTypeError if PlTerm::is_atomic()
fails.PlTypeError if PlTerm::is_number()
fails.PlTypeError if PlTerm::is_acyclic()
fails.PlRecord constructed from the term. Same as PlRecord(*this).std::string.
The flags BUF_MALLOC, BUF_STACK, and BUF_ALLOW_STACK
are ignored and replaced by BUF_DISCARDABLE. The call to PL_get_nchars()
is wrapped in a PlStringBuffers so that any generated
string is freed when the result is returned by copying to a std::string.std::wstring.
The flags BUF_MALLOC, BUF_STACK, and BUF_ALLOW_STACK
are ignored and replaced by BUF_DISCARDABLE.PlTypeError if not a
"compound" or atom.PlTypeError if not a "compound"
or atom.nullptr. Returns false if the term
isn't a compound or atom.PlResourceError).PlTerm::null.
Does not reset the wrapped term. This is used implicitly in
PlTermScoped’s destructor, which does reset the
wrapped term.PlTermScoped’s destructor, which does reset the
wrapped term.false
if unification fails. If on failure, there isn't an immediate return to
Prolog (e.g., by wrapping the call with
PlCheckFail()), this method
should be called within the context of PlFrame, and PlFrame::rewind()
should be called.compare(t2) == 0.compare(t2) != 0.compare(t2) < 0.compare(t2) > 0.compare(t2) <= 0.compare(t2) >= 0.
This class is experimental and subject to change.
Normally all term references in a scope are discarded
together or all term references created after a specific one are
reclaimed using PlTerm::reset_term_refs(). A PlTermScoped
object is the same as a PlTerm object except that
PL_free_term_ref() is called on its wrapped term when the object
goes out of scope. This shrinks the current foreign frame if the term is
the last one in the frame and otherwise it marks it for reuse.
Here is an example, where PlTermScoped is inside a
for-loop. If PlTerm were used instead, the stack would grow
by the number of items in the array; PlTermScoped ensures
that stack doesn't grow.10Assuming
that unify_atom_list() is called from a predicate implementation,
if PlTerm were used instead of PlTermCopy, all
the created terms would be discarded when the Prolog stack frame is
unwound; the use of PlTermScoped reuses the terms in that
stack frame. A slightly more effiicient way of preventing
the Prolog stack from growing is to use PlTerm::put_term()
to reuse a term reference; but that is more difficult to understand and
also more error-prone.
bool
unify_atom_list(const std::vector<std::string>& array, PlTerm list)
{ PlTermScoped tail(list); // calls PL_copy_term_ref() to copy `list`
for( auto item : array )
{ PlTermScoped head; // var term
PlCheckFail(tail.unify_list(head, tail));
PlCheckFail(head.unify_chars(PL_ATOM, item));
}
return tail.unify_nil();
}
The design of PlTermScoped is modeled on
std::unique_ptr11unique_ptr
was originally called scoped_ptr in the Boost libraries,
but the name was changed to contrast with std::shared_ptr,
which is reference-counted. and uses move semantics
to ensure safety.12Move
semantics are a relatively new feature in C++ and can be a bit
difficult to understand. Roughly speaking, a move is a copies
the object and then calls its destructor, so that any further use of the
object is an error. If an object defines move methods or constructors,
it can optimize this operation, and also can catch certain kinds of
errors at compile time.
A PlTermScoped object can be created either with or
without a wrapped term - the PlTermScoped::reset()
method sets (or nulls) the wrapped term. A PlTermScoped
object cannot be copied or passed as a value to a function; the PlTermScoped::release()
method returns the wrapped term and resets the PlTermScoped
object so that any further use of the PlTermScoped object
is an error.
As shown in the example above, PlTermScoped can be used
instead of PlTerm, in places where a loop would otherwise
cause the stack to grow. There are limitations on the operations that
are allowed on a PlTermScoped object; in particular, a
PlTermScoped object cannot be copied and cannot be
implicitly converted to a Plterm.
The PlTermScoped constructors always create a new term
ref, by calling either PL_new_term_ref() or PL_copy_term_ref().
If you try to copy or create a PlTermScoped object from
another
PlTermScoped object, you will get a compile-time error; you
can set the value from a PlTerm object, which can be
obtained by calling PlTermScoped::release().
The methods derived from the PL_put_*() and PL_cons_*() functions
should not be used with a PlTermScoped object. If you need
to use these, you can use PlTermScoped::get()
to get a PlTerm, for which a put_*() method can be used.
To copy a PlTermScoped object or to pass it as a value
in a function call, use the PlTermScoped::release()
method or std::move():
PlTermScoped ts(...); PlTerm t; // Copy to a PlTerm: t = ts.release(); // or: t = std::move(ts); // Pass as a value to a function: foo(ts.release()); // or: foo(std::move(ts); // Copy to a PlTermScoped: PlTermScoped ts2; ts2.reset(ts.release()); // or: ts2.reset(std::move(ts));
The methods are (in addition to, or overriding the methods in PlTerm):
PlTermScoped, use PlTermScoped::release()
to convert it to a PlTerm.PlTerm. This is typically used
when calling a function that expects a PlTerm object and
which will not call
PlTerm::free_term_ref()
on it.t2.reset(t.release())
to copy a
PlTermScoped; this can also be written
t2=std::move(t).PlTermScoped objects’wrapped terms.
Nomenclature warning:
There are two different release() functions:
PL_blob_t).unique_ptr.Disclaimer:
The blob API for C++ is not completely general, but is designed to make common use cases easy to write. For other use cases, the underlying C API can still be used. The use case is:
PlBlob, which
provides a number of fields and methods, of which a few can be
overridden in the blob (notably: write_fields(),
compare_fields(), save(), load(), and the
destructor).std::unique_ptr
to manage the blob (that is, the blob is created using the new
operator and is not created on the stack).new operator and
passes ownership to the blob. More complex behavior is possible, using PlAtom::register_ref()
and PlAtom::unregister_ref().A Prolog blob consists of five parts:
PL_blob_t structure that defines the callbacks. The PL_BLOB_DEFINITION()
macro is typically used to create this, with the callbacks pointing to
methods in the C++ blob.PL_blob_t structure, and
optionally a virtual destructor. The PL_BLOB_SIZE macro is
used to define some required methods.std::unique_ptr.
For the PL_blob_t structure, the C++ API provides the
PL_BLOB_DEFINITION(blob_class,blob_name) macro, which references
a set of template functions that allow easily setting up the callbacks.
The C interface allows more flexibility by allowing some of the
callbacks to default; however, the C++ API for blobs provides suitable
callbacks for all of them, using the PL_BLOB_DEFINITION() macro.
For the data, which is subclassed from PlBlob, the
programmer defines the various fields, a constructor that initializes
them, and a destructor. Optionally, override methods can be defined for
one of more of the methods PlBlob::compare_fields(), PlBlob::write_fields(),
PlBlob::save(), PlBlob::load(), PlBlob::pre_delete().
More details on these are given later.
There is a mismatch between how Prolog does memory management (and
garbage collection) and how C++ does it. In particular, Prolog assumes
that cleanup will be done in the release() callback function
associated with the blob whereas C++ typically does cleanup in a
destructor. The blob interface gets around this mismatch by providing a
default release() callback that assumes that the blob was created
using PL_BLOB_NOCOPY and manages memory using a
std::unique_ptr.15This release()
function has nothing to do with std::unique_ptr::release().
More details on this are in
section 1.6.8.1.
The C blob interface has a flag that determines how memory is
managed:
PL_BLOB_NOCOPY. The PL_BLOB_DEFINITION() macro sets
this, so Prolog will call the C++ destructor when the blob is garbage
collected. (This call is done indirectly, using a callback that is
registeered with Prolog.)
The C++ API for blobs only supports blobs with
PL_BLOB_NOCOPY.16The
API can probably also support blobs with PL_BLOB_UNIQUE,
but there seems to be little point in setting this flag for non-text
blobs.
Some slightly obscure features of C++ are used with PlBlob
and
ContextType, and can easily cause subtle bugs or memory
leaks if not used carefully.
When a C++ object is created, its memory is allocated (either on the stack or on the heap using new), and the constructors are called in this order:
There are special forms of the constructor for copying, moving, and
assigning. The “copy constructor” has a signature Type(const
Type& and is used when an object is created by copying, for
example by assignment or passing the object on the stack in a function
call. The “move constructor” has the signature Type(Type&&
and is equivalent to the copy constructor for the new object followed by
the destructor for the old object. (Assignment is usually allowed to
default but can also be specified).
Currently, the copy and move constructors are not used, so it is best to explicitly mark them as not existing:
Type(const Type&) = delete; Type(Type&&) = delete; Type& operator =(const Type&) = delete; Type& operator =(Type&&) = delete;
A constructor may throw an exception - good programming style is to not leave a “half constructed” object but to throw an exception. Destructors are not allowed to throw exceptions,17because the destructor might be invoked by another exception, and C++ has no mechanism for dealing with a second exception. which complicates the API somewhat.
More details about constructors and destructors can be found in the FAQs for constructors and destructors.
Many classes or types have a constructor that simply assigns a
default value (e.g., 0 for int) and the destructor does
nothing. In particular, the destructor for a pointer does nothing, which
can lead to memory leaks. To avoid memory leaks, the smart pointer
std::unique_ptr18The
name “unique” is to distinguish this from a “shared” pointer.
A shared pointer can share ownership with multiple pointers and the
pointed-to object is deleted only when all pointers to the object have
been deleted. A unique pointer allows only a single pointer, so the
pointed-to object is deleted when the unique pointer is deleted.
can be used, whose destructor deletes its managed object. Note that std::unique_ptr
does not enforce single ownership; it merely makes single ownership easy
to manage and it detects most common mistakes, for example by not having
copy constructor or assignment operator.
For example, in the following, the implicit destructor for p
does nothing, so there will be a memory leak when a Ex1
object is deleted:
class Ex1 {
public:
Ex1() : p(new int) { }
int *p;
};
To avoid a memory leak, the code could be changed to this:
class Ex1 {
public:
Ex1() p(new int) { }
~Ex1() { delete p; }
int *p;
};
but it is easier to do the following, where the destructor for
std::unique_ptr will free the memory:
class Ex1 {
public:
Ex1() p(new int) { }
std::unique_ptr<int> p;
};
The same concept applies to objects that are created in code - if a
C++ object is created using new, the programmer must
manage when its destructor is called. In the following, if the call to
data->validate() fails, there will be a memory
leak:
MyData *foo(int some_value) {
MyData *data = new MyData(...);
data->some_field = some_value;
if (! data->validate() )
throw std::runtime_error("Failed to validate data");
return data;
}
Ths could fixed by adding delete data before throwing
the runtime_error; but this doesn't handle the situation of data->validate()
throwing an exception (which would require a catch/throw). Instead, it's
easiser to use std::unique_ptr, which takes care of every
return or exception path:
MyData *foo(int some_value) {
std::unique_ptr<MyData> data(new MyData(...));
data->some_field = some_value;
if (! data->validate() )
throw std::runtime_error("Failed to validate data");
return data.release(); // don't delete the new MyData
}
The destructor for std::unique_ptr will delete the data
when it goes out of scope (in this case, by return or throw) unless the
std::unique_ptr::release() method is called.19The
call to unique_ptr<MYData>::release
doesn't call the destructor; it can be called using std::unique_ptr::get_deleter().
In the code above, the throw will cause the
unique_ptr’s destructor to be called, which will free
the data; but the data will not be freed in the return
statement because of the unique_ptr::release(). Using this style,
a pointer to data on the heap can be managed as easily as data on the
stack. The current C++ API for blobs takes advantage of this - in
particular, there are two methods for unifying a blob:
unique_ptr allows specifying the delete function. For
example, the following can be used to manage memory created with PL_malloc():
std::unique_ptr<void, decltype(&PL_free)> ptr(PL_malloc(...), &PL_free);
or, when memory is allocated within a PL_*() function (in this case, using the Plx_*() wrapper for PL_get_nchars()):
size_t len; char *str = nullptr; Plx_get_nchars(t, &len, &str.get(), BUF_MALLOC|CVT_ALL|CVT_WRITEQ|CVT_VARIABLE|REP_UTF8|CVT_EXCEPTION); std::unique_ptr<char, decltype(&PL_free)> _str(str, &PL_free);
The current C++ API assumes that the C++ blob is allocated on the
heap. If the programmer wishes to use the stack, they can use std::unique_ptr
to automatically delete the object if an error is thrown -
PlTerm::unify_blob(std::unique_ptr<PlBlob>*)
prevents the automatic deletion if unification succeeds.
A unique_ptr needs a bit of care when it is passed as an
argument. The unique_ptr::get() method can be used to get the “raw” pointer;
the delete must not be used with this pointer. Or, the unique_ptr::release()
method can be used to transfer ownership without calling the object's
destructor.
Using unique_ptr::release() is a bit incovenient, so instead
the
unique_ptr can be passed as a pointer (or a reference).
This does not create a new scope, so the pointer must be assigned to a
local variable. For example, the code for unify_blob() is
something like:
bool PlTerm::unify_blob(std::unique_ptr<PlBlob>* b) const
{ std::unique_ptr<PlBlob> blob(std::move(*b));
if ( !unify_blob(blob.get()) )
return false;
(void)blob.release();
return true;
}
The line declaration for blob uses the “move
constructor” to set the value of a newly scoped variable (std::move(*b)
is a cast, so unique_ptr’s move constructor is used).
This has the same effect as calling b->reset(),
so from this point on,
b has the value nullptr.
Alternatively, the local unique_ptr could be set by
std::unique_ptr<PlBlob> blob(b->release());
or
std::unique_ptr<PlBlob> blob; blob.swap(*b);
If the call to PlTerm::unify_blob()
fails or throws an exception, the virtual destructor for blob
is called. Otherwise, the call to blob.release()
prevents the destructor from being called - Prolog now owns the blob
object and can call its destructor when the garbage collector reclaims
it.
TL;DR: Use PL_BLOB_DEFINITION() to define the blob with the
flag
PL_BLOB_NOCOPY and the default PlBlob
wrappers; define your struct as a subclass of PlBlob with
no copy constructor, move constructor, or assignment operator; create a
blob using
std::unique_ptr<PlBlob>(new ...), call PlTerm::unify_blob().
Optionally, define one or more of: compare_fields(), write_fields(),
save(), load() methods (these are described after the
sample code).
In this section, the blob is of type MyBlob, a subclass
of PlBlob. (Example code is given in section
1.6.8.5) and section 1.6.8.7.
A blob is typically created by calling a predicate that does the following:
auto ref = std::unique_ptr<PlBlob>(new MyBlob>(...))}
or
auto ref = std::make_unique<MyBlob>(...);
return PlTerm::unify_blob(&ref);
If unification fails or throws an exception, the object is automatically freed and its destructor is called.
If make_unique() was used to create the pointer, you need to call PlTerm::unify_blob() as follows, because C++'s type inferencing can't figure out that this is a covariant type:
std::unique_ptr<PlBlob> refb(ref.release());
// refb now "owns" the ptr - from here on, ref == nullptr
return A2.unify_blob(&refb);
If unification succeeds, Prolog calls:
ref->release() to pass ownership of the blob to
Prolog (when the blob is eventually garbage collected, the blob's
destructor will be called).
At this point, the blob is owned by Prolog and may be freed by its
atom garbage collector, which will call the blob's destructor (if the
blob shouldn't be deleted, it can override the the PlBlob::pre_delete()
method to return false).
Whenever a predicate is called with the blob as an argument (e.g., as A1),
the blob can be accessed by
PlBlobv<MyBlob>::cast_check(A1.as_atom()).
Within a method, the Prolog blob can be accessed as a term (e.g., for
constructing an error term) using the method MyBlob::symbol_term().
This field is initialized by the call to PlTerm::unify_blob();
if
MyBlob::symbol_term() is called before a successful call to
PlTerm::unify_blob(), MyBlob::symbol_term()
returns a
PlTerm_var.
When the atom garbage collector runs, it frees the blob by first calling the release() callback, which does delete, which calls the destructor MyBlob::~MyBlob(). Note that C++ destructors are not supposed to raise exception; they also should not cause a Prolog error, which could cause deadlock unless the real work is done in another thread.
Often it is desired to release the resources before the garbage collector runs. To do this, the programmer can provide a “close” predicate that is the inverse of the “open” predicate that created the blob. This typically has the same logic as the destructor, except that it can raise a Prolog error.
When a blob is used in the context of a PREDICATE()
macro, it can raise a C++ exception (PlFail or PlException)
and the
PREDICATE() code will convert
the exception to the appropriate Prolog failure or error; memory
allocation exceptions are also handled.
Blobs have callbacks, which can run outside the context of a PREDICATE(). Their exception handling is as follows:
PlAtom::null,
which is interpreted by Prolog as failure.false (or throw a PlException or
PlExceptinFailBase, which will be interpreted as a return
value of false), resulting in the blob not being garbage
collected, and the destructor not being called. Note that this doesn't
work well with final clean-up atom garbage collection, which disregards
the return value and also doesn't respect the ordering of blob
dependencies (e.g., if an iterator blob refers to a file-like blob, the
file-like blob might be deleted before the iterator is deleted).
This code runs in the gc thread. The only PL_*()
function that can safely be called are
PL_unregister_atom() (which is what PlAtom::unregister_ref()
calls).
Here is minimal sample code for creating a blob that owns a
connection to a database. It has a single field (connection)
and defines compare_fields() and write_fields().
A second sample code shows how to wrap a system pointer - section 1.6.8.7
struct MyConnection
{ std::string name;
explicit MyConnection();
explicit MyConnection(const std::string& _name);
bool open();
bool close() noexcept;
void portray(PlStream& strm) const;
};
struct MyBlob;
static PL_blob_t my_blob = PL_BLOB_DEFINITION(MyBlob, "my_blob");
struct MyBlob : public PlBlob
{ std::unique_ptr<MyConnection> connection;
explicit MyBlob()
: PlBlob(&my_blob) { }
explicit MyBlob(const std::string& connection_name)
: PlBlob(&my_blob),
connection(std::make_unique<MyConnection>(connection_name))
{ if ( !connection->open() )
throw MyBlobError("my_blob_open_error");
}
PL_BLOB_SIZE
~MyBlob() noexcept
{ if ( !close() )
Sdprintf("***ERROR: Close MyBlob failed: %s\n", name().c_str()); // Can't use PL_warning()
}
inline std::string
name() const
{ return connection ? connection->name : "";
}
bool close() noexcept
{ if ( !connection )
return true;
bool rc = connection->close();
connection.reset(); // Can be omitted, leaving deletion to ~MyBlob()
return rc;
}
PlException MyBlobError(const char* error) const
{ return PlGeneralError(PlCompound(error, PlTermv(symbol_term())));
}
int compare_fields(const PlBlob* _b_data) const override
{ auto b_data = static_cast<const MyBlob*>(_b_data); // See note about cast
return name().compare(b_data->name());
}
bool write_fields(IOSTREAM *s, int flags) const override
{ PlStream strm(s);
strm.printf(",");
return write_fields_only(strm);
}
bool write_fields_only(PlStream& strm) const
{ if ( connection )
connection->portray(strm);
else
strm.printf("closed");
return true;
}
bool portray(PlStream& strm) const
{ strm.printf("MyBlob(");
write_fields_only(strm);
strm.printf(")");
return true;
}
};
// %! create_my_blob(+Name: atom, -MyBlob) is semidet.
PREDICATE(create_my_blob, 2)
{ // Allocating the blob uses std::unique_ptr<MyBlob> so that it'll be
// deleted if an error happens - the auto-deletion is disabled by
// ref.release() inside unify_blob() before returning success.
auto ref = std::unique_ptr<PlBlob>(new MyBlob(A1.as_atom().as_string()));
return A2.unify_blob(&ref);
}
// %! close_my_blob(+MyBlob) is det.
// % Close the connection, silently succeeding if is already
// % closed; throw an exception if something goes wrong.
PREDICATE(close_my_blob, 1)
{ auto ref = PlBlobV<MyBlob>::cast_ex(A1, my_blob);
if ( !ref->close() )
throw ref->MyBlobError("my_blob_close_error");
return true;
}
// %! portray_my_blob(+Stream, +MyBlob) is det.
// % Hook predicate for
// % user:portray(MyBlob) :-
// % blob(MyBlob, my_blob), !,
// % portray_my_blob(current_output, MyBlob).
PREDICATE(portray_my_blob, 2)
{ auto ref = PlBlobV<MyBlob>::cast_ex(A2, my_blob);
PlStream strm(A1, 0);
return ref->portray(strm);
}
PL_blob_t structure with the wrapper functions and flags
set to PL_BLOB_NOCOPY. It should be declared outside the PlBlob
class and should not be marked const - otherwise, a runtime
error can occur.20The cause of the
runtime error is not clear, but possibly has to do with the order of
initializing globals, which is unspecified for C++.
MyBlob struct is a subclass of PlBlob.
See below for a discussion of the default behaviors.
MyBlob contains a pointer to a MyConnection
object and keeps a copy of the connection's name. The MyConnection
object is handled by a std::unique_ptr smart pointer, so
that it is automatically freed when the MyBlob object is
freed.
PlBlob
constructor.
MyBlob class must not provide a copy or move
constructor, nor an assignment operator (PlBlob has these as
delete, so if you try to use one of these, you will get
a compile-time error).
PlBlob’s constructor sets blob_t_ to
a pointer to the my_blob definition. This is used for
run-time consistency checking by the various callback functions and for
constructing error terms (see PlBlob::symbol_term()).
PlBlob’s acquire() is called by PlBlobV<MyBlob>::acquire()
and fills in the symbol_ field. MyBlob must
not override this - it is not a virtual method. The symbol_
field can be accessed by PlBlob::symbol_term().
MyConnection object. If this fails, an exception is thrown.
The constructor then calls MyConnection::open() and throws an
exception if that fails. (The code would be similar if instead the
constructor for MyConnection also did an open and threw an
exception on failure.)
PL_BLOB_SIZE is boilerplate that defines a
blob_size_() method that is used when the blob is created.
PlUnknownError("..."),
that will try to create a Prolog term, which will crash because the
environment for creating terms is not available. Because
there is no mechanism for reporting an error, the destructor prints a
message on failure (calling
PL_warning() would cause a crash).
PlBlob::close() calls MyConnection::close() and then
frees the object. Error handling is left to the caller because of the
possibility that this is called in the context of garbage collection. It
is not necessary to free the MyConnection object here - if
it is not freed, the
std::unique_ptr<MyConnection>’s
destructor would free it.
0 (``equal” ).
The _b_data argument is of type const PlBlob*
- this is cast to const MyBlob* using a
static_cast. This is safe because Prolog guarantees that
PlBlobV<PlBlob>::compare() will only be called
if both blobs are of the same type.
The flags argument is the same as given to PlBlobV<PlBlob>::write(),
which is a bitwise or of zero or more of the PL_WRT_*
flags that were passed in to the caling PL_write_term() (defined
in SWI-Prolog.h). The
flags do not have the PL_WRT_NEWLINE bit set, so
it is safe to call PlTerm::write() and there is no need for
writing a trailing newline.
If anything in PlBlob::write_fields() throws a C++ exception, it will be caught by the calling PlBlobV<PlBlob>::write() and handled appropriately.
std::unique_ptr<PlBlob>() creates a
MyBlob that is deleted when it goes out of scope. If an exception occurs
between the creation of the blob or if the call to unify_blob()
fails, the pointer will be automatically freed (and the
MyBlob destructor will be called).
PlTerm::unify_blob()
is called with a pointer to a
std::unique_ptr, which takes ownership of the object by
calling std::unique_ptr<PlBlob>::release() and
passes the pointer to Prolog, which then owns it. This also sets ref
to nullptr, so any attempt to use ref after a
call to PlTerm::unify_blob()
will be an error.
If you wish to create a MyBlob object instead of a
PlBlob object, a slightly different form is used:
auto ref = std::make_unique<MyBlob>(...);
...
std::unique_ptr<PlBlob> refb(ref.release());
PlCheckFail(A2.unify_blob(&refb));
return true;
MyBlob pointer using the
PlBlobV<MyBlob>::cast_ex() function, which will
throw a
type_error if the argument isn't a blob of the expected
type.
struct MyFileBlob;
static PL_blob_t my_file_blob = PL_BLOB_DEFINITION(MyFileBlob, "my_file_blob");
static const PlOptionsFlag<int>
MyFileBlob_options("MyFileBlob-options",
{ {"absolute", PL_FILE_ABSOLUTE},
{"ospath", PL_FILE_OSPATH},
{"search", PL_FILE_SEARCH},
{"exist", PL_FILE_EXIST},
{"read", PL_FILE_READ},
{"write", PL_FILE_WRITE},
{"execute", PL_FILE_EXECUTE},
{"noerrors", PL_FILE_NOERRORS} });
struct MyFileBlob : public PlBlob
{ std::FILE* file_;
std::string mode_;
int flags_;
std::string filename_;
std::vector<char> buffer_; // used by read(), to avoid re-allocation
explicit MyFileBlob()
: PlBlob(&my_file_blob) { }
explicit MyFileBlob(PlTerm filename, PlTerm mode, PlTerm flags)
: PlBlob(&my_file_blob),
mode_(mode.as_string())
{ flags_ = MyFileBlob_options.lookup_list(flags);
filename_ = filename.get_file_name(flags_);
file_ = fopen(filename_.c_str(), mode_.c_str());
if ( !file_ ) // TODO: get error code (might not be existence error)
throw PlExistenceError("my_file_blob_open", PlTerm_string(filename_));
// for debugging:
// PlTerm_string(filename.as_string() + "\" => \"" +
// filename_ + "\", \"" + mode_ +
// ", flags=" + MyFileBlob_options.as_string(flags_) + "\")")
}
PL_BLOB_SIZE
std::string read(size_t count)
{ assert(sizeof buffer_[0] == sizeof (char));
assert(sizeof (char) == 1);
buffer_.reserve(count);
return std::string(buffer_.data(),
std::fread(buffer_.data(), sizeof buffer_[0], count, file_));
}
bool eof() const
{ return std::feof(file_);
}
bool error() const
{ return std::ferror(file_);
}
virtual ~MyFileBlob() noexcept
{ if ( !close() )
// Can't use PL_warning()
Sdprintf("***ERROR: Close MyFileBlob failed: (%s)\n", filename_.c_str());
}
bool close() noexcept
{ if ( !file_ )
return true;
int rc = std::fclose(file_);
file_ = nullptr;
return rc == 0;
}
PlException MyFileBlobError(const std::string error) const
{ return PlGeneralError(PlCompound(error, PlTermv(symbol_term())));
}
int compare_fields(const PlBlob* _b_data) const override
{ // dynamic_cast is safer than static_cast, but slower (see documentation)
// It's used here for testing (the documentation has static_cast)
auto b_data = dynamic_cast<const MyFileBlob*>(_b_data);
return filename_.compare(b_data->filename_);
}
bool write_fields(IOSTREAM *s, int flags) const override
{ PlStream strm(s);
strm.printf(",");
return write_fields_only(strm);
}
bool write_fields_only(PlStream& strm) const
{ // For debugging:
// strm.printf("%s mode=%s flags=%s", filename_.c_str(), mode_.c_str(),
// MyFileBlob_options.as_string(flags_).c_str());
strm.printf("%s", filename_.c_str());
if ( !file_ )
strm.printf("-CLOSED");
return true;
}
bool portray(PlStream& strm) const
{ strm.printf("MyFileBlob(");
write_fields_only(strm);
strm.printf(")");
return true;
}
};
PREDICATE(my_file_open, 4)
{ auto ref = std::unique_ptr<PlBlob>(new MyFileBlob(A2, A3, A4));
return A1.unify_blob(&ref);
}
PREDICATE(my_file_close, 1)
{ auto ref = PlBlobV<MyFileBlob>::cast_ex(A1, my_file_blob);
if ( !ref->close() ) // TODO: get the error code
throw ref->MyFileBlobError("my_file_blob_close_error");
return true;
}
<cstdio>. The blob wraps the
file pointer returned from fopen() and also keeps a few other
values for debugging (the mode, flags, filename from the call to fopen())
plus a buffer for read operations.
[search,read]
would map to‘examPL_FILE_SEARCH|PL_FILE_READ‘.
MyFileBlob struct defines the blob that wraps a
FILE*. The constructor (which is called by predicate
my_file_open/4)
converts the flags term (a list of atoms or strings) to a
flag that is passed to PL_get_file_name(), to convert the filename
to a string containing the abslute file name. This is then passed to fopen(),
together with the
mode. If the call to fopen() fails, a C++ exception is
thrown, to be handled by Prolog. Other errors, such as a wrong argument
type to PL_get_file_name() can also cause an exception.
FILE*
to null, so that close won't be done twice.
MyBlob in section
1.6.8.5.
MyFileBlob constructor with Filename, Mode,
flags and unifies the blob with File.
Passing a Prolog blob around can be inconvenient; it is easier if a
blob can be identified an atom. An example of this is with streams,
which are identified by atoms such as user_input.
A utility class AtomMap is provided for this situation.
See section 1.17.4.
The C++ API remains a work in progress.
SWI-Prolog string handling has evolved over time. The functions that
create atoms or strings using char* or wchar_t*
are “old school” ; similarly with functions that get the
string as
char* or wchar_t*. The PL_get,unify,put_[nw]chars()
family is more friendly when it comes to different input, output,
encoding and exception handling.
Roughly, the modern API is PL_get_nchars(), PL_unify_chars()
and
PL_put_chars() on terms. There is only half of the API for atoms
as
PL_new_atom_mbchars() and PL_atom_mbchars(), which take an
encoding, length and char*.
For return values, char* is dangerous because it can
point to local or stack memory. For this reason, wherever possible, the
C++ API returns a std::string, which contains a copy of the
string. This can be slightly less efficient that returning a
char*, but it avoids some subtle and pervasive bugs that
even address sanitizers can't detect.23If
we wish to minimize the overhead of passing strings, this can be done by
passing in a pointer to a string rather than returning a string value;
but this is more cumbersome and modern compilers can often optimize the
code to avoid copying the return value.
Some functions require allocating string space using PL_STRINGS_MARK().
The PlStringBuffers class provides a RAII wrapper
that ensures the matching PL_STRINGS_RELEASE() is done. The PlAtom
or PlTerm member functions that need the string buffer use PlStringBuffers,
and then copy the resulting string to a std::string value.
The C++ API has functions such as PlTerm::get_nchars()
that use
PlStringBuffers and then copy the result to a
std::string result, so the programmer often doesn't need to
use PlStringBuffers.
BUF_STACK. This isn't needed if you use a method such as
PlTerm::as_string(), but
is needed for calling certain PL_*() or Plx_*() wrapped functions.
The constructor calls PL_STRINGS_MARK() and the destructor calls PL_STRINGS_RELEASE(). Here is an example of its use, for writing an atom to a stream, using Plx_atom_wchars(), which must be called within a strings buffer:
PREDICATE(w_atom_cpp, 2)
{ auto stream(A1), term(A2);
PlStream strm(stream, STIO_OUTPUT);
PlStringBuffers _string_buffers;
const pl_wchar_t *sa = Plx_atom_wchars(term.as_atom().unwrap(), nullptr);
strm.printfX("/%Ws/", sa);
return true;
}
PlStream can be used to get a stream from a Prolog term,
or to lock the stream so that other threads cannot interleave their
output. With either usage, PlStream is a RAII
class that ensure the matching PL_release_stream() is done, and
also handles some subtle problems with C++ exceptions.
The methods are:
PlStream
object to an invalid stream (see PlStream::check_stream()).IOSTREAM*, PlStream
is implicitly converted to IOSTREAM*.PlStream object contains a valid stream and throws an
exception if it doesn't. This is used to ensure that PlStream::release()
hasn't been called.
Most of the stream I/O functions have corresponding methods in PlStream.
For example, Sfprintf() corresponds to
PlStream::printf(). PlStream::seek() and PlStream::tell()
call
Sseek64() and Stell64() instead of long (they
are also deprecated: PlStream::seek64() and PlStream::tell64()
are preferred).
The C interface to stream I/O doesn't raise a Prolog error when
there's a stream error (typically indicated by a -1 return code).
Instead, the error sets a flag on the stream and
PL_release_stream() creates the error term. The
PlStream destructor calls PL_release_stream(); but
it's a fatal error in C++ to raise an exception in a destructor if the
destructor is invoked by stack-unwinding due to another exception,
including the pseudo-exceptions PlFail and
PlExceptionFail.
To get around this, the various stream I/O functions have wrapper
methods in the PlStream class that check for an error and
call PlStream::release()
to create the Prolog error, which is thrown as a C++ error.
The destructor calls PlStream::release(), which throws a C++ exception if there is a stream error. This is outside the destructor, so it is safe - the destructor checks if the stream has been released and does nothing in that situation.
The following two code examples do essentially the same thing:
PREDICATE(name_arity, 1)
{ PlStream strm(Scurrent_output);
strm.printf("name = %s, arity = %zd\n", A1.name().as_string().c_str(), A1.arity());
return true;
}
PREDICATE(name_arity, 1)
{ PlStream strm(Scurrent_output);
try
{ strm.printf("name = %s, arity = %zd\n", A1.name().as_string().c_str(), A1.arity());
} PREDICATE_CATCH({strm.release(); return false;})
return true;
}
If you write the code as follows, using Sfprintf() directly, it is possible that a fatal exception will be raised on an I/O error:
PREDICATE(name_arity, 1)
{ PlStream strm(Scurrent_output);
Sfprintf(strm, "name = %s, arity = %zd\n", A1.name().as_string().c_str(), A1.arity());
return true;
// WARNING: the PlStream destructor might throw a C++
// exception on stack unwinding, giving a fatal
// fatal runtime exception.
}
If you don't use these, and want to throw an exception if there's an
error, the following code works because PlStream (and the
underlying PL_acquire_stream()) can be called recursively:
{ PlStream strm(...);
strm.release();
}
Many of the “opaque object handles” , such as atom_t,
term_t, and functor_t are integers.24Typically uintptr_t
values, which the C standard defines as “an unsigned integer type
with the property that any valid pointer to void can be converted to
this type, then converted back to pointer to void, and the result will
compare equal to the original pointer.’ As such,
there is no compile-time detection of passing the wrong handle to a
function.
This leads to a problem with classes such as PlTerm -
C++ overloading cannot be used to distinguish, for example, creating a
term from an atom versus creating a term from an integer. There are a
number of possible solutions, including:
struct instead of an
integer.It is impractical to change the C code, both because of the amount of edits that would be required and also because of the possibility that the changes would inhibit some optimizations.
There isn't much difference between subclasses versus tags; but as a matter of design, it's better to specify things as constants than as (theoretically) variables, so the decision was to use subclasses.
The utility program swipl-ld (Win32: swipl-ld.exe) works with both C and C++ programs. See Linking embedded applications using swipl-ld for more details.
Your C++ compiler should support at least C++-17.
To avoid incompatibilities amongst the various C++ compilers’ABIs,
the object file from compiling SWI-cpp2.cpp is not included
in the shared object libswipl; instead, it must be compiled
along with any foreign predicate files. If the macro
_SWI_CPP2_CPP_SEPARATE is defined before the include for
SWI-cpp2.h, then SWI-cpp2.cpp is not
automatically included and must be compiled separately - either by
creating a
.a file or by adding a #include <SWI-cpp2.cpp>
to one of your source files.
Before going into a detailed description of the C++ classes we present a few examples illustrating the “feel” of the interface.
This simple example shows the basic definition of the predicate hello/1 and how a Prolog argument is converted to C-data:
PREDICATE(hello, 1)
{ cout << "Hello " << A1.as_string() << endl;
return true;
}
The arguments to PREDICATE()
are the name and arity of the predicate. The macros A<n>
provide access to the predicate arguments by position and are of the
type PlTerm. The C or C++ string for a PlTerm
can be extracted using as_string(),
or as_wstring() methods;25The
C-string values can be extracted from std::string by using c_str(),
but you must be careful to not return a pointer to a local/stack value,
so this isn't recommende. and similar access methods
provide an easy type-conversion for most Prolog data-types, using the
output of write/1
otherwise:
?- hello(world). Hello world Yes ?- hello(X) Hello _G170 X = _G170
This example shows arithmetic using the C++ interface, including unification, type-checking, and conversion. The predicate add/3 adds the two first arguments and unifies the last with the result.
PREDICATE(add, 3)
{ return A3.unify_integer(A1.as_long() + A2.as_long());
}
You can use your own variable names instead of A1,
A2, etc.:
PREDICATE(add, 3) // add(+X, +Y, +Result)
{ PlTerm x(A1);
PlTerm y(A2);
PlTerm result(A3);
return result.unify_integer(x.as_long() + y.as_long());
}
or more compactly:
PREDICATE(add, 3) // add(+X, +Y, +Result)
{ auto x = A1, y = A2, result = A3;
return result.unify_integer(x.as_long() + y.as_long());
}
The as_long() method for a PlTerm performs a PL_get_long_ex()
and throws a C++ exception if the Prolog argument is not a Prolog
integer or float that can be converted without loss to a
long. The unify_integer() method of PlTerm
is defined to perform unification and returns true or false
depending on the result.
?- add(1, 2, X). X = 3. ?- add(a, 2, X). [ERROR: Type error: `integer' expected, found `a'] Exception: ( 7) add(a, 2, _G197) ?
This example is a bit harder. The predicate average/3 is defined to take the template average(+Var, :Goal, -Average) , where Goal binds Var and will unify Average with average of the (integer) results.
PlQuery takes the name of a predicate and the
goal-argument vector as arguments. From this information it deduces the
arity and locates the predicate. The method PlQuery::next_solution()
yields
true if there was a solution and false
otherwise. If the goal yields a Prolog exception, it is mapped into a
C++ exception. A return to Prolog does an implicit “cut” (PL_cut_query());
this can also be done explicitly by the PlQuery::cut()
method.
PREDICATE(average, 3) /* average(+Templ, :Goal, -Average) */
{ long sum = 0;
long n = 0;
PlQuery q("call", PlTermv(A2));
while( q.next_solution() )
{ sum += A1.as_long();
n++;
}
return A3.unify_float(double(sum) / double(n));
}
?- [user]. |: p(1). |: p(10). |: p(20). |: % user://1 compiled 0.00 sec, 3 clauses true. ?- average(X, p(X), Average). Average = 10.333333333333334.
The original version of the C++ interface heavily used implicit constructors and conversion operators. This allowed, for example:
PREDICATE(hello, 1)
{ cout << "Hello " << (char *)A1 << endl; // Deprecated
return true;
}
PREDICATE(add, 3)
{ return A3 = (long)A1 + (long)A2; // Deprecated
}
Version 2 is a bit more verbose:
PREDICATE(hello, 1)
{ cout << "Hello " << A1.as_string() << endl;
return true;
}
PREDICATE(add, 3)
{ return A3.unify_int(A1.as_long() + A2.as_long());
}
There are a few reasons for this:
bool. In addition, the result
of unification should always be checked (e.g., an “always succeed” unification
could fail due to an out-of-memory error); the unify_XXX()
methods return a bool and they can be wrapped inside a PlCheckFail()
to raise an exception on unification failure.(char*)A1 becomes the more verbose
static_cast<std::string>(A1), which is longer than
A1.as_string().
Also, the string casts don't allow for specifying encoding.PlTerm t; Pl_put_atom_chars(t, "someName");
whereas this is now required:
PlTerm t; Pl_put_atom_chars(t.as_term_t(), "someName");
However, this is mostly avoided by methods and constructors that wrap the foreign language functions:
PlTerm_atom t("someName");
or
auto t = PlTerm_atom("someName");
Additionally, there are now wrappers for most of the PL_*() functions that check the error return and throw a C++ exception as appropriate.
Over time, it is expected that some of these restrictions will be eased, to allow a more compact coding style that was the intent of the original API. However, too much use of overloaded methods/constructors, implicit conversions and constructors can result in code that's difficult to understand, so a balance needs to be struck between compactness of code and understandability.
For backwards compatibility, much of the version 1 interface is still available (except for the implicit constructors and operators), but marked as “deprecated” ; code that depends on the parts that have been removed can be easily changed to use the new interface.
The version API often used char* for both setting and
setting string values. This is not a problem for setting (although
encodings can be an issue), but can introduce subtle bugs in the
lifetimes of pointers if the buffer stack isn't used properly. PlStringBuffers
makes the buffer stack easier to use, but it would be preferable to
avoid its use altogether. C++, unlike C, has a standard string that
allows easily keeping a copy rather than dealing with a pointer that
might become invalid. (Also, C++ strings can contain null characters.)
C++ has default conversion operators from char* to
std::string, so some of the API support only
std::string, even though this can cause a small
inefficiency. If this proves to be a problem, additional overloaded
functions and methods can be provided in future (note that some
compilers have optimizations that reduce the overheads of using
std::string); but for performance-critical code, the C
functions can still be used.
There still remains the problems of Unicode and encodings.
std::wstring is one way of dealing with this. And for
interfaces that use std::string, an encoding can be
specified.26As of 2023-04, this
had only been partially implemented. Some of the details
for this - such as the default encoding - may change slightly in the
future.
The easiest way of porting from SWI-cpp.h to SWI-cpp2.h
is to change the #include "SWI-cpp.h" to #include
"SWI-cpp2.h" and look at the warning and error messages. Where
possible, version 2 keeps old interfaces with a “deprecated” flag
if there is a better way of doing things with version 2.
For convenience when calling PL_*() functions, the Plx_*() wrapper
functions add error checking. Also, most of the PL_*() functions that
work with term_t, atom_t, etc. have
corresponding methods in PlTerm, PlAtom, etc.
Here is a list of typical changes:
term_t, PlTerm_integer(i),
PlTerm_float(v), or PlTerm_pointer(p).
char* or wchar_t and
replace them by
std::string or std::wstring if appropriate.
For example, cout << "Hello " << (char*)A1 <<
endl can be replaced by cout << "Hello " << A1.as_string()
<< endl. In general, std::string is safer than char*
because the latter can potentially point to freed memory.
false from a predicate for
failure, you can do throw PlFail(). This mechanism
is also used by
PlCheckFail(rc). Note that
throwing an exception is slower than returning false, so
performance-critical code should avoid PlCheckFail(rc)
if failure is expected to happen often.
SWI-Prolog and throw a PlFail
exception to short-circuit execution and return failure (false)
to Prolog (or throw a PlException if there was a Prolog
error.
PlAtom::handle has been replaced by PlAtom::C_,
which should be accessed by PlAtom::unwrap().
PlTerm::ref has been replaced by PlTerm::C_,
which should be accessed by PlTerm::unwrap().
PlFunctor::functor has been replaced by PlFunctor::C_,
which should be accessed by PlFunctor::unwrap().
=
static_cast<char*>(t) is replaced by t.as_string().c_str()
(and you should prefer t.as_striong();
static_cast<int32_t>(t) is replaced by t.as_int32_t(),
etc.
int or
long because of problems porting between Unix and Windows
platforms; instead, use int32_t, int64_t,
uint32_t, uint64_t, etc.
The PlFail class is used for short-circuiting a function
when failure or an exception occurs and any errors will be handled in
the code generated by the PREDICATE()
macro. See also
section 1.17.2).
For example, this code, using the C API:
PREDICATE(unify_zero, 1)
{ if ( !PL_unify_integer(A1.unwrap(), 0) )
return false; // could be an error or failure
Sprintf("It's zero!\n");
return true;
}
can instead be written this way, using the C++ API:
PREDICATE(unify_zero, 1)
{ PlCheckFail(A1.unify_integer(0));
Sprintf("It's zero!\n");
return true;
}
Using throw PlFail() in performance-critical code
can cause a signficant slowdown. A simple benchmark showed a 15x to 20x
slowdown using throw PlFail() compared to return
false (comparing the first code sample above with the second and
third samples; the speed difference seems to have been because in the
second sample, the compiler did a better job of inlining). However, for
most code, this difference will be barely noticeable. And if the code
usually succeeds, there is no significant difference.
There was no significant performance difference between the C++ version and this C version:
static foreign_t
unify_zero(term_t a1)
{ return PL_unify_integer(a1, 0);
}
If one of the C PL_*() functions in SWI-Prolog.h returns
failure, this can be either a Prolog-style failure (e.g. from
PL_unify() or PL_next_solution()) or an error. If the
failure is due to an error, it's usually best to immediately return to
Prolog - and this can be done with the PlEx()
function, which turns a Prolog error into a C++ PlException. PlCheckFail()
calls PlEx() and additionally throws PlFail()
if the failure is for Prolog failure.
PlEx() calls PL_exception()
to see if there is a Prolog exception; if so, the Prolog exception is
converted to a
PlException object, which is then thrown. For more details
on the C++ exceptions, see section 1.15.
false, throw PlFail to
return control to Prolog with failure.PlException if there was one; otherwise, return the rc.PlFail
to return control to Prolog with failure. This is the same as PlCheckFail()
except it can also specify a
qid_t query ID.
The SWI-Prolog.h header provides various functions for
accessing, setting, and unifying terms, atoms and other types.
Typically, these functions return a 0 (false)
or
1 (true) value for whether they succeeded or
not. For failure, there might also be an exception created - this can be
tested by calling PL_excpetion(0).
There are three major groups of methods:
The “put” operations are typically done on an uninstantiated term (see the PlTerm_var() constructor). These are expected to succeed, and typically raise an exception failure (e.g., resource exception) - for details, see the corresponding PL_put_*() functions in Constructing Terms.
For the “get” and “unify” operations, there are three possible failures:
false return code
Each of these is communicated to Prolog by returning false
from the top level; exceptions also set a “global” exception
term (using PL_raise_exception()). The C++ programmer usually
doesn't have to worry about this; instead they can throw PlFail()
for failure or throw PlException() (or one of PlException’s
subclasses) and the C++ API will take care of everything.
These are deprecated and replaced by the various as_*()
methods.
PlTerm can be converted to the following types:
long if the PlTerm is a Prolog
integer or float that can be converted without loss to a long. Throws a
type_error exception otherwise.long, but might represent fewer bits.PlTerm represents a
Prolog integer or float.CVT_ALL|CVT_WRITE|BUF_RING, which implies Prolog atoms and
strings are converted to the represented text. All other data is handed
to write/1. If
the text is static in Prolog, a direct pointer to the string is
returned. Otherwise the text is saved in a ring of 16 buffers and must
be copied to avoid overwriting.
In addition, the Prolog type (PL_VARIABLE,
PL_ATOM, ... PL_DICT) can be determined using
the type() method. There are also boolean methods that check the
type:
See also section 1.13.1.
*blob==nullptr.
A family of unification methods are defined for the various Prolog
types and C++ types. Wherever string is shown, you can use:
char*whar_t*std::stringstd::wstring
Here is an example:
PREDICATE(hostname, 1)
{ char buf[256];
if ( gethostname(buf, sizeof buf) == 0 )
return A1.unify_atom(buf);
return false;
}
An alternative way of writing this would use the PlCheckFail() to raise an exception if the unification fails.
PREDICATE(hostname2, 1)
{ char buf[256];
PlCheckFail(gethostname(buf, sizeof buf) == 0);
PlCheckFail(A1.unify_atom(buf));
return true;
}
Of course, in a real program, the failure of
gethostname(buf)sizeof buf should create an error term than
contains information from errno.
PlTerm to a long and perform standard
C-comparison between the two long integers. If PlTerm
cannot be converted a type_error is raised.true if the PlTerm is an atom or string
representing the same text as the argument, false if the
conversion was successful, but the strings are not equal and an
type_error exception if the conversion failed.Below are some typical examples. See section 1.11.12.2 for direct manipulation of atoms in their internal representation.
A1 < 0 | Test A1 to hold a Prolog integer or float that can be transformed lossless to an integer less than zero. |
A1 < PlTerm(0) | A1
is before the term‘0’in the‘standard order of terms’.
This means that if A1 represents an atom, this test yields true. |
A1 == PlCompound("a(1)") | Test A1
to represent the term
a(1). |
A1 == "now" | Test A1 to be an atom or string holding the text “now” . |
Compound terms can be viewed as an array of terms with a name and
arity (length). This view is expressed by overloading the []
A type_error is raised if the argument is not compound
and a
domain_error if the index is out of range.
In addition, the following functions are defined:
PlTerm is a compound term and arg is
between 1 and the arity of the term, return a new PlTerm
representing the arg-th argument of the term. If PlTerm is
not compound, a
type_error is raised. Id arg is out of range, a
domain_error is raised. Please note the counting from 1
which is consistent to Prolog's arg/3
predicate, but inconsistent to C's normal view on an array. See also
class PlCompound. The following example tests x
to represent a term with first-argument an atom or string equal to gnat.
...,
if ( x[1] == "gnat" )
...
const char * holding the name of the functor of
the compound term. Raises a type_error if the argument is
not compound.type_error
if the argument is not compound.
t.is_null() is the
same as t.unwrap() == PlTerm::nullt.not_null() is the
same as t.unwrap() != PlTerm::nullt.reset() is the same
as t.unwrap() = PlTerm::nullt.reset(x) is the same as t.unwrap() = xPL_VARIABLE, PL_FLOAT, PL_INTEGER,
PL_ATOM, PL_STRING or PL_TERM
To avoid very confusing combinations of constructors and therefore
possible undesirable effects a number of subclasses of PlTerm
have been defined that provide constructors for creating special Prolog
terms. These subclasses are defined below.
A SWI-Prolog string represents a byte-string on the global stack. Its
lifetime is the same as for compound terms and other data living on the
global stack. Strings are not only a compound representation of text
that is garbage-collected, but as they can contain 0-bytes, they can be
used to contain arbitrary C-data structures. However, it is generally
preferred to use blobs for storing arbitrary C-data structures (see also PlTerm_pointer(void
*ptr)).
Character lists are compliant to Prolog's atom_chars/2 predicate.
The PlCompound class is a convenience class for creating
a term from a string; it is similar to (=..)/2
syntax_error exception is raised. Otherwise a new
term-reference holding the parsed text is created.PlTermv for details. The example below
creates the Prolog term hello(world).
PlCompound("hello", PlTermv(PlAtom("world")))
The class PlTerm_tail27This
was named PlTail in version 1 of the API. is
both for analysing and constructing lists. It is called PlTerm_tail
as enumeration-steps make the term-reference follow the “tail” of
the list.
PlTerm_tail is created by making a new term-reference
pointing to the same object. As PlTerm_tail is used to
enumerate or build a Prolog list, the initial list
term-reference keeps pointing to the head of the list.PlTerm_tail
reference point to the new variable tail. If A is a variable,
and this function is called on it using the argument "gnat",
a list of the form [gnat|B] is created and the PlTerm_tail
object now points to the new variable B.
This function returns true if the unification succeeded
and
false otherwise. No exceptions are generated.
The example below translates the main() argument vector to Prolog and calls the prolog predicate entry/1 with it.
int
main(int argc, char *argv[])
{ PlEngine e(argv[0]);
PlTermv av(1);
PlTerm_tail l(av[0]);
for(int i=0; i<argc; i++)
PlCheckFail(l.append(PlTerm_string(argv[i])));
PlCheckFail(l.close());
PlQuery q("writeln", av);
try
{ return q.next_solution() ? 0 : 1;
} catch ( PlException &ex )
{ std::cerr << ex.what() << std::endl;
return 1;
}
}
[]PlTerm_tail
and advance
PlTerm_tail. Returns true on success and false
if
PlTerm_tail represents the empty list. If PlTerm_tail
is neither a list nor the empty list, a type_error is
thrown. The example below prints the elements of a list.
PREDICATE(write_list, 1)
{ PlTerm_tail tail(A1);
PlTerm_var e;
while(tail.next(e))
cout << e.as_string() << endl;
return tail.close();
}
The class PlTermv represents an array of
term-references. This type is used to pass the arguments to a foreign
defined predicate, construct compound terms (see
PlTerm::PlTerm(const char *name)PlTermv arguments ), and to
create queries (see PlQuery).
The only useful member function is the overloading of []domain_error exception.
The constructors for this class are below. Note that these can be
error-prone because there's no distinction between term_t
and
size_t; the form of the constructor is determined by
whether the first argument is an integer (term_t or size_t)
or
PlTerm.
load_file(const char *file)
{ return PlCall("compile", PlTermv(PlAtom(file)));
}
If the vector has to contain more than 5 elements, the following construction should be used:
{ PlTermv av(10);
av[0].put_term(PlTerm_atom("hello"));
av[1].put_term(PlTerm_integer(666));
...
}
Important: be sure that all the arguments are of type
PlTerm - PlTermv(i) is not the same as
PlTermv(PlTerm_integer(i)), and will result in a
runtime error.
Both for quick comparison as for quick building of lists of atoms, it is desirable to provide access to Prolog's atom-table, mapping handles to unique string-constants. If the handles of two atoms are different it is guaranteed they represent different text strings.
Suppose we want to test whether a term represents a certain atom, this interface presents a large number of alternatives:
Example:
PREDICATE(test, 1)
{ if ( A1 == "read" )
...;
}
This writes easily and is the preferred method is performance is not critical and only a few comparisons have to be made. It validates A1 to be a term-reference representing text (atom, string, integer or float) extracts the represented text and uses strcmp() to match the strings.
Example:
static PlAtom ATOM_read("read");
PREDICATE(test, 1)
{ if ( A1 == ATOM_read )
...;
}
This case raises a type_error if A1 is not an
atom. Otherwise it extacts the atom-handle and compares it to the
atom-handle of the global PlAtom object. This approach is
faster and provides more strict type-checking.
Example:
static PlAtom ATOM_read("read");
PREDICATE(test, 1)
{ PlAtom a1(A1);
if ( a1 == ATOM_read )
...;
}
This approach is basically the same as section 1.11.12.2, but in nested if-then-else the extraction of the atom from the term is done only once.
Example:
PREDICATE(test, 1)
{ PlAtom a1(A1);
if ( a1 == "read" )
...;
}
This approach extracts the atom once and for each test extracts the represented string from the atom and compares it. It avoids the need for global atom constructors.
atom_t). Used
internally and for integration with the C-interface.type_error is thrown.true if the atom represents text, false
otherwise. Performs a strcmp() or similar for this.true or
false. Because atoms are unique, there is no need to use strcmp()
for this.==true.char* from a function, you should not
do return t.as_string().c_str()
because that will return a pointer into the stack (Gnu C++ or Clang
options -Wreturn-stack-address or -Wreturn-local-addr)
can sometimes catch this, as can the runtime address sanitizer
when run with detect_stack_use_after_return=1.
This does not quote or escape any characters that would need to be
escaped if the atom were to be input to the Prolog parser. The possible
values for enc are:
EncLatin1 - throws an exception if cannot be
represented in ASCII.EncUTF8EncLocale - uses the locale to determine the
representation.
The recorded database is has two wrappers, for supporting the internal records and external records.
Currently, the interface to internal records requires that
the programmer explicitly call the dupicate() and erase()
methods - in future, it is intended that this will be done automatically
by a new
PlRecord class, so that the internal records behave like “smart
pointers” ; in the meantime, the PlRecord provides a
trivial wrapper around the various recorded database functions.
The class PlRecord supports the following methods:
PlRecord object.
The class PlRecord provides direct access to the
reference counting aspects of the recorded term (through the duplicate()
and
erase() methods), but does not
connect these with C++'s copy constructor, assignment operator, or
destructor. If the recorded term is encapsulated within an object, then
the containing object can use the duplicate()
and erase() methods in its copy and
move constructors and assignment operators (and the erase()
method in the destructor).29The
copy constructor and assignment use the duplicate()
method; the move constructor and assignment use the duplicate()
method to assign to the destination and the erase()
method on the source; and the destructor uses erase().
Alternatively, the std::shared_ptr or std::unique_ptr
can be used with the supplied PlrecordDeleter, which calls
the
erase() method when the shared_ptr
reference count goes to zero or when the std::unique_ptr
goes out of scope.
For example:
std::shared_ptr<PlRecord> r(new PlRecord(t.record()), PlRecordDeleter()); assert(t.unify_term(r->term()));
The class PlRecordExternalCopy keeps the external
record as an uninterpreted string (which may contain nulls). It
supports the following methods.
This class encapsulates PL_register_foreign(). It is defined as a class rather then a function to exploit the C++ global constructor feature. This class provides a constructor to deal with the PREDICATE() way of defining foreign predicates as well as constructors to deal with more conventional foreign predicate definitions.
PL_FA_VARARGS calling convention, where the argument
list of the predicate is passed using an array of term_t
objects as returned by PL_new_term_refs(). This interface poses
no limits on the arity of the predicate and is faster, especially for a
large number of arguments.
static foreign_t
pl_hello(PlTerm a1)
{ ...
}
PlRegister x_hello_1(NULL, "hello", 1, pl_hello);
This construct is currently supported upto 3 arguments.
This class encapsulates the call-backs onto Prolog.
user.true if
successful and false if there are no (more) solutions.
Prolog exceptions are mapped to C++ exceptions. If the PlQuery
object was created with the PL_Q_EXT_STATUS flag, the
extended return codes can also be returned (TRUE,
FALSE,
PL_S_NOT_INNER,
PL_S_EXCEPTION,
PL_S_FALSE,
PL_S_TRUE,
PL_S_LAST). Because of this, you shouldn't use PlCheckFail()
with PlQuery::next_solution()
in this situation.PlQuery’s destructor.
Below is an example listing the currently defined Prolog modules to the terminal.
PREDICATE(list_modules, 0)
{ PlTermv av(1);
PlQuery q("current_module", av);
while( q.next_solution() )
cout << av[0].as_string() << endl;
return true;
}
In addition to the above, the following functions have been defined.
PlQuery from the arguments generates the first next_solution()
and destroys the query. Returns the result of next_solution() or
an exception.true or false
for the success/failure of the call; and throws an exception if there's
an error.
t.call() is essentially
the same as PlCall(t).
As documented with PL_unify(), if a unification call fails and
control isn't made immediately to Prolog, any changes made by
unification must be undone. The functions PL_open_foreign_frame(),
PL_rewind_foreign_frame(), PL_discard_foreign_frame(), and
PL_close_foreign_frame() are encapsulated in the class
PlFrame, whose destructor calls
PL_close_foreign_frame(). Using this, the example code with PL_unify()
can be written:
PREDICATE(can_unify_ffi, 2)
{ fid_t fid = PL_open_foreign_frame();
int rval = PL_unify(A1.unwrap(), A2.unwrap());
PL_discard_foreign_frame(fid);
return rval;
}
/* equivalent to the Prolog code
T1 = T2 -> do_one_thing ; do_another_thing */
{ PlFrame fr;
bool t1_t2_unified = A1.unify_term(A2);
if ( ! t1_t2_unified )
fr.rewind();
if ( t1_t2_unified )
do_one_thing(...);
else
do_another_thing(...);
}
The following is C++ version of the code example for PL_open_foreign_frame(). The calls to PL_close_foreign_frame() and the check for PL_exception(0) in the C code aren't needed in the C++ code:
static std::vector<std::string> lookup_unifies =
{ "item(one, 1)", "item(two, 2)", "item(three, 3)" };
PREDICATE(lookup_unify, 1)
{ PlFrame fr;
for (auto& s : lookup_unifies )
{ PlCompound t(s);
if ( A1.unify_term(t) )
return true;
fr.rewind();
}
return false;
}
or using this convenience wrapper:
if ( RewindOnFail([t1=A1,t2=A2]()->bool
{ return t1.unify_term(t2); }) )
do_one_thing(...);
else
do_another_thing(...);
Note that PlTerm::unify_term()
checks for an error and throws an exception to Prolog; if you wish to
handle exceptions, you must call PL_unify_term(t1. unwrap(),t2.
unwrap()).
The class PlFrame provides an interface to discard
unused term-references as well as rewinding unifications (data-backtracking).
Reclaiming unused term-references is automatically performed after a
call to a C++-defined predicate has finished and returns control to
Prolog. In this scenario PlFrame is rarely of any use. This
class comes into play if the toplevel program is defined in C++ and
calls Prolog multiple times. Setting up arguments to a query requires
term-references and using PlFrame is the only way to
reclaim them.
Another use of of PlFrame is when multiple separate
unifications are done - if any of them fails, then the earlier
unifications must be undone before returning to Prolog.
PlFrame.
A typical use for PlFrame is
the definition of C++ functions that call Prolog and may be called
repeatedly from C++. Consider the definition of assertWord(),
adding a fact to word/1;
the PlFrame removes the new term av[0] from
the stack, which prevents the stack from growing each time assertWord()
is called:
void
assertWord(const char *word)
{ PlFrame fr;
PlTermv av(1);
av[0] = PlCompound("word", PlTermv(word));
PlQuery q("assert", av);
PlCheckFail(q.next_solution());
}
The following example uses PlFrame in the context of a
foreign predicate. The can_unify/2’s
truth-value is the same as for Prolog unification (=/2), but has no side
effects. In Prolog one would use double negation to achieve this:
PREDICATE(can_unify, 2)
{ PlFrame fr;
int rval = (A1=A2);
fr.discard(); // or, less efficiently: fr.rewindd();
return rval;
}
Here is an example of using PlRewindOnFail(),
where name_to_terms contains a map from names to terms
(which are made global by using the PL_record() function). The
frame rewind is needed in the situation where the first unify_term()
succeeds and the second one fails.
static const std::map<const std::string, PlRecord> name_to_term =
{ {"a", PlTerm(...).record(), PlTerm(...).record()},
... };
PREDICATE(name_to_terms, 3)
{ A1.must_be_atom_or_string();
const auto it = name_to_term.find(A1.as_string());
return it != name_to_term.cend() &&
PlRewindOnFail([t1=A2,t2=A3,&it]()
{ return t1.unify_term(it->second.first.term()) &&
t2.unify_term(it->second.second.term()); });
}
The equivalent code without using PlRewindOnFail() is:
PREDICATE(name_to_terms, 3)
{ PlTerm key(A1), term1(A2), term2(A3);
const auto it = name_to_term.find(key.as_string());
if ( it == name_to_term.cend() )
return false;
if ( !term1.unify_term(it->second.first.term()) )
return false;
PlFrame fr;
if ( !term2.unify_term(it->second.second.term()) )
{ fr.discard();
return false;
}
return true;
}
The PREDICATE macro is there to make your code look nice, taking care of the interface to the C-defined SWI-Prolog kernel as well as mapping exceptions. Using the macro
PREDICATE(hello, 1)
is the same as writing:30There
are a few more details, such as catching std::bad_alloc.:
static foreign_t pl_hello__1(PlTermv PL_av);
static foreign_t
_pl_hello__1(term_t t0, int arity, control_t ctx)
{ (void)arity; (void)ctx;
try
{ return pl_hello__1(PlTermv(1, t0));
} catch( PlFail& )
{ return false;
} catch ( PlException& ex )
{ return ex.plThrow();
}
}
static PlRegister _x_hello__1("hello", 1, _pl_hello__1);
static foreign_t
pl_hello__1(PlTermv PL_av)
The first function converts the parameters passed from the Prolog
kernel to a PlTermv instance and maps exceptions raised in
the body to simple failure or Prolog exceptions. The PlRegister
global constructor registers the predicate. Finally, the function header
for the implementation is created.
The PREDICATE() macros have a number of variations that deal with special cases.
A1, A2,
etc.PL_av is not used.
NAMED_PREDICATE("#", hash, 2)
{ return A2.unify_string(A1.as_string());
}
Non-deterministic predicates are defined using PREDICATE_NONDET(plname, cname, arity) or NAMED_PREDICATE_NONDET(plname, cname, arity).
A non-deterministic predicate returns a “context” , which
is passed to a subsequent retry. Typically, this context is allocated on
the first call to the predicate and freed when the predicate either
fails or does its last successful return (the context is nullptr
on the first call). To simplify this, a template helper function
PlControl::context_unique_ptr<ContextType>() provides a “smart
pointer” that frees the context on normal return or an exception;
when used with PL_retry_address(), the context's std:unique_ptr<ContextType>::release()
is used to pass the context to Prolog for the next retry, and to prevent
the context from being freed. If the predicate is called with PL_PRUNE,
the normal return true will implicitly free the context.
The skeleton for a typical non-deterministic predicate is as follows.
The test for PL_PRUNED is done first to avoid an unneeded
PlFrame and also to ensure that A1, A2,
etc. aren't used when they have the value
PlTerm::null.31This
code could be structured as a switch statement, but
typically the PL_FIRST_CALL case falls through to the PL_REDO
case. There are a number of examples of non-deterministic
predicates in the test code test_cpp.cpp.
struct PredContext { ... }; // The "context" for retries
PREDICATE_NONDET(pred, <arity>)
{ // "ctxt" must be acquired so that the destructor deletes it
auto ctxt = handle.context_unique_ptr<PredContext>();
const auto control = handle.foreign_control();
if ( control == PL_PRUNED )
return true;
// Can use A1, A2, etc. after we know control != PL_PRUNED
if ( ... ) // deterministic result
{ assert(control == PL_FIRST_CALL);
if ( ... )
return true; // Success (and no more solutions)
else
return fase;
}
if ( control = PL_FIRST_CALL )
{ ctxt.reset(new PredContext(...));
...
} else
{ assert(control == PL_REDO);
}
PlFrame fr;
for ( ; ctxt->valid(...) ; ctxt->next() )
{ if ( ... unify a result ... )
{ ctxt->next();
if ( ctxt->valid(...) )
PL_retry_addresss(ctxt.release()); // Succeed with a choice point
else
return true; // deterministic success
}
fr.rewind();
}
return false;
}
With no special precautions, the predicates are defined into the
module from which load_foreign_library/1
was called, or in the module
user if there is no Prolog context from which to deduce the
module such as while linking the extension statically with the Prolog
kernel.
Alternatively, before loading the SWI-Prolog include file, the macro PROLOG_MODULE may be defined to a string containing the name of the destination module. A module name may only contain alpha-numerical characters (letters, digits, _). See the example below:
#define PROLOG_MODULE "math"
#include <SWI-Prolog.h>
#include <math.h>
PREDICATE(pi, 1)
{ A1 = M_PI;
}
?- math:pi(X). X = 3.14159
See also Prolog exceptions in foreign code.
Prolog exceptions are mapped to C++ exceptions using the class
PlException (a subclass of PlExceptionBase to
represent the Prolog exception term. All type-conversion functions of
the interface raise Prolog-compliant exceptions, providing decent
error-handling support at no extra work for the programmer.
For some commonly used exceptions, convenience functions have been
created to exploit both their constructors for easy creation of these
exceptions. If you wish to trap these, you should use
PlException or PlExceptionBase and then look
for the appropriate error name. For example, the following code catches
"type_error" and passes all other exceptions:
try
{ do_something(...);
} catch (const PlException& e)
{ PlTerm e_t = e.term();
PlAtom ATOM_type_error("type_error");
// e_t.name() == PlAtom("error") && e_t.arity() == 2
if ( e_t[1].name() == ATOM_type_error) )
{ ... // expected type and culprit are \exam{e_t[1][1]} and \exam{e_t[1][2]}
} else throw;
}
The convenience functions are PlTypeEror() and PlDomainError(),
PlDomainError(), PlInstantiationError(), PlExistenceError(),
PlUninstantiationError(), PlRepresentationError(),
PlPermissionError(), PlResourceError(), PlUnknownError().
There is also a PlGeneralError(inside) that creates error(inside,_)
terms and is used by the other error convience functions.
To throw an exception, create an instance of PlException
and use throw. This is intercepted by the PREDICATE macro
and turned into a Prolog exception. See section
1.17.2.
char *data = "users";
throw PlException(PlCompound("no_database", PlTerm(data)));
This subclass of PlExceptionBase is used to represent
exceptions.
PlException, there are convenience functions that create
and wrap a Prolog term, similar to the PL_domain_error(), etc.
The hierarchy allows catch statements to easily handle
combinations.
A PlException object contains a Prolog term, so its
what() method must be called either
within a Prolog predicate or within the context of a PlEngine
(and PlFrame; see section
1.16). The term is copied so that it is available outside of the
context of the frame that created it.
std::exception
*-- PlExceptionBase
*-- PlException
| *.. PlDomainError()
| *.. PlExistenceError()
| *.. PlGeneralError()
| *.. PlInstantiationError()
| *.. PlPermissionError()
| *.. PlRepresentationError()
| *.. PlResourceError()
| *.. PlTypeError()
| *.. PlUninstantiationError()
| *.. PlUnknownError()
*-- PlExceptionFailBase
| *-- PlExceptionFail
| *-- PlFail
*-- PlEngineInitialisationFailed
*-- PlOpenForeignFrameFailed
Note that everything under PlException can contain a
Prolog term; if the what() method is
called, it must be within the context of a Prolog frame. If you wish to
pass the exception outside the frame, you can use the set_what_str()
method to avoid evaluating the term after it has been freed by Prolog:
try
{ PlCall("p(123)");
...
} catch ( PlException &ex )
{ ex.set_what_str();
throw; // rethrow the exception
}
Currently defined methods are:
...;
try
{ PlCall("consult(load)");
} catch ( const PlException& ex )
{ cerr << ex.as_string() << endl;
}
A type error expresses that a term does not satisfy the expected basic Prolog type.
A domain error expresses that a term satisfies the basic
Prolog type expected, but is unacceptable to the restricted domain
expected by some operation. For example, the standard Prolog open/3
call expect an io_mode (read, write, append, ...). If an
integer is provided, this is a type error, if an atom other
than one of the defined io-modes is provided it is a domain error.
Most of the above assumes Prolog is‘in charge’of the
application and C++ is used to add functionality to Prolog, either for
accessing external resources or for performance reasons. In some
applications, there is a main-program and we want to use Prolog
as a
logic server. For these applications, the class
PlEngine has been defined.
Only a single instance of this class can exist in a process. When used in a multi-threading application, only one thread at a time may have a running query on this engine. Applications should ensure this using proper locking techniques.32For Unix, there is a multi-threaded version of SWI-Prolog. In this version each thread can create and destroy a thread-engine. There is currently no C++ interface defined to access this functionality, though ---of course--- you can use the C-functions.
argv[0]
from its main function, which is needed in the Unix version to find the
running executable. See PL_initialise() for details. If
initialisation fails, PL_halt(1) is called.argv[0].Section 1.11.10 has a simple example using this class.
Not all functionality of the C-interface is provided, but as
PlTerm and term_t are essentially the same
thing with type-conversion between the two (using the unwrap()
method), this interface can be freely mixed with the functions defined
for plain C. For checking return codes from C functions, it is
recommended to use PlCheckFail()
or PlCheck_PL().
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.
Global terms and atoms need to be handled slightly differently in C++ than in C - see section 1.17.3
Exceptions are normal Prolog terms that are handled specially by the
PREDICATE macro when they are used by a C++ throw, and
converted into Prolog exceptions. The exception term may not be unbound;
that is, throw(_) must raise an error. The C++ code and underlying C
code do not explicitly check for the term being a variable, and
behaviour of raising an exception that is an unbound term is undefined,
including the possibility of causing a crash or corrupting data.
The Prolog exception term error(Formal, _) is special. If the 2nd
argument of error/2
is undefined, and the term is thrown, the system finds the catcher (if
any), and calls the hooks in library(prolog_stack) to add the context
and stack trace information when appropriate. That is, throw PlDomainError(Domain,Culprit)
ends up doing the same thing as calling
PL_domain_error(Domain,Culprit) which internally
calls
PL_raise_exception() and returns control back to Prolog.
The VM handling of calling to C finds the FALSE return
code, checks for the pending exception and propagates the exception into
the Prolog environment. As the term references (term_t)
used to create the exception are lost while returning from the foreign
function we need some way to protect them. That is done using a global term_t
handle that is allocated at the epoch of Prolog.
PL_raise_exception() sets this to the term using PL_put_term().
PL_exception(0) returns the global exception term_t
if it is bound and 0 otherwise.
Special care needs to be taken with data backtracking using
PL_discard_foreign_frame() or PL_close_query() because
that will invalidate the exception term. So, between raising the
exception and returning control back to Prolog we must make sure not to
do anything that invalidates the exception term. If you suspect
something like that to happen, use the debugger with a breakpoint on
__do_undo__LD() defined in pl-wam.c.
In order to always preserve Prolog exceptions and return as quickly as possible to Prolog on an exception, some of the C++ classes can throw an exception in their destructor. This is theoretically a dangerous thing to do, and can lead to a crash or program termination if the destructor is invoked as part of handling another exception.
Sometimes it is convenient to put constant terms and atoms as global
variables in a file (with a static qualifier), so that they
are only created (and looked up) cone. This is fine for atoms and
functors, which can be created by something like this:
static PlAtom ATOM_foo("foo");
static PlFunctor FUNCTOR_ff_2("ff", 2);
C++ makes no guarantees about the order of creating global variables
across “translation units” (that is, individual C++ files),
but the Prolog runtime ensures that the necessary initialization has
been done to allow PlAtom and PlFunctor
objects to be created. However, to be safe, it is best to put such
global variables
inside functions - C++ will initialize them on their firstuse.
Global Terms need a bit of care. For one thing, terms are ephemeral,
so it is wrong to have a PlTerm static variable - instead,
a
PlRecord must be used, which will provide a fresh copy of
the term using PlRecord::term(). There is no guarantee that the
Prolog runtime has initialized everything needed for creating entries in
the recorded database (see
Recorded
database). Therefore, global recorded terms must be wrapped inside a
function. C++ will call the constructor upon first use. For example:
static PlTerm
term_foo_bar()
{ static PlRecord r(PlCompound("foo", PlTermv(PlTerm_atom("bar"))).record());
return r.term();
}
The include file SWI-cpp2-atommap.h contains a templated
class
AtomMap for mapping atoms to atoms or terms. The typical
use case is for when it is desired to open a database or stream and,
instead of passing around the blob, an atom can be used to identify the
blob.
The keys in the map must be standard Prolog atoms and not blobs - the code depends on the fact that an atom has a unique ID.
The AtomMap is thread-safe (it contains a mutex). It
also takes care of reference counts for both the key and the value. Here
is a typical use case:
static AtomMap<PlAtom, PlAtom> map_atom_my_blob("alias", "my_blob");
// look up an entry:
auto value = map_atom_my_blob(A1.as_atom());
PlCheckFail(value.not_null());
// insert an entry:
map_atom_my_blob.insert(A1.as_atom(), A2.as_atom());
// remove an entry:
map_atom_my_blob.erase(A1.as_atom());
The constructor and methods are as follows:
AtomMap.
The ValueType and StoredValueType specify what
type you wish for the value. Currently, two value types are supported:
PlAtom - the StoredValueType should be PlAtom.PlTerm - the StoredValueType shoud be PlRecord
(because the term needs to be put on the global stack).permission_error if the value
is already in the map, unless the value is identical to the value in the
map. The insert() method converts the value to the StoredValueType.
The insertion code takes care of atom reference counts.StoredValueType
to ValueType.
The mechanisms outlined in this document can be used for static linking with the SWI-Prolog kernel using swipl-ld(1). In general the C++ linker should be used to deal with the C++ runtime libraries and global constructors.
The current interface can be 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. 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 .h file.
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 PlEncoding optional
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, throw PlInstantiationError(A1)
does not result in the same context and traceback information that would
happen from
Plx_instantiation_error(A1. unwrap()); throw PlFail().
See
section 1.17.2.
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.
In this document, we presented a high-level interface to Prolog exploiting automatic type-conversion and exception-handling defined in C++.
Programming using this interface is much more natural and requires only little extra resources in terms of time and memory.
Especially the smooth integration between C++ and Prolog exceptions reduce the coding effort for type checking and reporting in foreign predicates.