Are you the author of the program?
If so, why not just initialize everything at the beginning of the program so you don't have to wonder?
Are the data types all going to be numeric, as in your example?
I don't think there is an easy way to do it. Off the top of my head, one way would be to assign a Boolean variable to each variable to indicate if it has been initialized or not.
If the variables are all numeric, you might try using isnan() in <cmath>.
Also, this might interest you, and it is relevant:
Yesterday when I was looking for information about quiet_NaN, I came across several informative threads on stackoverflow. You might want to head over there and do a search for "quiet_NaN". Here are some of the more interesting/relevant threads:
Well, for one, you must always turn on all the warnings (-Wall) when compiling your code, and most compilers will warn you when you are using uninitialized variables, or that a variable might be uninitialized at some point.
If the type is not a trivial type (int, double, etc.., and some trivial classes), then it will always be default-initialized or zero-initialized. Only trivial variables can be truly uninitialized (i.e., have some garbage value).
Some compilers (e.g., Visual Studio, Borland, etc.), under debugging-mode, will fill all uninitialized memory with some weird bit-pattern to informally mark them as being uninitialized. When you are debugging and reading a stack dump or memory dump in hexadecimal form, you will see patterns like 0xBAADF00D or 0xDEADBEEF in the memory, those correspond to uninitialized memory. The reason why this is only done in debugging-mode is because it is an expensive operation, and any correct program cannot be relying on any kind of uninitialized memory, so, it is useless in any final product / application.
Uninitialized variables have an undefined value. This means that a correct program cannot use that value under any circumstance. And for that reason, there is no such thing as a function to "check if it is initialized" because that would imply the possibility of reading the value of an uninitialized variable, which is undefined behavior, and thus, an incorrect program. In other words, such a function would be, by definition, a guaranteed bug in your program.
The solution, of course, is to always initialize your variables where they are declared. It rarely makes sense to declare a variable at a point where you cannot determine a meaningful (possibly "neutral") value to give it. If you can't think of a value to initialize the variable with, you are probably declaring it too early in the function. The only typical situation in which a variable remains uninitialized for a little (tiny) amount of time, is this:
if( /* something */ )
a = /* some value */;
a = /* some other value */;
Or something very similar to that (the point is that you don't want a to be in the scope of the if-else statements).
And, in the worst case, as DavidB pointed out, you can use some other "marker" (like a bool, or a state-flag, or some fancy device like boost::optional, boost::variant, or Alexandrescu's "expected" template or whatever else). But that is rarely needed in practice.