How do I show all of the variables + their single structure names that are within a structure type to the user?
How do I show all of the variables + their single structure names that are within a structure type to the user?
Last edited by Warrax; 05-05-2007 at 06:28 AM.
first, your post is quite confusing to difficult to understand.
you use '.' (period) to access members of the struct. if the struct is a pointer you use '->' ('indirect member selection' operator). to show the information, you use the same method you would for showing any other information.
Fixed; it should be easier to understand, now, :-).
Same way you would a class. Write a meathod or function that prints everything that you need out.
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
There is no automated way to print the name and value of all struct members: the name is no longer available at runtime.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Just out of curiosity, would there be a way of writing a program such that if it were compiled into a debug version (i.e. with the symbolic tables embedded), the program be able to look into its own symbolic table?
I mean, a vague idea would be
Code:int main(int argc, char* argv[]) { FILE* f = fopen(argv[0], "r"); //so here you'd pass its own self as an argument look_in_the_symbolic_table_of_the_file_,_format_it_and_print_it_out(f); }
argv[0] doesn't necessarily contain the filename of the program in question.
There are 10 types of people in this world, those who cringed when reading the beginning of this sentence and those who salivated to how superior they are for understanding something as simple as binary.
> the program be able to look into its own symbolic table?
Theoretically, yes. Examples of such programs are called debuggers.
But if you only have one or two such structures, then its much easier to roll the code yourself.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Is it shell specific? At least in Bash and Windows, I think you always get the name of the executable or script.argv[0] doesn't necessarily contain the filename of the program in question.
It always includes the filename, but it may also include the path or a partial path.
And the filename in question might specify a symbolic link.
Oh, and the filename is looked up in the PATH, whereas fopen doesn't look, which means that if you don't call the program with an explicit path, it won't find the executable in the fopen call.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Right, I'd forgotten that executables have to be in the path to run. I guess you could do some kind of combo with getenv and searching for the file in each of the path directories.
Symbolic links... Can't see any way around that. Oh well, recursive self-reference is always interesting.