Hello all,

I recently wrote my own freestanding replacement for the C++ standard library.  I'm one of those people who started writing out C++ on a 44Mhz processor and never was allowed to use the standard template library because it was too bloated. In many ways this code is the exact opposite of Boost in terms of its design. I'd like to share a few details with this list because I think it is interesting to talk about what could be done to improve the developer experience of the standard library. Please be warned, I have a lot of opinions about C++ and they are nonconformist.

In this email I would like to talk about asserts. I'd like to see a lot more features available than with pre/post/contract_assert.

I would argue there has to be support by default for making the debugger stop on the exact line where the assert fired. There is just no excuse for having a software engineer do unnecessary manual labour every time an assertion fires. And students shouldn't be asked to write this themselves when learning a new language. Currently only clang (and not gcc) can be configured to support this perfectly.

There are also uses for having different "levels" of severity when it comes to asserts. When I am cross compiling to an embedded target I am not going to be able to afford all the same assertions with all the same strings being added to the string table. At minimum that entails "debug asserts" and "release asserts" to differentiate between the two use cases. The code I am sharing also uses compile time string hashing in order to identify filenames when compiled for release. (This didn't work reliably with constexpr and you have to check the generated assembly to find that out.) Having these kinds of build levels is also common enough that CMake has it built in.

(As a slight aside, it would be nice to have support for string hashing in the elf file format. That way strings could be replaced by integers in the generated assembly and then the debugger could look up those strings in an optional string table. There is no reason to have a huge list of human readable names embedded in a stripped executable's string table when you are testing code on a 16-bit processor.)

Next is the issue of formatting assert messages. It turns out to be really handy to have debug asserts that take C-style variadic arguments and perform printf formatting. There is an issue here with having untested format strings and that does need to be resolved. However, by leveraging gcc's ability to check a printf format string against its arguments I was able to avoid any issues in my own work. This approach avoids making an unnecessary local function call or allocating memory after an assertion fails.

With that out of the way, let me show you some code.  This is a debug assert that implements the above:

#define hxassertmsg(x_, ...) (void)((bool)(x_) \

|| (hxloghandler(hxloglevel_assert, __VA_ARGS__), hxasserthandler(__FILE__, __LINE__)) \

|| hxbreakpoint())

The assert handler returns true when it wants a breakpoint set.

Next is a macro that implements a release assert at a higher release level. (hxstring_literal_hash uses some horrifying macros.) 

#define hxassertrelease(x_, ...) (void)((bool)(x_) \

        || (hxasserthandler(hxstring_literal_hash(__FILE__), __LINE__), 0))

The result is adding one function call with two integer parameters to the executable. This macro is also capable of printing formatted messages and setting breakpoints at lower release levels. This particular version uses a handler that is also marked noreturn.

There are more pieces of functionality needed. Any C++ library implementing asserts is going to want the compiler to know that the release mode assert handler or log handler cannot throw an exception. However, there is overhead associated with "noexcept" and it is just impossible to add that overhead everywhere an assert is used. This is something that still requires compiler intrinsics.

The standard library also has explicit language allowing for its asserts to operate in a manifestly const environment. It would be nice for others to be able to access that functionality without mucking up the callstack for every assert in the codebase.

If you made it this far, thank you. Here are some links if you want to know more. This is the main header file for the Hatchling Platform which has been my test bed and includes this code:

https://github.com/whatchamacallem/hatchlingplatform/blob/master/include/hx/hatchling.h

Here is the whole project and it has some overview docs. Please be kind, this is a solo effort that is just being released to the world and I am not trying to go head to head with the standard library over all the possible things.

https://github.com/whatchamacallem/hatchlingplatform/

Stay tuned and I'll put something else together about developer experience and micro-optimization. I am happy to write a formal proposal if anything resonates with the list.

Regards,

Adrian Johnston