Re: [boost] [system] Would it be possible to trial a breaking change to Boost.System and see what happens?

On 15 Jan 2018, at 10:42 am, Niall Douglas via Boost wrote: What I are discussing here is whether to do something about the common mispractice or not i.e. whether, and how much, to change or even break the system_error API so the incorrectly written code becomes correct.

Ok, to provide you with some data points for your original proposals:

1. Stop treating code zero as always meaning success irrespective of category. This remedies a defect where some custom error code domains cannot be represented by error_code due to using value 0 for an error. In actual code, I've never seen anyone ever use comparison to anything but a default constructed error code, so I think this will be safe.

This change is not "safe" and will break currently supported source code. "Fixing" this source code to support your scheme will introduce an additional branch (to intercept and translate error codes in the zero/success case) where none is currently required, adding code bloat and a runtime performance penalty.

4. error_code::message() returns a std::string_view instead of std::string if running C++ 17 or better.

...

The use of string_view is a non-starter. It has unclear ownership semantics

I don't get the mental block people are having on this. The ownership obviously is by the error category from which it was sourced, so the storage needs to live as long as there is any instance of the category anywhere in the process. For most categories, it's a static const string table anyway living in the const part of the compiled binary.

...

and does not cater to error sources that compose their messages on demand (e.g. messages that are obtained from another API function, read from a file-based catalog, or constructed based on an error code value that happens to be a bitmask).

Static hashmap cache.

Such a change will penalise existing, supported source code by requiring these applications to hold a very large number of strings in memory, if it is indeed feasible to hold that many at all. In these applications, which contain a number of error categories representing different error sources: * Some messages are obtained via other APIs' functions, which populate a buffer. Assuming the API itself holds these strings in memory (sometimes it is read from file), we are now duplicating the memory usage. * Some error codes are not a simple enumeration but a bitmask containing a number of different fields. The message is composed from these fields, and the number of combinations of these fields is large indeed. I note that there is established non-std::string practice which involves copying a string into a supplied buffer. This may or may not be an acceptable approach in the standard library, but unlike your string_view proposal it does not impose the high runtime complexity or memory requirements of a hashmap cache, still removes the dependency on <string>, and supports freestanding/embedded environments. I appreciate that you were unaware of these data points and the purpose of your original email was to gather information. I hope that this information enables the development of proposals that will not break or severely penalise existing, supported use cases.