Why isn't map::find() finding anything?

Can anyone think of a reason why map::find() isn't finding a name that definitely is in the map?

Code:

typedef std::map<std::wstring, bool> UserAdminChangeMap; std::wstring strUserName( UserName->Buffer, UserName->Length ); // strUserName == L"Test1" UserAdminChangeMap::iterator it = g_UserAdminChangeMap.find( strUserName ); // map has 1 key == L"Test1" if ( it != g_UserAdminChangeMap.end() ) { if ( it->second == true ) { swprintf( GenericMessage, _T("*** User '%s' with admin flag found in map!"), strUserName.c_str() ); } else { swprintf( GenericMessage, _T("*** User '%s' WITHOUT admin flag found in map!"), strUserName.c_str() ); } g_UserAdminChangeMap.erase( it ); } else { it = g_UserAdminChangeMap.begin(); swprintf( GenericMessage, _T("*** User (%04x %04x %04x %04x %04x %04x) NOT found in map!\nmap size = %u\nmap.first = (%04x %04x %04x %04x %04x %04x)"), strUserName.c_str()[0], strUserName.c_str()[1], strUserName.c_str()[2], strUserName.c_str()[3], strUserName.c_str()[4], strUserName.c_str()[5], g_UserAdminChangeMap.size(), it->first.c_str()[0], it->first.c_str()[1], it->first.c_str()[2], it->first.c_str()[3], it->first.c_str()[4], it->first.c_str()[5] ); }

It prints this into GenericMessage:

Code:

*** User (0054 0065 0073 0074 0031 0000) NOT found in map! map size = 1 map.first = (0054 0065 0073 0074 0031 0000)

have you tried stripping whitespace, etc ?

Quote:

Originally Posted by m37h0d

have you tried stripping whitespace, etc ?

From where?
The strings are exactly the same. Both are "Test1" and I even checked the hex values of the characters in case there was some strange Unicode difference, but they're both (0054 0065 0073 0074 0031 0000)

I just tried changing my map to a vector and it still doesn't find it:

Code:

typedef std::vector<std::wstring> UserAdminChangeMap; UserAdminChangeMap::iterator it = std::find( g_UserAdminChangeMap.begin(), g_UserAdminChangeMap.end(), strUserName );

Stupid question: Does g_UserAdminChangeMap.begin().str() == strUserName give you true or false?

Quote:

Originally Posted by tabstop

Stupid question: Does g_UserAdminChangeMap.begin().str() == strUserName give you true or false?

Good question, I'll try that out. It just takes a long time because every time I change the code in this DLL I need to reboot since it's loaded by LSA... :(

I also checked the .size() of each string, and for some reason it reported 10 instead of 5, so when I looked at all 10 hex bytes, the values were different after the NUL char:

Code:

*** User (0054 0065 0073 0074 0031 0000 0000 0000 8234 6670)[10] NOT found in map! map size = 1 map.first = (0054 0065 0073 0074 0031 0000 ffff ffff ffff ffff)[10]

Maybe the UserName->Length that LSA passes is wrong? I'll check that too.

Oh crap! I just looked at the documentation for PUNICODE_STRING again and saw that Length is in bytes, not in TCHARS. Doh!

YES!!! I changed it to this, and now everything works fine! :)

Code:

std::wstring strUserName( UserName->Buffer, (UserName->Length / sizeof(WCHAR)) );

I guess one other thing I learned with this mess is that std::string's == operator doesn't compare NUL terminated strings; it compares every character in it's buffer, even if there's a NUL in the middle of it.

Yes, in compares everything up to size(). Incidentally, I believe std::map uses operator< (by default) for comparing but that doesn't change anything.

Quote:

Originally Posted by anon

Yes, in compares everything up to size(). Incidentally, I believe std::map uses operator< (by default) for comparing but that doesn't change anything.

Yes, maps compare for equivalence rather than equality. i.e. if ( !(a < b) && !(b < a) )
I don't really need that bool parameter in the map anyways, so I just kept it as a vector.

Quote:

I don't really need that bool parameter in the map anyways, so I just kept it as a vector.

std::set ?

Quote:

Originally Posted by Cactus_Hugger

std::set ?

I just thought of that when I got home.
It's unlikely that a UserID would be pushed onto the vector and not removed by the other thread, but with this spagetti code anything is possible, so using a std::set would at least minimize a possible memory leak to a much smaller size.

Quote:

Originally Posted by cpjust

I just thought of that when I got home.
It's unlikely that a UserID would be pushed onto the vector and not removed by the other thread, but with this spagetti code anything is possible, so using a std::set would at least minimize a possible memory leak to a much smaller size.

If you're using std::string/std::wstring contained in a std::map/std::set, there shouldn't be any leaking, unless you're doing something really wrong. The nice thing about std::string, set, map, etc. is that they help reduce the coded needed to avoid leaking. My main motive for suggesting std::set is that finding userIDs would be O(log(n)) instead of O(n)

Be sure that access to the container and its contents is thread-safe, of course.

Quote:

Originally Posted by Cactus_Hugger

If you're using std::string/std::wstring contained in a std::map/std::set, there shouldn't be any leaking, unless you're doing something really wrong. The nice thing about std::string, set, map, etc. is that they help reduce the coded needed to avoid leaking. My main motive for suggesting std::set is that finding userIDs would be O(log(n)) instead of O(n)

Be sure that access to the container and its contents is thread-safe, of course.

Oh thanks, that's another good reason to use a std::set that I didn't think of.
The "memory leak" I was talking about is that I have 1 function adding users to the vector and another taking them off the vector. If something goes wrong and the 2nd function doesn't get called and therefore never removes the users from the vector, it would keep getting bigger and bigger. Also, since vectors allow duplicate entries, it grows indefinitely, whereas a std::set doesn't allow duplicates, so even if the users aren't removed, there wouldn't be that many users in the company to cause a huge memory leak. But that's just a cover my ass scenario, since I can't see a reason why the 2nd function wouldn't get called.