Assigning the content of one map to another map and doing the same with vector

Ok, this is getting a little annoying...
After spending 2 hours debugging, I have successfully inserted all enumerators (both string names and their values) into a map<string, int> in my ConvertEnumToStrings program. The output of my program proves this. However, now what's happening is, when I get the map, the resulting map that I use in the int main() function has all mapped values set to 0 (even though the original member map of the CenumOperations class stored several different values). The size() is correct, but all values are set to 0. The same is true with the vector of enumerator values. The key value side of the map (i.e. "string") has the right values, but the mapped values are all 0.

Why would that be?

I'm thinking it has something to do with the assignment operator '=' of the std::map class failing to work right. Basically, how this works is:

1. A file containing an enum is passed to the program.
2. The complete enum (along with various elements, such as a vector of its enumerators string names, and a vector of its enumerators int values, as well as the map already mentioned) is stored in memory (internally inside of members of the CenumOperations class).
3. Now in int main(), I create an object of the class, call the CenumOperations::getEnumerationsMap() to retrieve the enumerations map. getEnumerationsMap returns a const map<string, int> reference to a copy of the original map (inside this function, the copy is assigned the content of the original, then the original map is cleared, and a reference to the copy is returned), i.e:

Code:

---

const map <string, int>& CenumOperations::getEnumeratorsMap() {

    enumeratorsMapCopy_m_si = enumeratorsMap_m_si; //get a copy of the enumerators map
    enumeratorsMap_m_si.clear(); //then clear the original
    return enumeratorsMapCopy_m_si; //and return a reference to the copy

}

---

Note that the enumerators map copy is also a member of the CenumOperations, same as the original map. Similiarly, the getEnumeratorValues() member function looks like this:

Code:

---

const vector <int>& CenumOperations::getEnumeratorValues() {

    enumeratorValuesCopy_v_i = enumeratorValues_v_i; //get a copy of the values of the enumerators
    enumeratorValues_v_i.clear(); //then clear the original
    return enumeratorValuesCopy_v_i; //and return a reference to the copy

}

---

Now, in int main(), what happens is, I create another map (and vector). I assign to the map the return value of getEnumeratorsMap(), and I assign to the vector the return value of getEnumeratorValues():

Code:

---

int main() {
  //do stuff...
  map <string, int> enumeratorsMap_m_si; //for storing a map of the enumerators
  vector <int> valuesOfEnumerators_v_i; //for storing the values of enumerators
  //do more stuff...
  enumeratorsMap_m_si = convertEnumToStringsObject.getEnumeratorsMap();
  //we now (actually, should...) have a map of both enumerator names and numerical values...BUT WE DON'T!! :D haha
  valuesOfEnumerators_v_i = convertEnumToStringsObject.getEnumeratorValues();
  //we now have a int vector of the values of the enumerators...or not :(
}

---

Note that the "convertEnumToStringsObject" is an object of a class that inherits from both the "CenumOperations" and "CfileOperations" classes, and has no members of its own.

So can anyone tell me why my program outputs this:

Quote:

---

gorilla@ubuntu:~/Documents/Programming/Completed_Programs/ConvertEnumToStrings/bin/Debug$ ./ConvertEnumToStrings "/home/gorilla/Documents/test.cpp" "results"
Thank you for running ConvertEnumToStrings.
This program will work with either C or C++ enums.
Before we begin converting enums to strings though,
please take note of the following points:

1. I did not provide support for invalid enums.
2. I also did not provide support for enums which
use variable names in any enumerator assignments.
You must use only const value numbers when you explicitly
assign an enumerator a value. The reason for this is, its
not possible to figure out the internal value of a variable.
3. The only exception to the last part of 2. is when
you specified the type of enum, and its a different
numerical type, such as a char. In this case, the program
will output the numerical representation of whatever char
has been assigned to a given enumerator. You are then free
to convert it back to a char if you want.
4. There are no other restrictions. The program should handle
all other kinds of enums.

Please press Enter to begin.


Thank you. We will now get the converting process underway...

currentEnumName_s is: DAY
We found an enumerator.
currentEnumeratorName_s is: sunday
enumeratorsCounter_ui is: 1
enumeratorsMap_m_si.find("sunday")->second is: 0
We found an enumerator.
We found an enumerator with an assigned value.
currentEnumeratorValue_i is: 0
currentEnumeratorName_s is: monday
currentEnumeratorHasAssignedValue_b is true.
enumeratorsMap_m_si.find("monday")->second is: 0
We found an enumerator.
currentEnumeratorName_s is: tuesday
The current enumerator is not the first and does not have an assigned value.
currentEnumeratorValue_i before incrementing: 0
currentEnumeratorValue_i after incrementing: 1
enumeratorsCounter_ui is: 3
enumeratorsMap_m_si.find("tuesday")->second is: 1
We found an enumerator.
currentEnumeratorName_s is: wednesday
The current enumerator is not the first and does not have an assigned value.
currentEnumeratorValue_i before incrementing: 1
currentEnumeratorValue_i after incrementing: 2
enumeratorsCounter_ui is: 4
enumeratorsMap_m_si.find("wednesday")->second is: 2
We found an enumerator.
currentEnumeratorName_s is: thursday
The current enumerator is not the first and does not have an assigned value.
currentEnumeratorValue_i before incrementing: 2
currentEnumeratorValue_i after incrementing: 3
enumeratorsCounter_ui is: 5
enumeratorsMap_m_si.find("thursday")->second is: 3
We found an enumerator.
currentEnumeratorName_s is: friday
The current enumerator is not the first and does not have an assigned value.
currentEnumeratorValue_i before incrementing: 3
currentEnumeratorValue_i after incrementing: 4
enumeratorsCounter_ui is: 6
enumeratorsMap_m_si.find("friday")->second is: 4
We found an enumerator.
currentEnumeratorName_s is: saturday
The current enumerator is not the first and does not have an assigned value.
currentEnumeratorValue_i before incrementing: 4
currentEnumeratorValue_i after incrementing: 5
enumeratorsCounter_ui is: 7
enumeratorsMap_m_si.find("saturday")->second is: 5
namesOfEnumerators_v_s.size() is: 7
valuesOfEnumerators_v_i.size() is: 7
enumeratorsMap_m_si.size() is: 7
numOfEnumerators_ui is: 7
We found a single-line enum.
currentEnumName_s is: AREYOUAROCK
We found an enumerator with an assigned value.
currentEnumeratorValue_i is: 1
currentEnumeratorName_s is: yes
currentEnumeratorHasAssignedValue_b is true.
enumeratorsMap_m_si.find("yes")->second is: 1
We're at the last enumerator of the single-line enum.
We found an enumerator that has an assigned value.
currentEnumeratorValue_i is: 0
currentEnumeratorHasAssignedValue_b is true.
enumeratorsMap_m_si.find("no")->second is: 0
namesOfEnumerators_v_s.size() is: 2
valuesOfEnumerators_v_i.size() is: 2
enumeratorsMap_m_si.size() is: 2
numOfEnumerators_ui is: 0
currentEnumName_s is: Work
We found an enumerator.
We found an enumerator with an assigned value.
currentEnumeratorValue_i is: 1
currentEnumeratorName_s is: hard
currentEnumeratorHasAssignedValue_b is true.
enumeratorsMap_m_si.find("hard")->second is: 1
We're at the last enumerator of the enum.
The last enumerator of the enum has an assigned value.
currentEnumeratorValue_s is: 2
currentEnumeratorValue_i is: 2
currentEnumeratorName_s is: lazy
currentEnumeratorHasAssignedValue_b is true.
enumeratorsMap_m_si.find("lazy")->second is: 2
namesOfEnumerators_v_s.size() is: 2
valuesOfEnumerators_v_i.size() is: 2
enumeratorsMap_m_si.size() is: 2
numOfEnumerators_ui is: 2
The current line with 'enum' has a comment.
currentEnumName_s is: weirdenum
We found an enumerator.
currentEnumeratorName_s is: weirdenum1
enumeratorsCounter_ui is: 1
enumeratorsMap_m_si.find("weirdenum1")->second is: 0
We found an enumerator.
We found an enumerator with an assigned value.
currentEnumeratorValue_i is: 2
currentEnumeratorName_s is: weirdenum2
currentEnumeratorHasAssignedValue_b is true.
enumeratorsMap_m_si.find("weirdenum2")->second is: 2
We're at the last enumerator of the enum.
The last enumerator of the enum has an assigned value.
currentEnumeratorValue_s is: 0
currentEnumeratorValue_i is: 0
currentEnumeratorName_s is: weirdenum3
currentEnumeratorHasAssignedValue_b is true.
enumeratorsMap_m_si.find("weirdenum3")->second is: 0
namesOfEnumerators_v_s.size() is: 3
valuesOfEnumerators_v_i.size() is: 3
enumeratorsMap_m_si.size() is: 3
numOfEnumerators_ui is: 3
4 enums were found.
They were successfully written to file.
Generated file can be found at: /home/gorilla/Documents/results.h

If you chose to write to a header file, then you
can include the header in your source file, and
call up a function to retrieve the names of all
the enumerations or a specific enumeration you choose.
Otherwise if you wrote to a source file, you will need
to put the implemention in the source file you wrote to.
The generated file provides the following functions inside
a class with the name of 'CnameofenumToStrings':

const vector<string>& getEnumeratorNames();
const vector<int>& getEnumeratorValues();
const string& getNameOfEnum();
const int& getNumOfEnumerators();
const map<string, int>& getEnumeratorsMap();
const string& getEnumeratorValue(nameofenum enumerator);

where 'nameofenum' is replaced with the actual name of the
enum you want to retrieve something from.

The function names are pretty self-explanatory:

getEnumeratorNames() obviously returns a reference
to a vector of the string names of the enumerators in
your enum.
getEnumeratorValues() returns a reference to a vector
of the int values of the enumerators in your enum.
getNameOfEnum() is provided in case you need to retrieve
the string name of the enum for some reason. It returns
a reference to a string.
getNumOfEnumerators() returns a reference to an int containing
the total number of enumerators found in the enum, in case
you need that for some reason.
getEnumeratorsMap() returns a reference to a map<string, int>
containing the string names and int values of the enumerators in an enum.
The int values can be either explicit or implicit, and the type of the enum does
not even have to be int. It can be some other intergal type, but
ConvertEnumToStrings will always return it in int form.
getEnumeratorValue(nameofenum enumerator) returns a
reference to a int containing the value of the enumerator
you passed in the parameter.

Congratulations, and feel free to use this program again anytime.


Press Enter to end this program.

---

Haha, I figured everyone would love the really long output... :D
Note that most of the output is debug output statements (and they demonstrate that I was able to get the actual enumerator values and insert them into the map, since calling find() on them after inserting returns the right values). I'll remove those before I'm done with the program.

I see you're still slaving away with this.
Unfortunately, I cannot exactly tell you what is wrong. The only thing I can not is the extremely unnecessary copies you're making before returning the map and vector.

Also, debug statements are pointless unless you're shopping your software to someone else. Use your debugger.
Better yet, post the smallest possible compilable example that demonstrates the problem.

Quote:

---

Originally Posted by Programmer_P

I'm thinking it has something to do with the assignment operator '=' of the std::map class failing to work right.

---

Doubt it. The assignment operator of a standard container has been used far more times and by far more programmers than any code you've written. Look for the bug elsewhere.

The code that you've shown, while it doesn't appear to have a bug in it, does look suspicious. If I call getEnumeratorsMap() more than once, I'm going to get an empty map the second time. That's not exactly intuitive for a 'get' operation.

Quote:

---

Originally Posted by Elysia

I see you're still slaving away with this.

---

lol...yeah, the map part of it turned out to be more difficult than expected. :)
(I told you I hated maps...)
But at least its almost working now.

Quote:

---

Unfortunately, I cannot exactly tell you what is wrong. The only thing I can not is the extremely unnecessary copies you're making before returning the map and vector.

---

Well, it may seem like unneccessary copies, but I do it that way since the function that operates on enums is supposed to return after only one enum is found. So there will be a call on operatedOnEnum() for each enum found in the file. Now for multiple enums in the file, if I didn't use copies, what would happen is there would already be content in both the vector and the map by at least the second call of the function, so I would only be adding elements to a non-empty map and vector.
But, come to think of it, I guess I could always check to see if they're empty at the start of the function, and clear them if they're not...

Quote:

---

Also, debug statements are pointless unless you're shopping your software to someone else. Use your debugger.

---

The debugger only helps with runtime errors (not logical errors), I think. I needed to find out what was actually happening. That is why I wrote the debug statements.

Quote:

---

Better yet, post the smallest possible compilable example that demonstrates the problem.

---

Code:

---

for (unsigned int i = 0; i < namesOfEnumerators_v_s.size(); i++) {
      output_s += "    enumeratorsMap.insert(make_pair(\"";
      output_s += namesOfEnumerators_v_s.at(i);
      output_s += "\", ";
      currentEnumeratorValue_i = enumeratorsMap_m_si.find(namesOfEnumerators_v_s.at(i))->second;
      currentEnumeratorValue_ss<< currentEnumeratorValue_i;
      currentEnumeratorValue_ss >> currentEnumeratorValue_s;
      output_s += currentEnumeratorValue_s;
      output_s += "));\n";
}

---

I'm thinking its adding 0s because the find() function is not finding what's being searched for, apparently because the map inside the int main is not the same as the original map. Anyway, I got rid of the copies, and am about to add a check to see if the find() funtion returned map::end() or not.

Quote:

---

Originally Posted by pianorain

Doubt it. The assignment operator of a standard container has been used far more times and by far more programmers than any code you've written. Look for the bug elsewhere.

The code that you've shown, while it doesn't appear to have a bug in it, does look suspicious. If I call getEnumeratorsMap() more than once, I'm going to get an empty map the second time. That's not exactly intuitive for a 'get' operation.

---

No, you wouldn't. Because both the function and both the maps being used are members of a class. If you call the function more than once from the same object, the content of the map will be the same so long as another call of operatedOnEnum() has not been made. And I call the function once for every call of operatedOnEnum() (if the function returned true that is). So the content of the map being retrieved should reflect the content of the original internal map of the class which contains the enum stuff. But it doesn't...
Anyway, like already mentioned though, I got rid of the copies and replaced them with a couple of checks inside operatedOnEnum() to see if the vector and map are not empty. If so, then I clear them both before the enum operations. Then I just return a reference to the original map from getEnumeratorsMap().

This is very pretty, but I still can't compile it. That's why I said smallest possible compilable example.
Cut down on parts of your source until the error disappears. Then post that small version. It doesn't have to do anything, it just has to reproduce that problem.
And of course the debugger helps you find logical errors. It does have step-by-step functionality and all that.
Boy, I managed to make a huge mistake (logic error; error in thinking) in my AI implementation. The wonderful debugger helped me find out what was wrong and it turned out it was an error in my thinking. That's pretty nice, isn't it?

What pianorain is trying to say is this:

Code:

---

CenumOperations myobj;
myobj.getEnumeratorValues(); // OK, we get a non-empty vector.
myobj.getEnumeratorValues(); // Problem! Vector returned is empty!

---

And you know there's a multi-quote button, yes?

Quote:

---

Originally Posted by Elysia

What pianorain is trying to say is this:

Code:

---

CenumOperations myobj;
myobj.getEnumeratorValues(); // OK, we get a non-empty vector.
myobj.getEnumeratorValues(); // Problem! Vector returned is empty!

---

---

And what I'm trying to say is this:

Code:

---

CenumOperations myobj;
myobj.getEnumeratorValues(); //Ok, we get a non-empty vector.
myobject.getEnumeratorValues(); //no problem! the vector returned is NOT empty!

---

Quote:

---

And you know there's a multi-quote button, yes?

---

Yeah, I know, but I sometimes forget about that button.

Those are two different objects. Call the function twice on the same object and you get a problem. Which sounds like a design flaw.

Quote:

---

Originally Posted by Elysia

Those are two different objects. Call the function twice on the same object and you get a problem. Which sounds like a design flaw.

---

Oops...that was a typo.
Anyway, obviously I know that the function wouldn't work if called twice on the same object with the second call before another call of operatedOnEnum(), but I was thinking along the lines of:

1. Call operatedOnEnum() to do operations on an enum.
2. Call getEnumeratorsMap() to get a map of the enum.
3. Call operatedOnEnum() to do operations on another enum (if there is one).
4. Call getEnumeratorsMap() to get a map of the new enum.

in which case the function would work perfectly fine like it was before (or more accurately, like it was supposed to before), since before the second function call of getEnumeratosMap(), the original enumeratorsMap would have the enumerators of the new enum inserted into it, then the map copy would be assigned the content of the new enumeratorsMap, hence why it would work. Anyhoo, I stopped using copies, and am now returning the original map, since I call map::clear() on the map before I begin enum operations in operatedOnEnum().

This sounds like unnecessary work. You generate whatever data you may need, preferably within the constructor and then utilize it. You never destroy what you've created. If I need to access the data multiple times, I should be able to call the function get it.
And if I need to start over, I would create a new object or tell it that I don't need the old data any longer.
A get function should never modify the object state.

Since the object in question is meant to be used internally rather than exposed for programmers to play with, it's only an issue if the OP cares. The posted code just didn't pass the smell test.

We still haven't seen any code that might help us help you.

Quote:

---

Originally Posted by Elysia

This sounds like unnecessary work. You generate whatever data you may need, preferably within the constructor and then utilize it.

---

I've considered doing that before (i.e. calling operatedOnEnum() inside the constructor), but decided against it. The reason is, since there might be more than one enum in the file, it makes sense to call the operatedOnEnum() function until the end of the file has been reached, and after each call, get the relevant stuff from the enum operations class. If I called operatedOnEnum() from inside the constructor, and it failed to find (and/or operate on) an enum, how would I let the outside world know about it? Constructors can't return values. I mean, I guess I could throw an exception or something, but the idea is to read the entire file, and store each enum it finds in data members of the class, and then retrieve it using public functions of the class.

Quote:

---

You never destroy what you've created.

---

Don't be so sure about that...what if you didn't like what you created? :p Then you might destroy it. haha. Obviously I'm not talking about programming in this instance.

Quote:

---

If I need to access the data multiple times, I should be able to call the function get it.

---

Well, now you can, since the getEnumeratorsMap() function and other similar functions have been improved.

Quote:

---

And if I need to start over, I would create a new object or tell it that I don't need the old data any longer.

---

Well, nothing says you can't create a new object of the enum class and start over.

Quote:

---

A get function should never modify the object state.

---

You're right, and its fixed now. What you're talking about here has already been changed. Its ancient history. :)

Quote:

---

Originally Posted by pianorain

Since the object in question is meant to be used internally rather than exposed for programmers to play with, it's only an issue if the OP cares.

---

Exactly. That's why I didn't see a problem with it before. Because the original enumerators map was never meant to be modified outside the class anyway. So returning a copy wasn't a problem. But anyway, I changed it for brevity.

Quote:

---

The posted code just didn't pass the smell test.

---

Don't you mean it didn't pass the sight test? ;)
AFAIK, your nose can't smell code.

Quote:

---

We still haven't seen any code that might help us help you.

---

You're right, and that's because I had to go to work, and didn't have time to work on it.

I'll try to post something in a minute if its still outputting 0s.

Ok, I pinpointed the problem:

Code:

---

for (unsigned int i = 0; i < namesOfEnumerators_v_s.size(); i++) {
      output_s += "    enumeratorsMap.insert(make_pair(\"";
      output_s += namesOfEnumerators_v_s.at(i);
      output_s += "\", ";
      map<string, int>::iterator it = enumeratorsMap_m_si.find(namesOfEnumerators_v_s.at(i));
      if (it == enumeratorsMap_m_si.end()) {
          cout<< "\"" << namesOfEnumerators_v_s.at(i) << "\" was not found in enumeratorsMap_m_si." <<endl;
      }

      else {
          currentEnumeratorValue_i = it->second;
          cout<< "In int main(), currentEnumeratorValue_i is: " << currentEnumeratorValue_i <<endl;
      }
      currentEnumeratorValue_ss<< currentEnumeratorValue_i;
      if (!currentEnumeratorValue_ss.good()) {
          cout<< "Not good..." <<endl;
          cout<< "Value was not added to stringstream." <<endl;
      }
      currentEnumeratorValue_ss >> currentEnumeratorValue_s;
      if (!currentEnumeratorValue_ss.good()) {
          cout<< "Not good..." <<endl;
          cout<< "Stringstream did not insert value into string." <<endl;
      }
      output_s += currentEnumeratorValue_s;
      output_s += "));\n";
}
output_s += "\n}\n\n";

---

Here is what the output shows now:

Quote:

---

currentEnumName_s is: DAY
We found an enumerator.
currentEnumeratorName_s is: sunday
enumeratorsCounter_ui is: 1
enumeratorsMap_m_si.find("sunday")->second is: 0
We found an enumerator.
We found an enumerator with an assigned value.
currentEnumeratorValue_i is: 0
currentEnumeratorName_s is: monday
currentEnumeratorHasAssignedValue_b is true.
enumeratorsMap_m_si.find("monday")->second is: 0
We found an enumerator.
currentEnumeratorName_s is: tuesday
The current enumerator is not the first and does not have an assigned value.
currentEnumeratorValue_i before incrementing: 0
currentEnumeratorValue_i after incrementing: 1
enumeratorsCounter_ui is: 3
enumeratorsMap_m_si.find("tuesday")->second is: 1
We found an enumerator.
currentEnumeratorName_s is: wednesday
The current enumerator is not the first and does not have an assigned value.
currentEnumeratorValue_i before incrementing: 1
currentEnumeratorValue_i after incrementing: 2
enumeratorsCounter_ui is: 4
enumeratorsMap_m_si.find("wednesday")->second is: 2
We found an enumerator.
currentEnumeratorName_s is: thursday
The current enumerator is not the first and does not have an assigned value.
currentEnumeratorValue_i before incrementing: 2
currentEnumeratorValue_i after incrementing: 3
enumeratorsCounter_ui is: 5
enumeratorsMap_m_si.find("thursday")->second is: 3
We found an enumerator.
currentEnumeratorName_s is: friday
The current enumerator is not the first and does not have an assigned value.
currentEnumeratorValue_i before incrementing: 3
currentEnumeratorValue_i after incrementing: 4
enumeratorsCounter_ui is: 6
enumeratorsMap_m_si.find("friday")->second is: 4
We found an enumerator.
currentEnumeratorName_s is: saturday
The current enumerator is not the first and does not have an assigned value.
currentEnumeratorValue_i before incrementing: 4
currentEnumeratorValue_i after incrementing: 5
enumeratorsCounter_ui is: 7
enumeratorsMap_m_si.find("saturday")->second is: 5
namesOfEnumerators_v_s.size() is: 7
valuesOfEnumerators_v_i.size() is: 7
enumeratorsMap_m_si.size() is: 7
numOfEnumerators_ui is: 7
In int main(), currentEnumeratorValue_i is: 0
Not good...
Value was not added to stringstream.
Not good...
Stringstream did not insert value into string.
In int main(), currentEnumeratorValue_i is: 0
Not good...
Value was not added to stringstream.
Not good...
Stringstream did not insert value into string.
In int main(), currentEnumeratorValue_i is: 1
Not good...
Value was not added to stringstream.
Not good...
Stringstream did not insert value into string.
In int main(), currentEnumeratorValue_i is: 2
Not good...
Value was not added to stringstream.
Not good...
Stringstream did not insert value into string.
In int main(), currentEnumeratorValue_i is: 3
Not good...
Value was not added to stringstream.
Not good...
Stringstream did not insert value into string.
In int main(), currentEnumeratorValue_i is: 4
Not good...
Value was not added to stringstream.
Not good...
Stringstream did not insert value into string.
In int main(), currentEnumeratorValue_i is: 5
Not good...
Value was not added to stringstream.
Not good...
Stringstream did not insert value into string.
We found a single-line enum.
currentEnumName_s is: AREYOUAROCK
We found an enumerator with an assigned value.
currentEnumeratorValue_i is: 1
currentEnumeratorName_s is: yes
currentEnumeratorHasAssignedValue_b is true.
enumeratorsMap_m_si.find("yes")->second is: 1
We're at the last enumerator of the single-line enum.
We found an enumerator that has an assigned value.
currentEnumeratorValue_i is: 0
currentEnumeratorHasAssignedValue_b is true.
enumeratorsMap_m_si.find("no")->second is: 0
namesOfEnumerators_v_s.size() is: 2
valuesOfEnumerators_v_i.size() is: 2
enumeratorsMap_m_si.size() is: 2
numOfEnumerators_ui is: 7
In int main(), currentEnumeratorValue_i is: 1
Not good...
Value was not added to stringstream.
Not good...
Stringstream did not insert value into string.
In int main(), currentEnumeratorValue_i is: 0
Not good...
Value was not added to stringstream.
Not good...
Stringstream did not insert value into string.
currentEnumName_s is: Work
We found an enumerator.
We found an enumerator with an assigned value.
currentEnumeratorValue_i is: 1
currentEnumeratorName_s is: hard
currentEnumeratorHasAssignedValue_b is true.
enumeratorsMap_m_si.find("hard")->second is: 1
We're at the last enumerator of the enum.
The last enumerator of the enum has an assigned value.
currentEnumeratorValue_s is: 2
currentEnumeratorValue_i is: 2
currentEnumeratorName_s is: lazy
currentEnumeratorHasAssignedValue_b is true.
enumeratorsMap_m_si.find("lazy")->second is: 2
namesOfEnumerators_v_s.size() is: 2
valuesOfEnumerators_v_i.size() is: 2
enumeratorsMap_m_si.size() is: 2
numOfEnumerators_ui is: 2
In int main(), currentEnumeratorValue_i is: 1
Not good...
Value was not added to stringstream.
Not good...
Stringstream did not insert value into string.
In int main(), currentEnumeratorValue_i is: 2
Not good...
Value was not added to stringstream.
Not good...
Stringstream did not insert value into string.
The current line with 'enum' has a comment.
currentEnumName_s is: weirdenum
We found an enumerator.
currentEnumeratorName_s is: weirdenum1
enumeratorsCounter_ui is: 1
enumeratorsMap_m_si.find("weirdenum1")->second is: 0
We found an enumerator.
We found an enumerator with an assigned value.
currentEnumeratorValue_i is: 2
currentEnumeratorName_s is: weirdenum2
currentEnumeratorHasAssignedValue_b is true.
enumeratorsMap_m_si.find("weirdenum2")->second is: 2
We're at the last enumerator of the enum.
The last enumerator of the enum has an assigned value.
currentEnumeratorValue_s is: 0
currentEnumeratorValue_i is: 0
currentEnumeratorName_s is: weirdenum3
currentEnumeratorHasAssignedValue_b is true.
enumeratorsMap_m_si.find("weirdenum3")->second is: 0
namesOfEnumerators_v_s.size() is: 3
valuesOfEnumerators_v_i.size() is: 3
enumeratorsMap_m_si.size() is: 3
numOfEnumerators_ui is: 3
In int main(), currentEnumeratorValue_i is: 0
Not good...
Value was not added to stringstream.
Not good...
Stringstream did not insert value into string.
In int main(), currentEnumeratorValue_i is: 2
Not good...
Value was not added to stringstream.
Not good...
Stringstream did not insert value into string.
In int main(), currentEnumeratorValue_i is: 0
Not good...
Value was not added to stringstream.
Not good...
Stringstream did not insert value into string.

---

So, its clear the stringstream operations are failing for some reason. That is why all the enumerator values are 0 when they're outputted to file.

Quote:

---

Originally Posted by Programmer_P

Don't you mean it didn't pass the sight test? ;)
AFAIK, your nose can't smell code.

---

Code smell - Wikipedia, the free encyclopedia

Quote:

---

Originally Posted by Programmer_P

Ok, I pinpointed the problem: So, its clear the stringstream operations are failing for some reason. That is why all the enumerator values are 0 when they're outputted to file.

---

Yes, that's clear. However, you still haven't given us any code with which we can help you. Why not try something like this:

Code:

---

{//local stringstream instead of...whatever scope it's at now.
  std::stringstream currentEnumeratorValue_ss;
  currentEnumeratorValue_ss << currentEnumeratorValue_i;
  if (!currentEnumeratorValue_ss.good()) {
      cout<< "Not good..." <<endl;
      cout<< "Value was not added to stringstream." <<endl;
  }
  //use .get() to get the string
  currentEnumeratorValue_s = currentEnumeratorValue_ss.get();
  if (!currentEnumeratorValue_ss.good()) {
      cout<< "Not good..." <<endl;
      cout<< "Stringstream did not insert value into string." <<endl;
  }
}
output_s += currentEnumeratorValue_s;

---

Quote:

---

Originally Posted by pianorain

Code smell - Wikipedia, the free encyclopedia

---

Oh wow...I didn't know there is a programming term called "code smell". Thanks for the link. :)

Quote:

---

Yes, that's clear. However, you still haven't given us any code with which we can help you. Why not try something like this:

Code:

---

{//local stringstream instead of...whatever scope it's at now.
  std::stringstream currentEnumeratorValue_ss;
  currentEnumeratorValue_ss << currentEnumeratorValue_i;
  if (!currentEnumeratorValue_ss.good()) {
      cout<< "Not good..." <<endl;
      cout<< "Value was not added to stringstream." <<endl;
  }
  //use .get() to get the string
  currentEnumeratorValue_s = currentEnumeratorValue_ss.get();
  if (!currentEnumeratorValue_ss.good()) {
      cout<< "Not good..." <<endl;
      cout<< "Stringstream did not insert value into string." <<endl;
  }
}
output_s += currentEnumeratorValue_s;

---

---

Using stringstream::get() didn't work either. It still failed at both inserting the int value of the enumerator into the stringstream, and outputting it to a string.

Should I be creating a new stringstream object each time I need one, instead of trying to use one object for all conversions of int to string? Also, do i need to pass anything to the stringstream's constructor, or is it ok to declare a stringstream like this:

Code:

---

stringstream currentEnumeratorValue_ss; //for converting the current enumerator value from an int to a string

---

And then use the << operator right away to insert values into it. Because that's what I'm currently doing.

Quote:

---

Originally Posted by Programmer_P

Using stringstream::get() didn't work either. It still failed at both inserting the int value of the enumerator into the stringstream, and outputting it to a string.

---

I'm willing to bet that your stringstream isn't good even before your first integer insertion. You should check.

Quote:

---

Originally Posted by Programmer_P

Should I be creating a new stringstream object each time I need one, instead of trying to use one object for all conversions of int to string?

---

You can reuse the same one over and over:

Code:

---

#include <sstream>
#include <iostream>
#include <string>

int main()
{
  std::stringstream s;
  for(int i = 0; i < 5; i++)
  {
      if(!s.good())
      {
        std::cout << "Not good - pre-insert" << std::endl;
      }

      s << i;
      if(!s.good())
      {
        std::cout << "Not good - post-insert" << std::endl;
      }

      std::string output = s.str();
      if(!s.good())
      {
        std::cout << "Not good - post-get()" << std::endl;
      }
      std::cout << output << std::endl;
      s.str(""); //clear the stringstream buffer
  }

  return 0;
}

---

Quote:

---

Originally Posted by pianorain

I'm willing to bet that your stringstream isn't good even before your first integer insertion. You should check.

---

You were correct. It wasn't good before the first integer insertion dealing with the map.
An error bit must have been set probably before that in the code, possibly when dealing with the enumerator values vector...

Quote:

---

Originally Posted by pianorain

s.str(""); //clear the stringstream buffer

---

If I remember correctly, you may also need to s.clear(); so as to reset any error flags the stringstream might be in. Personally, I think it is simpler to make the stringstream local to such a loop, unless due to performance reasons it turns out that you really need to pull it out of the loop.

Quote:

---

Originally Posted by laserlight

If I remember correctly, you may also need to s.clear(); so as to reset any error flags the stringstream might be in. Personally, I think it is simpler to make the stringstream local to such a loop, unless due to performance reasons it turns out that you really need to pull it out of the loop.

---

You are correct; you should s.clear() if you're going to reuse the stringstream. I'd also prefer to make the stringstream local; keep the code simple until it's finished, then optimize where you need it.

Yep, this is where it first failed:

Code:

---

for (unsigned int i = 0; i < valuesOfEnumerators_v_i.size(); i++) {
      currentEnumeratorValue_i = valuesOfEnumerators_v_i.at(i); //get the current enumerator's value
      currentEnumeratorValue_ss<< currentEnumeratorValue_i;
      if (!currentEnumeratorValue_ss.good()) {
          cout<< "stringstream is no longer good. It failed when I attempted to insert an int into it.\n"
                      "We're at element " << i << " of the vector, which is: "
                << valuesOfEnumerators_v_i.at(i) <<endl;
      }
      currentEnumeratorValue_ss>> currentEnumeratorValue_s;
      output_s += "    enumeratorValues.push_back(";
      output_s += currentEnumeratorValue_s; //add it to the output string
      output_s += ");\n";
}

---

Relevant output:

Quote:

---

stringstream is no longer good. It failed when I attempted to insert an int into it.
We're at element 1 of the vector, which is: 0
stringstream is no longer good. It failed when I attempted to insert an int into it.
We're at element 2 of the vector, which is: 1
stringstream is no longer good. It failed when I attempted to insert an int into it.
We're at element 3 of the vector, which is: 2
stringstream is no longer good. It failed when I attempted to insert an int into it.
We're at element 4 of the vector, which is: 3
stringstream is no longer good. It failed when I attempted to insert an int into it.
We're at element 5 of the vector, which is: 4
stringstream is no longer good. It failed when I attempted to insert an int into it.
We're at element 6 of the vector, which is: 5

---

EDIT: Ok, so it fails at the second element of the vector of some reason (which is a 0).

Does the stringstream not like it when a 0 is inserted into it?
But that doesn't make any sense, since the first element of the vector was a 0 too, and that worked, while the second one failed...
Oh, maybe its because I need to clear the stringstream after using it for each iteration of the loop.

Would you mind humoring me and checking to see if the stringstream is good after you use operator>>? I'm willing to bet it's not.

Oh yeah... :D
Perfect. It works now.
Bout' time...
Seriously though, I don't get why a stringstream object wont overwrite any existing content when you use the << operator.

Why should it magically clear()? You can append stuff to streams. It happens all the time with files... and cout...

Quote:

---

Originally Posted by pianorain

Would you mind humoring me and checking to see if the stringstream is good after you use operator>>? I'm willing to bet it's not.

---

Yeah, its still good. The problem was apparently the stringstream << operator either does not handle well when you attempt to insert a value that already exists in the stream, and/or it it does not handle inserting into a stream which already has something in it.

Either way, the problem is solved now.

Thanks everyone. :)

Quote:

---

Originally Posted by whiteflags

Why should it magically clear()? You can append stuff to streams. It happens all the time with files... and cout...

---

I thought cout outputs whatever argument was passed to its parameter, and then clears itself.

An output like this:

Code:

---

int num = 10;
cout<< "You suck this amount of times: "  << num << endl;

---

I thought would first output the string, clear itself, output the number, clear itself, and then finally output the endl and clear itself. If it appends it, then why does using later cout statements without explicitly clearing the stream only output the new arguments being passed to cout?

Quote:

---

Originally Posted by Programmer_P

Yeah, its still good. The problem was apparently the stringstream << operator either does not handle well when you attempt to insert a value that already exists in the stream, and/or it it does not handle inserting into a stream which already has something in it.

---

That doesn't seem right.

Code:

---

#include <sstream>
#include <iostream>
#include <string>

int main()
{
  std::stringstream s;
  for(int i = 0; i < 5; i++)
  {
      if(!s.good())
      {
        std::cout << "Not good - pre-insert" << std::endl;
      }

      s << 0;
      if(!s.good())
      {
        std::cout << "Not good - post-insert" << std::endl;
      }

      std::string output = s.str();
      if(!s.good())
      {
        std::cout << "Not good - post-get()" << std::endl;
      }
      std::cout << output << std::endl;
  }

  return 0;
}

---

The output is:

Code:

---

0
00
000
0000
00000

---

As you can see, it has both a repeated value and adding to a non-empty stringstream.

Quote:

---

Originally Posted by pianorain

That doesn't seem right.

Code:

---

#include <sstream>
#include <iostream>
#include <string>

int main()
{
  std::stringstream s;
  for(int i = 0; i < 5; i++)
  {
      if(!s.good())
      {
        std::cout << "Not good - pre-insert" << std::endl;
      }

      s << 0;
      if(!s.good())
      {
        std::cout << "Not good - post-insert" << std::endl;
      }

      std::string output = s.str();
      if(!s.good())
      {
        std::cout << "Not good - post-get()" << std::endl;
      }
      std::cout << output << std::endl;
  }

  return 0;
}

---

The output is:

Code:

---

0
00
000
0000
00000

---

As you can see, it has both a repeated value and adding to a non-empty stringstream.

---

Maybe its a compiler specific issue then? I'm using GCC. What compiler are you using?
I'm about to try to compile your code in my compiler and see if I get the same results.

At any rate, clearing the stringstream after each operation in the loops fixed the problem (note that I call clear() after using both the << and >> operators). I don't know why, but it did.

EDIT: Hmm...I got the same results you did.

Hmm...weird. It did become "not good" after inserting into a string from the stringstream, but it didn't do so with inserting an int into the stringstream. The statement I made earlier about checking to see if it was good() after using the operator >> wasn't exactly true, come to find out. I was checking it in one block of code, I think, but I wasn't checking it everywhere. I changed the code to check to see if stringstream::good() returned false after inserting into a string, and it did (apparently in all cases too). The weird thing is, even though, some error bit (not sure which one) was set to true, the "currentEnumeratorValue_s" string still ended up with the right value, so it outputted the right thing to file.

EDIT: I'm thinking it was probably the "badbit". I'm going to change the code to use the bad() function instead, and see if I'm right.

Nope. Its not the badbit. It must be either failbit or eofbit.

EDIT: Its eofbit. I guess you can't use >> when the eofbit has been set. clear() resets those flags, which is why it worked.

Quote:

---

Originally Posted by Programmer_P

Maybe its a compiler specific issue then? I'm using GCC. What compiler are you using?
I'm about to try to compile your code in my compiler and see if I get the same results.

At any rate, clearing the stringstream after each operation in the loops fixed the problem (note that I call clear() after using both the << and >> operators). I don't know why, but it did.

EDIT: Hmm...I got the same results you did.

---

It's not that something is wrong with the compiler or the streams you are using. In fact, pianorain's program is doing what it is supposed to do. I believe he is trying to point out your misuse, and your willingness to blame it on external factors, in a passive agressive way.

The problem is you, not your tools.

Quote:

---

Originally Posted by Programmer_P

I thought cout outputs whatever argument was passed to its parameter, and then clears itself.

An output like this:

Code:

---

int num = 10;
cout<< "You suck this amount of times: "  << num << endl;

---

I thought would first output the string, clear itself, output the number, clear itself, and then finally output the endl and clear itself. If it appends it, then why does using later cout statements without explicitly clearing the stream only output the new arguments being passed to cout?

---

I will try to make sense of the madness.

Specifically, there are two kinds of streams: sources, and sinks. Sources are the kind of stream that have all the data you ever need, you just have to extract from it. Sinks can take anything in and put it somewhere else, like how water is the universal solvent and flows to the oceans, or tap water to the sewers. An example of a sink stream is cout.

cout itself has a default way of operating. It will print your lines at once, because it is line buffered. This means that you can break up a long cout statement however you want, but cout will be as big as it needs to be to hold a single line. To display the line, you flush it with endl;

cout << "My rage burns with the power of " << 1000000L << " suns!" << endl;

But the point is, now we know the terms sink and source. A stringstream can be used either way. When you use it as a source, you're usually not happy with the stream's state because you forget what the stream already has: what you put into it when it was acting like a sink.

Every character is important to the stream. Either you will extract everything and set the stream pointer to indicate a state of emptiness though the interface (operator>>), or you will discard the stream itself and... set the stream pointer to indicate emptiness, through the interface (e.g. clear() ).

My conclusion is, you need to find a default way of operating, like cout, yourself. Maybe you can parse smarter so that it is impossible to be confused like you are in this thread. After all, enums have a defined syntax. There are a number of quick fixes, like clearing exactly where you need to, but I think you need to give real attention to the algorithm.

I mean, I sort of get what it takes to parse an enum:

Find and store an enum keyword.
Find and store an optional identifier.
Counted the opening brace.
Recursively parse the constant=value, expression
Balance the closing brace.
Find a sequence point ( ';' ).

If you put a whole enum into a stringstream, expect to take all of it back out. Or divide it into parts elsewhere, and feed that to a string stream, and take it back out.

Quote:

---

Originally Posted by whiteflags

It's not that something is wrong with the compiler or the streams you are using. In fact, pianorain's program is doing what it is supposed to do. I believe he is trying to point out your misuse, and your willingness to blame it on external factors, in a passive agressive way.

The problem is you, not your tools.

---

Wow! :D This post made me crack up and laugh.
No offense intended.

Quote:

---

I will try to make sense of the madness.

Specifically, there are two kinds of streams: sources, and sinks. Sources are the kind of stream that have all the data you ever need, you just have to extract from it. Sinks can take anything in and put it somewhere else, like how water is the universal solvent and flows to the oceans, or tap water to the sewers. An example of a sink stream is cout.

cout itself has a default way of operating. It will print your lines at once, because it is line buffered. This means that you can break up a long cout statement however you want, but cout will be as big as it needs to be to hold a single line. To display the line, you flush it with endl;

cout << "My rage burns with the power of " << 1000000L << " suns!" << endl;

---

I LOLed when I read this comment in particular. Its even funnier because I have actually felt that way before...

Quote:

---

But the point is, now we know the terms sink and source. A stringstream can be used either way. When you use it as a source, you're usually not happy with the stream's state because you forget what the stream already has: what you put into it when it was acting like a sink.

Every character is important to the stream. Either you will extract everything and set the stream pointer to indicate a state of emptiness though the interface (operator>>), or you will discard the stream itself and... set the stream pointer to indicate emptiness, through the interface (e.g. clear() ).

My conclusion is, you need to find a default way of operating, like cout, yourself. Maybe you can parse smarter so that it is impossible to be confused like you are in this thread. After all, enums have a defined syntax. There are a number of quick fixes, like clearing exactly where you need to, but I think you need to give real attention to the algorithm.

I mean, I sort of get what it takes to parse an enum:

Find and store an enum keyword.
Find and store an optional identifier.
Counted the opening brace.
Recursively parse the constant=value, expression
Balance the closing brace.
Find a sequence point ( ';' ).

---

My algorithm does it a little differently, but I wont get into exactly how it works here. If you're interested, feel free to check out the code once I post the next version of ConvertEnumToStrings. And I'm not confused. As a matter of fact, the program is working now.

Quote:

---

If you put a whole enum into a stringstream, expect to take all of it back out. Or divide it into parts elsewhere, and feed that to a string stream, and take it back out.

---

I don't put the whole enum into a stringstream. :) Instead, I put each enumerator value of an enum into a stringstream, since I need to convert it to a string so I can add it to the output string. And yes, of course I take it back out of the stringstream. Otherwise, there wouldn't be any point of putting them in the stringstream to begin with. :p

Quote:

---

And I'm not confused.

---

I giggle every time I read that.

Soma

Quote:

---

Originally Posted by phantomotap

I giggle every time I read that.

Soma

---

Keep giggling like a little girl then. :)
Hell, I crack myself up all the time. What do I care if other people laugh at me too?

I intend to... as long as it is funny.

Soma

Quote:

---

Originally Posted by Programmer_P

Wow! :D This post made me crack up and laugh.
No offense intended.

I LOLed when I read this comment in particular. Its even funnier because I have actually felt that way before...

---

It's good that you can laugh at yourself, and stuff. :)

Quote:

---

My algorithm does it a little differently, but I wont get into how exactly it works here. If you're interested, feel free to check out the code once I post the next version of ConvertEnumToStrings. And I'm not confused. As a matter of fact, the program is working now.

I don't put the whole enum into a stringstream. :) Instead, I put each enumerator value of an enum into a stringstream, since I need to convert it to a string so I can add it to the output string. And yes, of course I take it back out of the stringstream. Otherwise, there wouldn't be any point of putting them in the stringstream to begin with. :p

---

Not to get abrasive, but knowing how your algorithm works is not my goal. We need to stick to defined teacher-pupil roles.

Just because your program works, does not mean my point is less lost on you. It would be my fault if it was, for I have not explained clearly. It would probably be your fault to, if you didn't make an effort to understand. Now if you know why your program works, you'll have an easier time finding the root of the next mistake.

I think, though you wont acknowledge, that you understand how stringstreams work now?

Quote:

---

Originally Posted by whiteflags

\Now if you know why your program works, you'll have an easier time finding the root of the next mistake.

I think, though you wont acknowledge, that you understand how stringstreams work now?

---

Yes, I know why my program works now. :)
Its because I call clear() on the stringstream every time I'm done with it, so next time I use it, I have a fresh start with it. I don't really need to know the fine details of the "why" and "how" it works, so long as I remember that I need to call clear() on any other stringstream that I make in the future, so I wont make the same mistake again.

And yes, I understand how stringstreams work now, even though I still think its kind of lame that the << operator appends to existing data instead of replaces. For appending, a better operator to use would be the "+=" operator. That way its more clearer that its appending.

Quote:

---

Originally Posted by Programmer_P

And yes, I understand how stringstreams work now, even though I still think its kind of lame that the << operator appends to existing data instead of replaces. For appending, a better operator to use would be the "+=" operator. That way its more clearer that its appending.

---

Choice of operators to overload can sometimes be rather subjective. In fact, I have read a piece critical of the overloading of operator>> and operator<< for input/output streams for this very reason.

If you are familiar with code that chains operators like this:

Code:

---

std::string name("Programmer_P");
std::cout << "Hello " << name;

---

then it should be natural to accept that operator<< is overloaded to append, not replace, since you would know that after "Hello " is printed, "Programmer_P" is then appended to the output. If we use your suggestion, it would then be:

Code:

---

std::cout += "Hello " += name;

---

This could work too, since it is a matter of interpretation, though care would have to be paid concerning the change in precedence.

Quote:

---

I still think its kind of lame that the << operator appends to existing data instead of replaces.

---

The standard streams are designed with "OOP" in mind as a representation of stream devices. (This as opposed to block devices.) They can't "replace" by definition.

Quote:

---

For appending, a better operator to use would be the "+=" operator.

---

What would you use for "extraction" if you had used "+=" as "insertion"? I'm here to tell you that "-=" would be incredibly stupid.

Quote:

---

In fact, I have read a piece critical of the overloading of operator>> and operator<< for input/output streams for this very reason.

---

It is not as subjective as people would like to believe. The only operators with parity that logically maintain the "read order" in processing are the "stream operators" ("<<" and ">>"). (I'm ignoring the possibility of overloading the comparison operators for this purpose because we still may need to compare the result of such chaining.)

Quote:

---

This could work too, since it is a matter of interpretation, though care would have to be paid concerning the change in precedence.

---

WTF!?

It could not work. You could not "chain" the operators. It is not an issue of precedence. It is an issue of associativity. And wrapping the expression in countless parentheses doesn't count!

Soma

Code:

---

struct test1_1
{
};

struct test1_2
{
};

struct test2_1
{
};

struct test2_2
{
};

#include <iostream>

test1_1 & operator +=
(
  test1_1 & fLHS
 , const test1_2 & fRHS
)
{
  std::cout << "test1_1 & operator += (const test1_1 &, const test1_2 &)" << '\n';
  return(fLHS);
}

test1_2 & operator +=
(
  test1_2 & fLHS
 , const test1_2 & fRHS
)
{
  std::cout << "test1_2 & operator += (const test1_2 &, const test1_2 &)" << '\n';
  return(fLHS);
}

test2_1 & operator <<
(
  test2_1 & fLHS
 , const test2_2 & fRHS
)
{
  std::cout << "test2_1 & operator << (const test2_1 &, const test2_2 &)" << '\n';
  return(fLHS);
}

test2_2 & operator <<
(
  test2_2 & fLHS
 , const test2_2 & fRHS
)
{
  std::cout << "test2_2 & operator << (const test2_2 &, const test2_2 &)" << '\n';
  return(fLHS);
}

int main
(
  int argc
 , char ** argv
)
{
  test1_1 t1_1;
  test1_2 t1_2;
  test2_1 t2_1;
  test2_2 t2_2;
  t1_1 += t1_2 += t1_2;
  t2_1 << t2_2 << t2_2;
  return(0);
}

---

Quote:

---

Originally Posted by phantomotap

WTF!?

---

omgwtfbbq!?

Quote:

---

Originally Posted by phantomotap

It could not work. You could not "chain" the operators. It is not an issue of precedence. It is an issue of associativity.

---

That's true. Precedence is an issue, but I did not notice the more pertinent issue.

Quote:

---

Originally Posted by phantomotap

And wrapping the expression in countless parentheses doesn't count!

---

Of course it does, if you're a masochist.

Quote:

---

omgwtfbbq!?

---

IANRIILUTAFTPOTDBITFYA!?

Quote:

---

Of course it does, if you're a masochist.

---

Don't be stupid; if the programmer were a masochist they'd be using Java.

Soma

Programmer_P: WTF! (Always wanted to say that.)
There are some points you just seem to fail to understand.
First of all: a stringstream is just like your vanilla file streams or console streams or whatever you want to call them. You don't see...

Code:

---

std::cout << "Hello" << "World";

---

...only printing out "World", do you? Then why do you expect stringstreams to do that?

Second point.
You need to understand how stringstreams work, not just, "oh I've seen this scenario before; do this and it's fixed." You don't have a clear view of what the actual problem is, and that is by all definitions, bad. You must understand that streams are bastards in many ways. If they fail, they will just silently fail to do anything else. You need to check if a problem occurred, and if so, fix it. If the stream failed for some reason, it usually means that whatever you parsed is wrong. Or you parsed it wrong. If it cannot convert from type X to type Y for some reason, it will fail. Keep this in mind. The clear member function clears the error flags and allows the stream to continue to do work.

Third point.
If there is an error, fail or recover. Don't silently ignore it. For simple code, all you can do is just throw an exception or put an assert. But don't ignore it altogether. This will just cause you headaches.

Fourth point.
Why couldn't you just put the damn debugger into the parsing routine and do a step-by-step instead of putting out a lot of verbose, useless debug information? Why was it so extremely difficult to do this!?!

Fifth point.
There is an edit button Use it.

Sixth point.
There is a multi-quote button. Use it.

Quote:

---

Originally Posted by Elysia

Programmer_P: WTF! (Always wanted to say that.)
There are some points you just seem to fail to understand.
First of all: a stringstream is just like your vanilla file streams or console streams or whatever you want to call them. You don't see...

Code:

---

std::cout << "Hello" << "World";

---

...only printing out "World", do you? Then why do you expect stringstreams to do that?

---

Because with stringstream, I'm dealing with a stringstream variable and I'm doing this:

Code:

---

ss<< i;

---

not:

Code:

---

ss<< i << i2;

---

As for cout, I didn't know it appended. I thought it outputted each argument after << then cleared itself, in which case your line of code would still output both "Hello" and "World".

Quote:

---

Second point.
You need to understand how stringstreams work, not just, "oh I've seen this scenario before; do this and it's fixed." You don't have a clear view of what the actual problem is, and that is by all definitions, bad. You must understand that streams are bastards in many ways. If they fail, they will just silently fail to do anything else. You need to check if a problem occurred, and if so, fix it. If the stream failed for some reason, it usually means that whatever you parsed is wrong. Or you parsed it wrong. If it cannot convert from type X to type Y for some reason, it will fail. Keep this in mind. The clear member function clears the error flags and allows the stream to continue to do work.
Third point.
If there is an error, fail or recover. Don't silently ignore it. For simple code, all you can do is just throw an exception or put an assert. But don't ignore it altogether. This will just cause you headaches.

---

Well, in this case, the problem was the "eofbit" was being set. Neither "badbit" or "failbit" were set, so I didn't see a need to output anything, or fail. I just cleared it and moved on. I guess I could do something like this though:

Code:

---

for (unsigned int i = 0; i < valuesOfEnumerators_v_i.size(); i++) {
      currentEnumeratorValue_i = valuesOfEnumerators_v_i.at(i); //get the current enumerator's value
      currentEnumeratorValue_ss<< currentEnumeratorValue_i;
      if (!currentEnumeratorValue_ss.good()) {
          if (currentEnumeratorValue_ss.bad()) {
              cout<< "Error! Badbit was set on stringstream input operation.\n"
                          "Failing..." <<endl;
              return 1;
          }

          else if (currentEnumeratorValue_ss.fail()) {
              cout<< "Error! Failbit was set on stringstream input operation.\n"
                          "Failing..." <<endl;
              return 1;
          }

        else if (currentEnumeratorValue_ss.eof()) {
              cout<< "Error! eofbit was set on stringstream input operation.\n"
                          "Recovering..." <<endl;
              }
        }

        currentEnumeratorValue_ss>> currentEnumeratorValue_s;
        if (!currentEnumeratorValue_ss.good()) {
            if (currentEnumeratorValue_ss.bad()) {
                cout<< "Error! Badbit was set on stringstream output operation.\n"
                            "Failing..." <<endl;
                return 1;
            }

            else if (currentEnumeratorValue_ss.fail()) {
                  cout<< "Error! Failbit was set on stringstream output operation.\n"
                              "Failing..." <<endl;
                  return 1;
            }

            else if (currentEnumeratorValue_ss.eof()) {
                  cout<< "WTF?! eofbit was set on stringstream output operation.\n"
                              "Recovering..." <<endl;
              }
        }
        output_s += "    enumeratorValues.push_back(";
        output_s += currentEnumeratorValue_s; //add it to the output string
        currentEnumeratorValue_ss.clear();
        currentEnumeratorValue_s.clear();
        output_s += ");\n";
}

---

Quote:

---

Fourth point.
Why couldn't you just put the damn debugger into the parsing routine and do a step-by-step instead of putting out a lot of verbose, useless debug information? Why was it so extremely difficult to do this!?!

---

The thing is, I didn't want to use my debugger. :) I wanted to waste my time "putting out a lot of verbose, useless debug information" just so I could annoy you. And it worked... :p

Quote:

---

Fifth point.
There is an edit button Use it.

---

I use it all the time. That's why you see lots of posts with "Last edited by Programmer_P;"...

Quote:

---

Sixth point.
There is a multi-quote button. Use it.

---

I know there is a multi-quote button. But sometimes I forget about it. Anyway, I don't see what the big deal is. :D Why are you so into multi-quote buttons?

Quote:

---

Originally Posted by Programmer_P

Well, in this case, the problem was the "eofbit" was being set. Neither "badbit" or "failbit" were set, so I didn't see a need to output anything, or fail. I just cleared it and moved on. I guess I could do something like this though:

---

Or you could just do

Code:

---

for (unsigned int i = 0; i < valuesOfEnumerators_v_i.size(); i++)
{
    try
    {
        EnumValue = EmumVec.at(i);
        if (! (EnumStream << EnumValue)) throw std::exception("Unable to parse input.");
        if (! (EnumStream >> EnumStr)) throw std::exception("Unable to extract input.");
    }
    catch (const std::exception& e)
    {
        std::cout << e.what() << "\nBits: eof: " << EnumStream.eof() << " bad: " << EnumStream.bad() << " fail: " << EnumStream.fail() << std::endl;
    }
}

---

Simple, short, yet concise and gets the work done.

Quote:

---

The thing is, I didn't want to use my debugger. :) I wanted to waste my time putting out a lot of verbose, useless debug information, just so I could annoy you. And it worked... :p

---

True, and you wasted lots of time yourself.

Quote:

---

I use it all the time. That's why you see lots of posts with "Last edited by Programmer_P;"...

---

But apparently you favor multiple posts when finding something new to add instead of merging them into one post.

Quote:

---

I know there is a multi-quote button. But sometimes I forget about it. Anyway, I don't see what the big deal is. :D Why are you so into multi-quote buttons?

---

Maybe you should work on finding if it exists? The problem is that you double and triple post. A lot.
Such things are frowned upon. I guess it isn't long now until you're going to quadraple post.

Quote:

---

Originally Posted by whiteflags

It's not that something is wrong with the compiler or the streams you are using. In fact, pianorain's program is doing what it is supposed to do. I believe he is trying to point out your misuse, and your willingness to blame it on external factors, in a passive agressive way.

---

The part in bold is really the most annoying part. I was continually reminded of 'How To Ask Questions The Smart Way'. Reading through that little guide is tremendously helpful.

Quote:

---

Originally Posted by Elysia

You don't have a clear view of what the actual problem is, and that is by all definitions, bad. You must understand that streams are bastards in many ways.

---

There is a super-saturation of truth in these statements. I expect crystalline formations to appear soon.

Quote:

---

Originally Posted by pianorain

The part in bold is really the most annoying part. I was continually reminded of 'How To Ask Questions The Smart Way'. Reading through that little guide is tremendously helpful.

---

Hey, thanks for that link. The author of it definitely made some good points.
I'll try to watch what I post a little better from now on...but seriously, its the Internet.
Half of the time, I'm not even serious when I post stuff. Don't take it personal. Also don't think that I'm taking anything personal, because I'm not. Its just my personality to say things in a prickish way that always annoys people. That's more for amusement than anything else.
And about the research/homework thing, I usually do do that before starting a thread (though I admit I maybe don't give it as much effort as I should). And right after discovering that the problem was with the stringstream, I read up on the stringstream << operator reference at cplusplus.com, but it didn't mention that it appended to existing data instead of replacing it. So I figured I would mention it here.
Anyway, its funner to get feedback from real people on programming problems, rather than turning to Google all the time. Plus, getting involved in a discussion about the topic always helps me remember stuff better.