Like Tree4Likes

Comparing a string that might not exist?

This is a discussion on Comparing a string that might not exist? within the C++ Programming forums, part of the General Programming Boards category; Thanks everyone. I've decided against using at() because it's a passive parser. It shouldn't throw an exception if it doesn't ...

  1. #16
    Registered User
    Join Date
    May 2011
    Posts
    23
    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:
    Quote 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.
    Last edited by screennameless; 07-15-2011 at 07:14 PM.

  2. #17
    Registered User
    Join Date
    Apr 2006
    Posts
    2,053

    split

    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
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  3. #18
    Registered User
    Join Date
    May 2011
    Posts
    23
    Quote Originally Posted by King Mir View Post
    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
    Hmm, does this provide any advantages?

  4. #19
    Registered User
    Join Date
    Apr 2006
    Posts
    2,053
    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.
    screennameless likes this.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  5. #20
    Registered User
    Join Date
    May 2011
    Posts
    23
    Quote Originally Posted by King Mir View Post
    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.
    Ahh, I see. Well, thank you then, I will do this.
    Memory management is not really my forté, I'm still a beginner!

  6. #21
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,002
    Quote Originally Posted by screennameless View Post
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #22
    Registered User
    Join Date
    May 2011
    Posts
    23
    Quote Originally Posted by Elysia View Post
    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.
    Hmm. Well, the only way I can imagine using this is as a replacement to push_back(), by using resize() and then at() to assign it.
    Is this what you had in mind?

  8. #23
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,002
    No. Just replace the index operator with at. No other changes.
    screennameless likes this.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #24
    Registered User
    Join Date
    May 2011
    Posts
    23
    Ohh, haha, I didn't think of changing the compare() function. Thanks!

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 7
    Last Post: 06-16-2011, 07:21 PM
  2. String comparing in C
    By petrock6 in forum C Programming
    Replies: 10
    Last Post: 12-05-2008, 06:08 PM
  3. Comparing Value of Int to String
    By Xeavor in forum C Programming
    Replies: 6
    Last Post: 12-12-2004, 04:44 PM
  4. string comparing
    By pode in forum C++ Programming
    Replies: 5
    Last Post: 11-18-2002, 06:07 PM
  5. Problem comparing string from text file with string constant
    By XenoCodex Admin in forum C++ Programming
    Replies: 3
    Last Post: 07-25-2002, 11:17 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21