Closed kamahen closed 2 years ago
These two casts were needed because I got "ambiguous cast" error without them.
ambiguous cast
That is my biggest worry with the C++ interface. It looks nice that you can cast Prolog terms to a C++ type to get the conversion, but it is rather easy to get it wrong :( If I recall correctly C++ defines bool
as char
, no? That would, I assume, imply we cannot have casts to both.
It's been years since I've programmed in C++, and the language was too complex even then for me to fully grasp its intracacies. The Google style guide has its flaws (the biggest being that it doesn't allow exceptions, but that's a legacy of the old gcc 2.95 compiler), but it does help reduce some of the cognitive overload and discourages clever tricks. (I knew some Algol-68 people ... they would be appalled at some of the automatic "coercions" that C++ does and the resulting complexity of the language and the compiler.)
Anyway, C++ weakly distinguishes bool, char, int -- it's possible to define different overladings for these. Otherwise, C++ follows the C rules of allowing a char to be treated as an int, and for converting an int (or char) to bool.
The definition of operator= in SWI-cpp.h is also dangerous because it breaks the normal convention of assignment operators, namely:
class-name & class-name :: operator= ( const class-name & ) = default;
I redefined the assignment operators to be "deleted" and found a few places in the code where assignment had been used without a test (for example). I'll try to fix these and send a new PR. I'll also take a look at Volker's code and see if that gives me any design ideas.
Merged. Updated
uint32_t
to use PL_get_int64() as that is good enough (with a check forv >= 0
) and doesn't depend on unbounded integer support. Not sure how many of these casts we actually want though.