Thread: Comparing a string that might not exist?

Thanks everyone. I've decided against using at() because it's a passive parser. It shouldn't throw an exception if it doesn't equal something, it should only move on to the next combination of chunks and compare to those. And I believe using at() in such a manner would defeat the purpose, and (at least) overcomplicate things.

Instead, I've just written a member function
"compare(vector<string>& vsChunks, string sCompare, int nChunk)"
which does

Code:

if(vsChunks.size() >= nChunk + 1) {
    //Go ahead and compare
}
else
    return false; //nChunk doesn't exist, comparing would cause a segfault

And this seems to work just fine. Thanks again for your suggestions!

EDIT:

Originally Posted by Elysia

Better than getting a buffer overrun.
Plus using smart pointers (or avoiding new altogether!--I don't see a reason for it here), you won't get memory leaks either.

I'm using "new" because I want to be able to explicitly delete that object. The parser grows exponentially from that point, and I don't want to chance an overflow; so I'm dynamically allocating as much as I can without overcomplicating.

Re:new

Consider instead:

Code:

vector<string> vstrChunks;
{
  Split cSplit(strLine);

  vstrChunks.push_back(cSplit.first());
  while(!cSplit.islast())
    vstrChunks.push_back(cSplit.next());
}
//use vtrChunks here, but not cSplit

Yes, if vstrChunks.push_back() throws an exception (such as if it fails to allocate memory), then cSplit will be deleted for you without a leak. It's also simpler visually. The leak problem can be solved with smart pointers or a try-catch-rethrow, but neither of those options are as simple as this alternative.

Originally Posted by screennameless

Thanks everyone. I've decided against using at() because it's a passive parser. It shouldn't throw an exception if it doesn't equal something, it should only move on to the next combination of chunks and compare to those. And I believe using at() in such a manner would defeat the purpose, and (at least) overcomplicate things.

I think you are misunderstanding its suggested purpose here.
The suggestion was that it should be a second layer defense. That is, if for some reason, you make a programming error, instead of getting undefined behavior, you can catch the exception and prompt an "internal error," or the like.
(Plus a user would likely be less annoyed if they get an internal error rather than a crash or the entirely wrong results!)
It was not suggested you should use it to check if an element was there or not. The way you are using now is fine.

No. Just replace the index operator with at. No other changes.