Make enums derived from uint16_t at least or migrate to libfmt, to avoid garbled log in OPENRAVE_ASSERT_OP

[cielavenir]

Today I read boost::format source code and it turned out that it was just a frontend of stringstream (eg boost::str(boost::format("%x") % "xyz") is the same as std::cout << std::setbase(16) << "xyz" << std::endl;).

ostream, including stringstream, handles uint8_t in the same way as char ( cf https://cplusplus.com/reference/ostream/basic_ostream/operator-free/ ).

Recently openrave changed some enums derived from uint8_t ( https://github.com/rdiankov/openrave/commit/d841c7633ec34cbd95c6486811eb2d5401b198ad ). It is problematic when the values are directly passed to OPENRAVE_ASSERT_OP because if the assertion fails, boost::format is called, and the value are printed as char, which is unexpected and garbled. We paid some attention to pass the value with casting to int, but it is forgettable ( eg planningcommon https://tiny.mujin.co.jp/mcyzo ). To avoid further confusion, enums should be derived from uint16_t at least. Alternatively I suggest to migrate to libfmt ( we discussed this years ago https://tiny.mujin.co.jp/czkx4 ), which does not have this uint8_t output issue.

/cc @ntohge

[cielavenir]

cc @yoshikikanemoto (he got an issue related to this, where pybind11 exception message is not garbled but nothing is shown)

[cielavenir]

maybe product team want to take a look @felixvd @hemangandhi

[hemangandhi]

+1 on migrating to fmt -- I think that's a good future direction.

That said, we might want to start with moving to uint16_t so that {fmt} doesn't block pybind-related work.

[rdiankov]

Doesn't sound like a blocking or important issue at the moment....