Yes, that is the current usage of auto. As you have found out, it is rather pointless and very, very rarely used, hence the decision was made to sacrifice this in favour of the new semantics of auto in the next version of C++.Originally Posted by Programmer_P
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Right. I don't know why I did that to begin with. I guess because I got in the habit of commenting stuff.
That's an interesting link (bookmarked it for future reference).Descriptive names are fine. As for Hungarian notation, read Stroustrup's answer to the FAQ: How do you name variables? Do you recommend "Hungarian"?
Thanks.
Anyway, its all a matter of personal preference. But Stroustrup did make a valid point about possibly running into a problem later on where you change the type of a variable, so the name is no longer accurate when using Hungarian notation. I think I probably will just stick with descriptive names and leave off the hungarian notation in the future. Its just something I recently started doing, thinking it might make things a little more clearer, but I guess not.
I'm an alien from another world. Planet Earth is only my vacation home, and I'm not liking it.
The string streams work a lot like and are on some level based on the types of streams cin and cout are. This means that you will have all the same issues dealing with string streams -- operations can and will fail on a string stream. So that is probably the crux of the problem.
While string streams are handy for converting numbers, you can also do basic parsing with string extraction (which works as it does in cin), and other functions, such as get() and ignore(). I recommend this approach to you. Poke your nearest reference.
Assuming that you will ignore this suggestion, you can also clear() the stream and replace your string when you are ready to convert more strings to numbers. This way you will not confuse the state of the stream versus the source's value.
Code:// mess with your string ... iss.str(source); if (iss >> literalConstant) { // good } else { // bad } iss.clear(); // mess with source again iss.str(source); if (iss >> literalConstant) { // and so forth ... }
Hmm...I decided I don't need to clear the istringstream (since it will be a different object of istringstream for each string enumerator value), but clearing the int I'm inserting into after I'm done using it for the current enumerator might work (that way the variable will be recreated in memory with the same identifier for each int). Is there anyway to explicitly destroy a normal stack variable, i.e. something akin to destroying an object on the heap with "delete"?
Last edited by Programmer_P; 07-09-2010 at 08:13 PM.
I'm an alien from another world. Planet Earth is only my vacation home, and I'm not liking it.
I can guarantee that string streams do not mishandle PODs like int. In fact if operation fails then the int would stay the same. This is about you not checking for correctness, most likely.
I showed you. The idiom for this is to provide a function that destroys the contained object or resource, e.g. stream.clear(), file.close(), ptr.reset().Is there anyway to explicitly destroy a normal stack variable
A stack variable's lifetime is also defined by its scope, so you might surround an object declaration and its statements in curly braces, also.
There is no other option.
Last edited by whiteflags; 07-09-2010 at 08:25 PM.
Alright, I answered my own question. There is no problem with the istringstream >> operator inserting into a variable which already has a value, which this code proves:
C++ code - 21 lines - codepad
So it seems I need to search for my problem elsewhere...
I'm an alien from another world. Planet Earth is only my vacation home, and I'm not liking it.
Well maybe, but try following my example first. I mean, I haven't reached the same conclusion you have. Your extraction may just be failing and the literal constant values left alone. Always validate stream operations.
You were correct. I was not checking for correctness, and I'm still not checking for correctness. I'm going to assume the user passes a file with a valid enum.I'm not going to provide support for invalid enums, because it would be too much of a pain trying to handle every single wrong use case (I do warn the user though before the conversion process begins that I didn't provide support for invalid enums).
Anyway, I fixed that problem (thanks to that comment, which made me think what the problem might be). It turns out the string I was stripping was the wrong one, and so the string being passed to the istringstream object was empty, which is why the value of the int didn't change. Once I changed the code to strip the right string instead, it does as expected (well, not quite...but at least now I'm on to a different problem).
Thanks for the help everyone.
Last edited by Programmer_P; 07-09-2010 at 08:49 PM.
I'm an alien from another world. Planet Earth is only my vacation home, and I'm not liking it.
It isn't difficult to support invalid cases. If your extraction fails, or if you don't get what you expect, then simply fail. Throw an error or whatever.
I did that for brevity. I'm sorry for the confusion it caused. Just declare it with the proper iterator type.
"If you tell the truth, you don't have to remember anything"
-Mark Twain
I don't think there's any need to apologize. Everyone should learn C++0x sooner or later.
sorry about that... I got distracted while writing my reply, so in the time it took me to write my post, a bunch of other people (including you) posted to the forum, making nearly all of my points quite moot.
No problem. I figured it was something like that.
Anyway, I should start getting better at posting all relevant code when making a help request. Something I need to work on in my character. So your post was still helpful.
Thanks.
I'm an alien from another world. Planet Earth is only my vacation home, and I'm not liking it.
