GeneralSaver (was: Access to compiler's variable types possible ?)

[Cymric]

Not within standard ANSI-C, and not without severe hacking of the C++ runtime library by the looks of things. I have a strong hunch that that various debugging hunks written out by the compiler can be parsed to derive the information you're after: good debuggers allow you to look at variables and the like, and for that they must know the type---which is what you want to know. That's as far as my knowledge can take you, unfortunately.

[Cymric]

BTW aren't the hunks debuggers use written down after the code is actually compiled ? That would rule out that option.

Well, it depends on what you were after, which wasn't very clear from my point of view :-). If you write all programs yourself, then you know the type of variable at compile time---there's no need to ask the program or the compiler. If you want you can abstract away that information so that the program itself can determine at runtime the type of objects it's dealing with (in essence providing the rudimentaries of  a runtime library found in C++ or ObjectiveC), but this would be a pain in programming, as everything is a struct or pointer to a struct. Your code would be littered with #define's and the like to hide the fact that you're not accessing a variable directly, but through a struct.

In C, there is no magical recipe which dereferences a pointer and says 'oh, that's an integer', or 'oh, that's an union'. You can with some clever heuristics determine whether you are dealing with a pointer, but those tricks rely heavily on the machine's architecture. And whether it is a pointer or not is not of much use unless you are into automated memory management.

If you haven't written the program, then what you're after is much, much harder, and relies on the presence of those debugging hunks, or a so-called cooperative language which stores that information in the executable. Java is an example of such a language.

[Cymric]

It's probably the only way to do it, and not much more work than a 'conventional' custom loader / saver. This does pretty much the same thing, but then dumps the variables straight to non-volatile memory, without bothering with type information and what not.

Generalisation can be cumbersome depending on whether you want to be able to simply 'plug & go'. With unions you can code this quite elegantly; with pointers you can 'shadow' variables throughout the program with but a single assignment. Nevertheless, if you want to be able to dump N-dimensional arrays, strings, and complex structs, things can become tricky. You will need to specify some sort of loader format too: is it write-as-you-ask, or will you group all strings near the end of the file; will you provide error checking or not; etcetera.

However, you cannot make it completely general, as structs are not completely general. You will need some program code to deal with the specific nature of the structs you're dumping, although the building blocks they are made up of (ints, chars, pointers, floats, ...) are general.

In my experience though, such little blocks of code are extremely useful and reusable if you've coded them as general and robust as you can. You might spend a week getting it to work, but the effort is worth it. I created a small set of routines to set all kinds of parameters in the program in a standardised way (complete with input checking against preset bounds) and various function hooks to do some pre- or postprocessing, and it has worked marvellously in any program I've linked it to. Write down the question, provide some glue code to link the input values to program parameters, and forget about the rest.

[Cymric]

Not a bad idea, but it needs extension: you must store that type string in the dump too, and that requires some indication as to its length. Second, you need to be able to distinguish between various structs (and unions). That's what makes such a state-dumping routine somewhat less-than-easy to write, although it is atill all perfectly straightforward C, of course.

[Cymric]

*Ponders a little*. No, I don't think that switching to C++ is very useful. Of course, the OO-ness does provide a nice, consistent interface (which is a Good Thing, by the way), but it still doesn't easily tell you what variables need to be serialised---and that's what this discussion is all about. With C++ all classes still would need their own serialisation function, and those would still need manual updates if the variable structure of that class changes. (Thus rendering the entire class / inheritance idea more or less superfluous again.) The main problem Jose is facing is that there is no keyword (not in C, not in C++) which gives you back some structure outlining the variables and their type in a given scope.

[Cymric]

No, the loader doesn't know, especially if you use variable-length strings. As for the structs: that's nice, but if you write an 's' in the description to indicate a struct, which one are we referring to...?

[Cymric]

Waiting for comments...

Yes, start coding already, dagnabbit! Unless you want us to come up with the program ourselves, of course. Try it out, see what works and what doesn't.

Another hint I can give you is that you should avoid falling into the trap of thinking 'oooo, that's a lot of C, that's going to take awhile'. On a moderarely fast CPU (which you are surely using), such routines hardly take more than a few milliseconds. Even if you add a small parser. Don't worry about speed. You'll be spending far more time coding the routines than can be made up by code optimisations or clever algorithms.

And finally, could you please cut long comments in two? It is so damn annoying to have to scroll the window sideways in order to read the main text.