Printable View
String containing "cd" prints like this:
Does Linux/GDB always print strings like this, or am I doing something wrong?Code:$3 = {static npos = 4294967295,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data field s>}, <No data fields>}, _M_p = 0x8b6004c "cd"}}
That looks right. A string variable is just an instance of the string class, and so the contents of that class will be output by the debugger. Some debugger allow you to customize how it is output, but I'm not familiar with how to do that in gdb.
In any debugger, you could use something like this.
That would give you the C string, which should print without any extra frills.Code:print str.c_str()
Ahh... Interesting...Quote:
Originally Posted by dwks
However, I'm running through GDB pointers A LOT to see what's going on with everything... Is there any way to do c_str() by default?
Hmm. You could create functions like this
and call them like "p c(whatever)". ("p" is short for "print".) It would work for C++ strings and char[] strings.Code:const char *c(std::string &str) {
return str.c_str();
}
const char *c(const char *c) {
return c;
}
Other than that, I can't think of any shorter way to do it at the moment.
A few other things you might want to know: "$" evaluates to the previous result, $$ to the one before that. And you can use $N to access a specific result. (Notice that whenever you print something, it gets a number? Well, you can use $14 or $20 or whatever to get that exact value.)
Damn... Smart... HahaQuote:
Originally Posted by dwks
Why the "const" though?
Because it says it cannot be modified, so the compiler will complain if you try.
The .c_str() function returns a const char* pointer, so it is wrong to modify it in the first place, and as C++ is type strict, it won't compile unless you return a const char*.
[And if you modify it, it will result in undefined behavior.]
But why would you? The entire string can be read from the debugger, it just gives some extra information about its trait and allocator classes.Quote:
In any debugger, you could use something like this.
Code:print str.c_str()
Writing extra code for debugging might introduce new errors (have you never written erroneous test-code, which made you spending hours to search a bug which wasn't there? I have..).
Simply ignore the extra information from the debugger and everything is just fine...
But if you're examining a lot of strings, it might be slower to do as you suggest. Your eye doesn't easily skip over the other stuff GDB prints, especially if the string is only a few characters long.
Yes, introducing new test code can introduce new bugs. But as long as you're aware of that fact, such code can really make your life easier. For example, one time I was debugging a tree, where nodes consisted of pointers; so in order to examine the whole tree, I had to use a lot of print statements. I wrote a simple function which dumped the whole tree, and it made my life a lot easier . . . .
Haha! That's pretty much exactly what I have to do!Quote:
Originally Posted by dwks
For the first part of the project, we did a linked list representation, so I just printed every linked list in the trie out to screen.
For the second part, now we have to do trees.
Kind of off topic, but what's a good way to print a tree to command prompt?? Did you actually do spaces between the nodes, or just say like "left child: value" etc?
I indented the nodes with spaces to get a graphical representation. Something like this. (Which I just typed up in this box and may not work properly.)Quote:
Originally Posted by Paul22000
That's for a sort of trie-like structure, not a binary tree (which is what you have, right?). It might generate printouts like this.Code:struct data {
int data;
struct data *next;
size_t nexts;
};
void dump_node(struct data *tree, int indent);
void print_indent(int indent);
void dump_data(struct data *tree) {
dump_node(tree, 0);
}
void dump_node(struct data *tree, int indent) {
size_t x;
print_indent(indent);
std::cout << tree->data << std::endl;
for(x = 0; x < tree->nexts; x ++) {
dump_node(tree, indent + 1);
}
}
void print_indent(int indent) {
int x;
for(x = 0; x < indent; x ++) std::cout << " ";
}
You can print a tree however you like . . . I like to use whitespace, however. Your eye easily passes over it, and you still get an idea of what the structure looks like.Code:0
1
2
4
6
3
Ohhhh ok, so don't put spaces on the left. That makes it easier!
I'm confused as to how you have it, so 1/2 are children of 0.
4 and 6 are children of 2?
And 3 is child of 6?
For this project the data is stored in a trie AND a secondary data structure (first linked lists, and now on to binomial heaps). Basically to make various operations like merge faster, since we have the choice of accessing the data with either of the two data structures.
You can print the data any way you want. The way I printed it is suitable for the type of structure I had:
Basically, every structure pointed to zero or more (many more) other structures.Code:struct data {
int data;
struct data *next;
size_t nexts;
};
I think with complex structures like a binomial heap, unless you can come up with a way to depict them graphically, you might have to print them linearly.
You could try to record everything you're going to print and then format it before you print it -- which would let you display a binary tree, for example -- but that's probably just overkill for a debugging function. :)