Re: RFC: fix std::unique_ptr pretty-printer
On 14 August 2012 15:44, Tom Tromey wrote: Jonathan == Jonathan Wakely jwakely@gmail.com writes: Jonathan I prefer it as unique_ptrdatum but I'm probably not your typical Jonathan user of the pretty printers, so if anyone else has an opinion please Jonathan share it. I prefer it too. Here's the updated patch. Let me know what you think. I like it, please go ahead and check that in it you're happy with it.
Re: RFC: fix std::unique_ptr pretty-printer
Jonathan == Jonathan Wakely jwakely@gmail.com writes: Jonathan I like it, please go ahead and check that in it you're happy Jonathan with it. I did. Thanks. Tom
Re: RFC: fix std::unique_ptr pretty-printer
Jonathan == Jonathan Wakely jwakely@gmail.com writes: $11 = std::unique_ptr containing (datum *) 0x6067d0 Jonathan It's inconsistent with the other printers in that it prints Jonathan the stored type, unlike e.g. std::vectorint which just says Jonathan std::vector of length ... but I think that's an improvement. Yeah... without this bit it was just printing $11 = std::unique_ptr containing 0x6067d0 Ordinarily, gdb will print the type here; but it doesn't when called from Python. I thought the typical output was easier to read. Jonathan Personally I'd prefer the element_type as part of the type, e.g. Jonathan std::unique_ptrdatum = 0x6067d0 but that would be even more Jonathan inconsistent! I can make that change if you'd prefer. I don't know why, but I didn't even think of it. Tom
Re: RFC: fix std::unique_ptr pretty-printer
On 13 August 2012 14:31, Tom Tromey wrote: Jonathan == Jonathan Wakely jwakely@gmail.com writes: $11 = std::unique_ptr containing (datum *) 0x6067d0 Jonathan It's inconsistent with the other printers in that it prints Jonathan the stored type, unlike e.g. std::vectorint which just says Jonathan std::vector of length ... but I think that's an improvement. Yeah... without this bit it was just printing $11 = std::unique_ptr containing 0x6067d0 Ordinarily, gdb will print the type here; but it doesn't when called from Python. I thought the typical output was easier to read. Jonathan Personally I'd prefer the element_type as part of the type, e.g. Jonathan std::unique_ptrdatum = 0x6067d0 but that would be even more Jonathan inconsistent! I can make that change if you'd prefer. I don't know why, but I didn't even think of it. I prefer it as unique_ptrdatum but I'm probably not your typical user of the pretty printers, so if anyone else has an opinion please share it.
Re: RFC: fix std::unique_ptr pretty-printer
On 10 August 2012 20:49, Tom Tromey wrote:
A user reported on irc that the std::unique_ptr pretty-printer yields
bad results. For example:
(gdb) p uptr
$1 = std::tuple containing = {
[1] = ,
[2] = {
std::default_deletedatum = {No data fields}, No data fields}
}
This omits the actual pointer and prints some useless stuff instead.
This patch fixes the printer and adds a test.
The new output looks like this:
$11 = std::unique_ptr containing (datum *) 0x6067d0
Let me know what you think.
It's inconsistent with the other printers in that it prints the stored
type, unlike e.g. std::vectorint which just says std::vector of
length ... but I think that's an improvement.
Personally I'd prefer the element_type as part of the type, e.g.
std::unique_ptrdatum = 0x6067d0 but that would be even more
inconsistent!
OK for trunk, thanks.
