[Bug libstdc++/65230] New: pretty-print inconsistent output for similar objects

[Bug libstdc++/65230] New: pretty-print inconsistent output for similar objects

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230

            Bug ID: 65230
           Summary: pretty-print inconsistent output for similar objects
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: msebor at gcc dot gnu.org

The libstdc++ pretty printer produces inconsistent output for objects with
similar properties, making it more difficult than necessary to interpret.   For
example, an "empty" bitset object (one consisting of no bits, or one with no
bits set) is printed simply as "std::bitset" while an empty std::tuple<> is
printed as "empty std::tuple".  A std::vector<bool> of size 0 is printed to
include its size and capacity, while a non-empty vector<bool> also includes its
elements. An example is below.

I'd like to propose that the value of an empty object be printed as "{ }"
regardless of its type.  I.e., a std::bitset<0> as "std::bitset { }", a
std::tuple<> as "std::tuple<> { }", and an empty std::vector<T> as
"std::vector<T> of length 0, capacity N = { }"

$ g++ -g -std=c++11 t.cpp && gdb -batch -ex "b foo" -ex "r" -ex "p b0" -ex "p
b1" -ex "p t0" -ex "p t1" -ex "p v0" -ex "p v1" -q a.out
Breakpoint 1 at 0x100008a8: file t.cpp, line 9.

Python Exception <class 'gdb.error'> There is no member or method named _M_w.: 
Breakpoint 1, foo(std::bitset<0ul>, std::bitset<1ul>, std::tuple<>,
std::tuple<int>, std::vector<bool, std::allocator<bool> >, std::vector<bool,
std::allocator<bool> >) (b0=std::bitset, b1=std::bitset, t0=empty std::tuple,
t1=std::tuple containing = {...}, v0=std::vector<bool> of length 0, capacity 0,
v1=std::vector<bool> of length 1, capacity 64 = {...}) at t.cpp:9
9    }
Python Exception <class 'gdb.error'> There is no member or method named _M_w.: 
$1 = std::bitset
$2 = std::bitset
$3 = empty std::tuple
$4 = std::tuple containing = {[1] = 0}
$5 = std::vector<bool> of length 0, capacity 0
$6 = std::vector<bool> of length 1, capacity 64 = {0}

[Bug libstdc++/65230] pretty-print inconsistent output for similar objects

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-02-27
     Ever confirmed|0                           |1

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #0)
> I'd like to propose that the value of an empty object be printed as "{ }"
> regardless of its type.  I.e., a std::bitset<0> as "std::bitset { }", a
> std::tuple<> as "std::tuple<> { }", and an empty std::vector<T> as
> "std::vector<T> of length 0, capacity N = { }"

Yes, I like this suggestion.

[Bug libstdc++/65230] pretty-print inconsistent output for similar objects

[drepper.fsp+rhbz at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230

Ulrich Drepper <drepper.fsp+rhbz at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |drepper.fsp+rhbz at gmail dot com

--- Comment #2 from Ulrich Drepper <drepper.fsp+rhbz at gmail dot com> ---
Let's go through the details.  I like the idea of a common format but there
also
shouldn't be any information lost.

Here's some test code, similar to what Martin has:

#include <tuple>
#include <array>
#include <vector>
#include <bitset>
#include <memory>

int main()
{
  std::tuple<> t1;
  std::tuple<int> t2;
  std::tuple<int,int> t3;
  std::vector<int> v1;
  std::vector<int> v2 { 0 };
  std::vector<int> v3 { 0, 0 };
  std::array<int,0> a1;
  std::array<int,1> a2 { 0 };
  std::array<int,2> a3 { 0, 0 };
  std::pair<int,int> p1;
  std::bitset<0> b1;
  std::bitset<1> b2("0");
  std::bitset<2> b3("00");
  return 0;
}


The output as of gcc-12.1.1 (and gdb-12.1, what a coincidence) is:

(gdb) info locals 
t1 = empty std::tuple
t2 = std::tuple containing = {[0] = 0}
t3 = std::tuple containing = {[0] = 0, [1] = 0}
v1 = std::vector of length 0, capacity 0
v2 = std::vector of length 1, capacity 1 = {0}
v3 = std::vector of length 2, capacity 2 = {0, 0}
a1 = {_M_elems = {<No data fields>}}
a2 = {_M_elems = {0}}
a3 = {_M_elems = {0, 0}}
p1 = {first = 0, second = 0}
b1 = std::bitset
b2 = std::bitset
b3 = std::bitset

This is just my opinion, but I would like to see the following output (NB, this
already uses the tuple pretty printer change I committed):

(gdb) info locals 
t1 = std::tuple<> = { }
t2 = std::tuple<int> = {[0] = 0}
t3 = std::tuple<int,int> = {[0] = 0, [1] = 0}
v1 = std::vector<int> of length 0, capacity 0
v2 = std::vector<int> of length 1, capacity 1 = {0}
v3 = std::vector<int> of length 2, capacity 2 = {0, 0}
a1 = std::array<int,0> = { }
a2 = std::array<int,1> = {0}
a3 = std::array<int,2> = {0, 0}
p1 = {first = 0, second = 0}
b1 = std::bitset<0> = { }
b2 = std::bitset<1> = {0}
b3 = std::bitset<2> = {0, 0}

This means several changes but it corrects the rather ad-hoc nature of the
current output to be more uniform.

[Bug libstdc++/65230] pretty-print inconsistent output for similar objects

[drepper.fsp+rhbz at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230

--- Comment #3 from Ulrich Drepper <drepper.fsp+rhbz at gmail dot com> ---
Actually, I think for the std::pair definition I'd like to see

p1 = {[0] = 0, [1] = 0}

instead of

p1 = {first = 0, second = 0}

Again, more uniform and I'd say it should be encouraged to use std::get instead
of .first / .second because it's compatible with std::tuple.

[Bug libstdc++/65230] pretty-print inconsistent output for similar objects

[drepper.fsp+rhbz at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230

--- Comment #4 from Ulrich Drepper <drepper.fsp+rhbz at gmail dot com> ---
Ugh, this one is a pasto:

v1 = std::vector<int> of length 0, capacity 0 = { }

instead of

v1 = std::vector<int> of length 0, capacity 0

[Bug libstdc++/65230] pretty-print inconsistent output for similar objects

[drepper.fsp+rhbz at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230

--- Comment #5 from Ulrich Drepper <drepper.fsp+rhbz at gmail dot com> ---
Or should the std::pair output even be

p1 = std::pair<int,int> = {[0] = 0, [1] = 0}

??

[Bug libstdc++/65230] pretty-print inconsistent output for similar objects

[drepper.fsp+rhbz at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230

--- Comment #6 from Ulrich Drepper <drepper.fsp+rhbz at gmail dot com> ---
Created attachment 53410
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53410&action=edit
consistent pretty printing of contains

How about this patch?

I used the attached test case.  With the current code 'info locals' at the end
of the function prints:

t1 = empty std::tuple
t2 = std::tuple containing = {[0] = 0}
t3 = std::tuple containing = {[0] = 0, [1] = 0}
v1 = std::vector of length 0, capacity 0
v2 = std::vector of length 1, capacity 1 = {0}
v3 = std::vector of length 2, capacity 2 = {0, 0}
va1 = std::vector of length 0, capacity 0
va2 = std::vector of length 1, capacity 1 = {0}
va3 = std::vector of length 2, capacity 2 = {0, 0}
a1 = {_M_elems = {<No data fields>}}
a2 = {_M_elems = {0}}
a3 = {_M_elems = {0, 0}}
p1 = {first = 0, second = 0}
b1 = std::bitset
b2 = std::bitset
b3 = std::bitset
b4 = std::bitset = {[0] = 1}
b5 = std::bitset = {[70] = 1}

With the patch it prints:

t1 = std::tuple<> = {}
t2 = std::tuple<int> = {[0] = 0}
t3 = std::tuple<int, int> = {[0] = 0, [1] = 0}
v1 = std::vector<int> of length 0, capacity 0 = {}
v2 = std::vector<int> of length 1, capacity 1 = {0}
v3 = std::vector<int> of length 2, capacity 2 = {0, 0}
va1 = std::vector<int, va<int> > of length 0, capacity 0 = {}
va2 = std::vector<int, va<int> > of length 1, capacity 1 = {0}
va3 = std::vector<int, va<int> > of length 2, capacity 2 = {0, 0}
a1 = std::array<int, 0> = {}
a2 = std::array<int, 1> = {0}
a3 = std::array<int, 2> = {0, 0}
p1 = std::pair<int, int> = {[0] = 0, [1] = 0}
b1 = std::bitset<0> = {}
b2 = std::bitset<1> = {}
b3 = std::bitset<2> = {}
b4 = std::bitset<2> = {[0] = 1}
b5 = std::bitset<72> = {[70] = 1}

This is quite a change from before but I think quite consistent.  NB: also
tested with _GLIBXX_DEBUG.

There is one point I'm not sure about: should the std::vector printer
explicitly show the length (capacity is no question)?  This is the one
remaining inconsistency.  The tuple printer does not explicitly list the number
of elements.  On the other hand, to avoid making the output too long the
std::vector printer does not show the indeces and therefore the number of
elements cannot be see right away.  So, maybe leave it as is?

BTW: notice that I added a pretty printer for std::array and I also added code
to recognize a standard allocator template argument to std::vector (which in
this case is not shown).

[Bug libstdc++/65230] pretty-print inconsistent output for similar objects

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Ulrich Drepper from comment #3)
> Again, more uniform and I'd say it should be encouraged to use std::get
> instead of .first / .second because it's compatible with std::tuple.

Which makes sense given the even-closer alignment between them in C++23 due to
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2165r4.pdf

(In reply to Ulrich Drepper from comment #5)
> Or should the std::pair output even be
> 
> p1 = std::pair<int,int> = {[0] = 0, [1] = 0}
> 
> ??

Yes, I think that's better.

[Bug libstdc++/65230] pretty-print inconsistent output for similar objects

[drepper.fsp+rhbz at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230

Ulrich Drepper <drepper.fsp+rhbz at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #53410|0                           |1
        is obsolete|                            |

--- Comment #8 from Ulrich Drepper <drepper.fsp+rhbz at gmail dot com> ---
Created attachment 53418
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53418&action=edit
Update pretty printers for all? containers

I spent some more time on this and should now have covered all the containers. 
The changes for the other containers are in line with what the previous patch
produced.  The output should now be as consistent as possible across all
containers.

Along the line some bugs have been fixed, too.

To illustrate the change I'll also attach to this bug a diff -y output of the
current and the proposed code.

[Bug libstdc++/65230] pretty-print inconsistent output for similar objects

[drepper.fsp+rhbz at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65230

--- Comment #9 from Ulrich Drepper <drepper.fsp+rhbz at gmail dot com> ---
Created attachment 53419
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53419&action=edit
diff -y of current and proposed output

To compare the results more easily.