I’ve started a new discussion here: https://swi-prolog.discourse.group/t/changes-to-swi-cpp-h
Not really, just some really outdated examples…
Hi
Until recently I have used SWI-cpp.h quite a bit in a project with a former employer. At first I used the c++ wrappers exclusively but slowly had to pull back and use the pure c interface due to a couple of limitations. At some point I commented on warnings in Visual Studio when mixing term_t and size_t (I believe it was), but this didn’t gain much traction, so I figured only few people were using SWI-cpp.h.
At the time I entertained the idea of rewriting parts of SWI-cpp.h to remedy at least some of my issues, but I think my ideas would break backwards compatibility… or alternatively introduce competing interfaces. In my own case I ended up creating my own abstractions.
Yes, I’ve run into some problems related to this. I’m trying to fix them with minimal changes to the API.
I was thinking of going through SWI-Prolog.h and adding more functions to the interface (and removing the operator methods because they seem to cause subtle problems … the rules are fairly complex and I’ve been unpleasantly surprised a few ties. It seems to me that it’s OK to implicitly convert PlTerm to term_t (and PlAtom to atom_t) but not much else … and even that might be dangerous because it won’t catch using a PlAtom when a PlTerm is better, so perhaps explicit casts are best.
It’s nice to be able to write:
PlTerm t;
... PL_is_variable(t); % same as Pl_is_variable(static_cast<term_t>(t))
but even better is t.is_variable().