On 4/27/19 10:18, Peter Dimov via Boost wrote:

There are two things that I suspect need to be fixed in Boost.Endian, but the changes are breaking.

1. endian_arithmetic<...> derives publicly from endian_buffer<...>. Intuitively, this inheritance relationship doesn't seem right, and it prevents endian_arithmetic from being a C++03 POD, due to having a base class.

2. the data() member function returns char const*. This type is strongly associated with null-terminated strings, and as such, using it for the underlying bytes of the endian object seems error-prone. I'd much prefer to return `unsigned char const*` from data() (although in C++17 `std::byte const*` might be even better.)

I can't however estimate with any certainty whether the (mostly aesthetic) benefit of these changes would outweigh the users' annoyance from their code being broken for no strong reason.

Comments?

I'm personally not a fan of breaking code without reason. I'm also a fan of progress and not stopping libraries from progressing. If we wanted stale libraries that aren't allowed to improve we would just use the stuff in std. As a user of the library I don't have a strong opinion either way ... which is like saying, do what makes you happy as the maintainer (o; It is interesting that these didn't come up in the review (or at least I am assuming they didn't. I looked over the mini-review discussion and didn't see anything). -- Michael Caisse Ciere Consulting ciere.com

Hi Peter, On Sat, Apr 27, 2019 at 7:18 PM Peter Dimov via Boost <boost@lists.boost.org> wrote:

1. endian_arithmetic<...> derives publicly from endian_buffer<...>. Intuitively, this inheritance relationship doesn't seem right, and it prevents endian_arithmetic from being a C++03 POD, due to having a base class.

I assume that the potential user base of Boost.Endian would benefit from endian_arithmetic begin a C++03 POD. I also assume that not many people explicitly rely on casts to the public base class... yet. Better to break now than later. I vote for the change, 2. the data() member function returns char const*. This type is strongly

associated with null-terminated strings, and as such, using it for the underlying bytes of the endian object seems error-prone. I'd much prefer to return `unsigned char const*` from data() (although in C++17 `std::byte const*` might be even better.)

I can't however estimate with any certainty whether the (mostly aesthetic) benefit of these changes would outweigh the users' annoyance from their code being broken for no strong reason.

You could offer a smooth transition with a proxy that has a deprecated `operator char const*` and a non deprecated `operator unsigned char const*`. https://wandbox.org/permlink/VpA5pWP3SPFYoWHu By the way, is there a hack to emulate a compile-time deprecation warning on pre C++14 compilers?