|
Boost : |
From: Julien Blanc (julien.blanc_at_[hidden])
Date: 2024-09-12 13:57:27
11 septembre 2024 à 21:46 "ÐмиÑÑий ÐÑÑ
ипов via Boost" <boost_at_[hidden]> a écrit:
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk