11 septembre 2024 à 21:46 "Дмитрий Архипов via Boost"
Recently Niall Douglas posted about his idea to embed GDB pretty printers into binaries using a header. At the time I was thinking about a good way to deploy pretty printers for JSON that facilitates their autoloading. After Niall's post I experimented a little bit more, and I came to the conclusion that indeed nothing beats embedding via a C++ header in terms of convenience.
I mostly agree with that statement, with a few caveats though. The main issue i've seen is that with some linkers, the .debug_gdb_scripts section is duplicated several times when the file is included several (although not exactly once per inclusion…), and this causes issues later with gdb (types registering multiple times, etc.). While i observed these only with compilers for embedded targets and pretty old toolchains, we finally used a different approach, based on the inclusion of a single cpp file in the project. This is not feasible for boost, however, i think the following can be done quite easily: * the macro to opt out from gdb pretty printing already exists, move its usage from inside gdb_printers.hpp to config.hpp * provide a public (ie, not in details) json/debug_printers.hpp file, which unconditionnaly includes gdb_printers.hpp, to opt-in again. This file shall not be included by any library code. This allows client code to circumvent the limitations, and is fully transparent for users not affected by the duplicated python code issue. I can file a PR if you are ok with this approach.
My questions to the community: do you find this useful? Would you use it in your Boost or non-Boost library? If you do, the module should be moved to tools rather than stay in libs/json.
Testing printers is indeed part of the job (we've had our bunch of broken printers where i work), so yes, this is definitely useful. Thanks for sharing this. Regards, Julien