How do I check for correct GUID from .txt file?

I have a GUID list in .txt file

like this
1
2
3
4
5
{4120cb22-c194-41bf-a221-49b0952e349e}
{83cc03cc-80d7-48ac-8dd1-051ce9cf2609}
{8448d87b-bf75-439d-be33-93070a19cc77}
{24e5b37b-7899-4a4e-a588-85f9126c3efb}
{571d6550-2978-4b36-b2f6-1f4e5a79fd0a}


I need to check for a "valid" GUID from that list.

1
2
3
4
5
6
7
8
9
10
11
12
13
  string valid = "{571d6550-2978-4b36-b2f6-1f4e5a79fd0a}" // valid GUID

  bool found = false;
  std::ifstream file;
  string line;
  file.open(path);
  while (std::getline(file, line))
  {
    //cout << line << endl;
    if (line.find(valid)) {
      found = true;
    }
  }


this didn't work.
Last edited on
find is not boolean, you should check against string::nopos or whatever it is.
strstr is effectively boolean, because nullptr == 0, but c++ strings do not expose their pointers and for some unholy reason npos isnt 0 so they had to make the find kludgy.

you don't need all that bloat either, just say something like
found |= (line.find(valid) != string::npos) ... trivial operations like bool assignment are so cheap that the extra comparison and jump of the if statement is actually less efficient (on top of being more wordy) than just assignment each iteration.

if you trust the file to not have crap in it, you can also use == instead of find()
Last edited on
and for some unholy reason npos isnt 0 so they had to make the find kludgy.
You can find something at index 0. Not that I'm defending the weird way string.find works compared to other <algorithm>s (to be consistent, it would return an iterator to string.end()).

std strings can expose their pointers through .data() (or by &str[0]).

In C++23 they'll finally have std::string::contains, lol.
https://en.cppreference.com/w/cpp/string/basic_string/contains
Last edited on
Contains would be welcome, that was a big miss. Ive been using strstr for it for years.

I don't like c++ string design. the need for 3-4 objects to do string work is a trainwreck. (string, string stream, string view, is there another one? and sometimes char* for compatibility or workarounds).
Topic archived. No new replies allowed.