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 ( d841c76 ). 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
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 asstd::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 ( d841c76 ). 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