|
Boost : |
From: ÐмиÑÑий ÐÑÑ
ипов (grisumbras_at_[hidden])
Date: 2024-08-08 21:54:30
пÑ, 9 авг. 2024â¯Ð³. в 03:36, Niall Douglas via Boost <boost_at_[hidden]>:
>
> On 08/08/2024 17:56, Vinnie Falco via Boost wrote:
> > On Wed, Aug 7, 2024 at 4:04â¯PM Jeff Trull via Boost <boost_at_[hidden]>
> > wrote:
> I would much rather that the maintainer of the library inlines the
> visualisers for their library, and then maintains them over time as
> their library changes.
>
> To make this work well, what we really need and don't have is a
> visualiser testing framework i.e. unit tests will fail if your
> visualiser stops matching your C++.
In my WIP GDB pretty printer branch I have the basis for GDB pretty
printers tests.
The "framework" consists of
1) an executable that creates objects to print and has labels at which
to print (https://github.com/boostorg/json/pull/733/files#diff-61c3f2894b149b936ad83868d940590331717dd9d3819c6edc8bd1d272a5455d),
2) a Python script that makes GDB jump to labels and print expressions
(https://github.com/boostorg/json/pull/733/files#diff-61c3f2894b149b936ad83868d940590331717dd9d3819c6edc8bd1d272a5455d),
3) b2 script to make that work from b2
(https://github.com/boostorg/json/pull/733/files#diff-2cde2bed13578c1217b50477bd73f8a50635ed874d15bac0f883a6ec59db2188).
This in theory could be turned into something more reusable.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk