I checked for some commandline options and I thought it would be the
best to map that through an unordered_map. I extracted this from my
application in the below code.

#include <Windows.h>
#include <iostream>
#include <variant>
#include <unordered_map>

using namespace std;

int wmain( int argc, wchar_t **argv )
{ static unordered_map<wchar_t const *, DWORD>
const opts =
{
{ L"--idle", IDLE_PRIORITY_CLASS },
{ L"--below", BELOW_NORMAL_PRIORITY_CLASS },
{ L"--above", ABOVE_NORMAL_PRIORITY_CLASS },
{ L"--high", HIGH_PRIORITY_CLASS },
{ L"--realtime", REALTIME_PRIORITY_CLASS }
};
auto mappedPrio = opts.find( "--high" );
if( mappedPrio == opts.end() )
return -1;
return 0;
}

Why does my code have a bug and why doesn't mappedPrio
point to end() at the end?

On 2023-09-01 7:35 PM, Bonita Montero wrote:
> I checked for some commandline options and I thought it would be the
> best to map that through an unordered_map. I extracted this from my
> application in the below code.
>
> #include <Windows.h>
> #include <iostream>
> #include <variant>
> #include <unordered_map>
>
> using namespace std;
>
> int wmain( int argc, wchar_t **argv )
> {
>     static unordered_map<wchar_t const *, DWORD>
>         const opts =
>     {
>         { L"--idle", IDLE_PRIORITY_CLASS },
>         { L"--below", BELOW_NORMAL_PRIORITY_CLASS },
>         { L"--above", ABOVE_NORMAL_PRIORITY_CLASS },
>         { L"--high", HIGH_PRIORITY_CLASS },
>         { L"--realtime", REALTIME_PRIORITY_CLASS }
>     };
>     auto mappedPrio = opts.find( "--high" );
>     if( mappedPrio == opts.end() )
>         return -1;
>     return 0;
> }
>
> Why does my code have a bug and why doesn't mappedPrio
> point to end() at the end?

How did you get that to compile?

With the compilation-spoiler fixed and the `-1` replaced with either
`E_FAIL` or `EXIT_FAILURE` (for the latter include `<stdlib.h>`), the
problem you're /probably/ talking about is why it doesn't work with your
setup to compare pointers to string literals. That's because the Holy
Standard does not require string pooling. An easy fix is to use
`wstring_view` as key (for that include `<string_view>`).

- Alf

On 9/1/2023 10:35 AM, Bonita Montero wrote:
> I checked for some commandline options and I thought it would be the
> best to map that through an unordered_map. I extracted this from my
> application in the below code.
>
> #include <Windows.h>
> #include <iostream>
> #include <variant>
> #include <unordered_map>
>
> using namespace std;
>
> int wmain( int argc, wchar_t **argv )
> {
>     static unordered_map<wchar_t const *, DWORD>
>         const opts =
>     {
>         { L"--idle", IDLE_PRIORITY_CLASS },
>         { L"--below", BELOW_NORMAL_PRIORITY_CLASS },
>         { L"--above", ABOVE_NORMAL_PRIORITY_CLASS },
>         { L"--high", HIGH_PRIORITY_CLASS },
>         { L"--realtime", REALTIME_PRIORITY_CLASS }
>     };
>     auto mappedPrio = opts.find( "--high" );
>     if( mappedPrio == opts.end() )
>         return -1;
>     return 0;
> }
>
> Why does my code have a bug and why doesn't mappedPrio
> point to end() at the end?

Try something like:
___________________________
#include <iostream>
#include <unordered_map>
#include <string>
#include <cstdlib>

int main()
{ static std::unordered_map<std::string, long> opts = {
{"--idle", 0 },
{"--below", 1 },
{"--above", 2 },
{"--high", 3 },
{"--realtime", 4 }
};

auto mapped_opt = opts.find("--realtime");

if(mapped_opt == opts.end())
{
std::cout << "ahhh, shit!!!" << std::endl;

return EXIT_FAILURE;
}

std::cout << mapped_opt->first << ", " << mapped_opt->second <<
std::endl;

return EXIT_SUCCESS;
} ___________________________

?

On 9/1/2023 2:09 PM, Alf P. Steinbach wrote:
> On 2023-09-01 7:35 PM, Bonita Montero wrote:
>> I checked for some commandline options and I thought it would be the
>> best to map that through an unordered_map. I extracted this from my
>> application in the below code.
>>
>> #include <Windows.h>
>> #include <iostream>
>> #include <variant>
>> #include <unordered_map>
>>
>> using namespace std;
>>
>> int wmain( int argc, wchar_t **argv )
>> {
>>      static unordered_map<wchar_t const *, DWORD>
>>          const opts =
>>      {
>>          { L"--idle", IDLE_PRIORITY_CLASS },
>>          { L"--below", BELOW_NORMAL_PRIORITY_CLASS },
>>          { L"--above", ABOVE_NORMAL_PRIORITY_CLASS },
>>          { L"--high", HIGH_PRIORITY_CLASS },
>>          { L"--realtime", REALTIME_PRIORITY_CLASS }
>>      };
>>      auto mappedPrio = opts.find( "--high" );
>>      if( mappedPrio == opts.end() )
>>          return -1;
>>      return 0;
>> }
>>
>> Why does my code have a bug and why doesn't mappedPrio
>> point to end() at the end?
>
> How did you get that to compile?
>
> With the compilation-spoiler fixed and the `-1` replaced with either
> `E_FAIL` or `EXIT_FAILURE` (for the latter include `<stdlib.h>`), the
> problem you're /probably/ talking about is why it doesn't work with your
> setup to compare pointers to string literals.

Yup.

> That's because the Holy
> Standard does not require string pooling. An easy fix is to use
> `wstring_view` as key (for that include `<string_view>`).
>
> - Alf

Am 01.09.2023 um 23:50 schrieb Chris M. Thomasson:

> Try something like:

I know that I could have done that easier, but I wanted to know
where's the bug and why my example does find the key value anyway.

> ___________________________
> #include <iostream>
> #include <unordered_map>
> #include <string>
> #include <cstdlib>
>
>
> int main()
> {
>     static std::unordered_map<std::string, long> opts = {
>       {"--idle", 0 },
>       {"--below", 1 },
>       {"--above", 2 },
>       {"--high", 3 },
>       {"--realtime", 4 }
>     };
>
>     auto mapped_opt = opts.find("--realtime");

The problem here is that each find creates a string-object,
which is rather slow.

Am 01.09.2023 um 23:09 schrieb Alf P. Steinbach:

> the problem you're /probably/ talking about is why it doesn't work with your
> setup to compare pointers to string literals. That's because the Holy
> Standard does not require string pooling. An easy fix is to use
> `wstring_view` as key (for that include `<string_view>`).

Exactly, that's what I did afterwards. But I first thought
that my code works because the linker has joined my both
"--high" strings to the same address.

On Sat, 2 Sep 2023 06:23:02 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 01.09.2023 um 23:09 schrieb Alf P. Steinbach:
>
>> the problem you're /probably/ talking about is why it doesn't work with
>your
>> setup to compare pointers to string literals. That's because the Holy
>> Standard does not require string pooling. An easy fix is to use
>> `wstring_view` as key (for that include `<string_view>`).
>
>Exactly, that's what I did afterwards. But I first thought
>that my code works because the linker has joined my both
>"--high" strings to the same address.

There's nothing in the standard saying that should be the case. I thought
you were a C++ god?

Am 02.09.2023 um 12:25 schrieb Muttley@dastardlyhq.com:

> On Sat, 2 Sep 2023 06:23:02 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:

>> Exactly, that's what I did afterwards. But I first thought
>> that my code works because the linker has joined my both
>> "--high" strings to the same address.

> There's nothing in the standard saying that should be the case.

No, but also nothing that forbids that.
And actually the linkers do that.

Try this at home:

#include <iostream>

int main()
{ std::cout << ("xxx" == "xxx") << std::endl;
}

Although MSVC joined the strings in my first example it doesnt
do that in this example. Bug g++ and clang++ do join the strings.

> I thought you were a C++ god?

Sounds you are not.

Am 02.09.2023 um 12:56 schrieb Bonita Montero:

> No, but also nothing that forbids that.
> And actually the linkers do that.
>
> Try this at home:
>
> #include <iostream>
>
> int main()
> {
>     std::cout << ("xxx" == "xxx") << std::endl;
> }

I found a small imcompatibility between MSVC's cl and "MSVC's" clang-cl:

C:\Users\Boni>cl -Ox -MD join.cpp -EHs
....
C:\Users\Boni>join
0 C:\Users\Boni>clang-cl -Ox -MD join.cpp -EHs
....
C:\Users\Boni>join
1

Maybe someone relies on the uniqueness or on the joining.

Am 02.09.2023 um 14:35 schrieb Bonita Montero:

> I found a small imcompatibility between MSVC's cl and "MSVC's" clang-cl:
>
> C:\Users\Boni>cl -Ox -MD join.cpp -EHs
> ...
> C:\Users\Boni>join
> 0
> C:\Users\Boni>clang-cl -Ox -MD join.cpp -EHs
> ...
> C:\Users\Boni>join
> 1
>
> Maybe someone relies on the uniqueness or on the joining.

I found that there is a commandline-option of MSVC and clang-cl that
directs the compiler to join strings with -GF or not with -GF-. For
MSVC the default is not to join the strings, for clang-cl the default
is to join the strings.

On Sat, 2 Sep 2023 12:56:58 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 02.09.2023 um 12:25 schrieb Muttley@dastardlyhq.com:
>
>> On Sat, 2 Sep 2023 06:23:02 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>
>>> Exactly, that's what I did afterwards. But I first thought
>>> that my code works because the linker has joined my both
>>> "--high" strings to the same address.
>
>> There's nothing in the standard saying that should be the case.
>
>No, but also nothing that forbids that.

There's nothing forbidding a lot of things but relying on them always being
the case would lead to some interesting bugs when the code is compiled on
a compiler that uses a different approach.

Am 02.09.2023 um 17:30 schrieb Muttley@dastardlyhq.com:

> There's nothing forbidding a lot of things but relying on them always being
> the case would lead to some interesting bugs when the code is compiled on
> a compiler that uses a different approach.

I just wanted to verify what I did wrong with my unordered map, having
a wchar_t-pointer as the key, and accidentally MSVC joined the strings
and the key actually was found because the keys shared the addresses.
So I this was all accidentally and I didn't rely on anything.
But if you're stuck with MS cl or clang-cl and you use the -GF(-) switch
correctly - as I said both have different defaults - you could even rely
on that anyway if you're writing a Windows application.

Bonita Montero ha scritto:
> I checked for some commandline options and I thought it would be the
> best to map that through an unordered_map. I extracted this from my
> application in the below code.
>
> #include <Windows.h>
> #include <iostream>
> #include <variant>
> #include <unordered_map>
>
> using namespace std;
>
> int wmain( int argc, wchar_t **argv )
> {
>     static unordered_map<wchar_t const *, DWORD>
>         const opts =
>     {
>         { L"--idle", IDLE_PRIORITY_CLASS },
>         { L"--below", BELOW_NORMAL_PRIORITY_CLASS },
>         { L"--above", ABOVE_NORMAL_PRIORITY_CLASS },
>         { L"--high", HIGH_PRIORITY_CLASS },
>         { L"--realtime", REALTIME_PRIORITY_CLASS }
>     };
>     auto mappedPrio = opts.find( "--high" );
>     if( mappedPrio == opts.end() )
>         return -1;
>     return 0;
> }
>
> Why does my code have a bug and why doesn't mappedPrio
> point to end() at the end?

HI,
you just need to use wchar_t in your search string as well:

from:
auto mappedPrio = opts.find( "--high" );
to:
auto mappedPrio = opts.find( L"--high" );

jak ha scritto:
> Bonita Montero ha scritto:
>> I checked for some commandline options and I thought it would be the
>> best to map that through an unordered_map. I extracted this from my
>> application in the below code.
>>
>> #include <Windows.h>
>> #include <iostream>
>> #include <variant>
>> #include <unordered_map>
>>
>> using namespace std;
>>
>> int wmain( int argc, wchar_t **argv )
>> {
>>      static unordered_map<wchar_t const *, DWORD>
>>          const opts =
>>      {
>>          { L"--idle", IDLE_PRIORITY_CLASS },
>>          { L"--below", BELOW_NORMAL_PRIORITY_CLASS },
>>          { L"--above", ABOVE_NORMAL_PRIORITY_CLASS },
>>          { L"--high", HIGH_PRIORITY_CLASS },
>>          { L"--realtime", REALTIME_PRIORITY_CLASS }
>>      };
>>      auto mappedPrio = opts.find( "--high" );
>>      if( mappedPrio == opts.end() )
>>          return -1;
>>      return 0;
>> }
>>
>> Why does my code have a bug and why doesn't mappedPrio
>> point to end() at the end?
>
> HI,
> you just need to use wchar_t in your search string as well:
>
> from:
> auto mappedPrio = opts.find( "--high" );
> to:
> auto mappedPrio = opts.find( L"--high" );
>
>

mmm. This only works because the compiler uses the same area of memory
as the strings are equal and therefore compares a pointer to itself when
it finds the string. In fact if I replace this:

auto mappedPrio = opts.find( L"--high" );

with this other:

wchar_t what[] = L"--high";
auto mappedPrio = opts.find( what );

the search fails.

I find this sneaky. In my opinion the compiler shouldn't treat two
objects as the same just because they have the same content.

On 9/1/2023 9:19 PM, Bonita Montero wrote:
> Am 01.09.2023 um 23:50 schrieb Chris M. Thomasson:
>
>> Try something like:
>
> I know that I could have done that easier, but I wanted to know
> where's the bug and why my example does find the key value anyway.
>
>> ___________________________
>> #include <iostream>
>> #include <unordered_map>
>> #include <string>
>> #include <cstdlib>
>>
>>
>> int main()
>> {
>>      static std::unordered_map<std::string, long> opts = {
>>        {"--idle", 0 },
>>        {"--below", 1 },
>>        {"--above", 2 },
>>        {"--high", 3 },
>>        {"--realtime", 4 }
>>      };
>>
>>      auto mapped_opt = opts.find("--realtime");
>
> The problem here is that each find creates a string-object,
> which is rather slow.

Right. Afaict, there is a way to create the strings on the stack and use
a little adapter logic to make it work with std::unordered_map. So, no
dynamic allocation.

jak <nospam@please.ty> writes:
> jak ha scritto:
>> Bonita Montero ha scritto:
>>> I checked for some commandline options and I thought it would be the
>>> best to map that through an unordered_map. I extracted this from my
>>> application in the below code.
>>>
>>> #include <Windows.h>
>>> #include <iostream>
>>> #include <variant>
>>> #include <unordered_map>
>>>
>>> using namespace std;
>>>
>>> int wmain( int argc, wchar_t **argv )
>>> {
>>>      static unordered_map<wchar_t const *, DWORD>
>>>          const opts =
>>>      {
>>>          { L"--idle", IDLE_PRIORITY_CLASS },
>>>          { L"--below", BELOW_NORMAL_PRIORITY_CLASS },
>>>          { L"--above", ABOVE_NORMAL_PRIORITY_CLASS },
>>>          { L"--high", HIGH_PRIORITY_CLASS },
>>>          { L"--realtime", REALTIME_PRIORITY_CLASS }
>>>      };
>>>      auto mappedPrio = opts.find( "--high" );
>>>      if( mappedPrio == opts.end() )
>>>          return -1;
>>>      return 0;
>>> }
>>>
>>> Why does my code have a bug and why doesn't mappedPrio
>>> point to end() at the end?
>> HI,
>> you just need to use wchar_t in your search string as well:
>> from:
>> auto mappedPrio = opts.find( "--high" );
>> to:
>> auto mappedPrio = opts.find( L"--high" );
>>
>
> mmm. This only works because the compiler uses the same area of memory
> as the strings are equal and therefore compares a pointer to itself when
> it finds the string. In fact if I replace this:
>
> auto mappedPrio = opts.find( L"--high" );
>
> with this other:
>
> wchar_t what[] = L"--high";
> auto mappedPrio = opts.find( what );
>
> the search fails.
>
> I find this sneaky. In my opinion the compiler shouldn't treat two
> objects as the same just because they have the same content.

The find() function of unordered_map<> compares keys for *equality*.

Since the code defines the key type as `wchar_t const *`, it does
pointer comparison, which has all the usual problems when you apply it
to string literals; L"foo" and L"foo" may or may not be stored at the
same memory location, and L"foo" and a string L"foo" derived from user
input will certainly not have the same address.

You can specify an equality function if you like.

A far simpler solution is to use std::wstring as the key type.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Am 04.09.2023 um 00:25 schrieb Chris M. Thomasson:

> Right. Afaict, there is a way to create the strings on the stack and use
> a little adapter logic to make it work with std::unordered_map. So, no
> dynamic allocation.

You can simply have a string_view as suggested in this thread.

On 9/3/2023 7:53 PM, Bonita Montero wrote:
> Am 04.09.2023 um 00:25 schrieb Chris M. Thomasson:
>
>> Right. Afaict, there is a way to create the strings on the stack and
>> use a little adapter logic to make it work with std::unordered_map.
>> So, no dynamic allocation.
>
> You can simply have a string_view as suggested in this thread.
>

A view into strings stored on the stack.

Am 04.09.2023 um 05:01 schrieb Chris M. Thomasson:

> A view into strings stored on the stack.

string_view is just a pointer and a size_t or two pointers.
And string_view is often faster since its constructor is
constexpr. If you do a string_view( "hello world" ).length()
that's all compile-time evaluated.

Am 04.09.2023 um 06:59 schrieb Bonita Montero:

> string_view is just a pointer and a size_t or two pointers.
> And string_view is often faster since its constructor is
> constexpr. If you do a string_view( "hello world" ).length()
> that's all compile-time evaluated.

#include <string_view>

size_t fn()
{ return std::string_view( "hello world" ).length();
}

MSVC:

?fn@@YA_KXZ PROC
mov eax, 11
ret 0
?fn@@YA_KXZ ENDP

clang++:

_Z2fnv:
movl $11, %eax
retq

g++:

_Z2fnv:
movl $11, %eax
ret

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>On 9/1/2023 9:19 PM, Bonita Montero wrote:
>> Am 01.09.2023 um 23:50 schrieb Chris M. Thomasson:
>>
>>> Try something like:
>>
>> I know that I could have done that easier, but I wanted to know
>> where's the bug and why my example does find the key value anyway.
>>
>>> ___________________________
>>> #include <iostream>
>>> #include <unordered_map>
>>> #include <string>
>>> #include <cstdlib>
>>>
>>>
>>> int main()
>>> {
>>>      static std::unordered_map<std::string, long> opts = {
>>>        {"--idle", 0 },
>>>        {"--below", 1 },
>>>        {"--above", 2 },
>>>        {"--high", 3 },
>>>        {"--realtime", 4 }
>>>      };
>>>
>>>      auto mapped_opt = opts.find("--realtime");
>>
>> The problem here is that each find creates a string-object,
>> which is rather slow.
>
>Right. Afaict, there is a way to create the strings on the stack and use
>a little adapter logic to make it work with std::unordered_map. So, no
>dynamic allocation.

Or just use getopt_long() with UTF-8 strings.

Bonita Montero wrote:
> Am 01.09.2023 um 23:50 schrieb Chris M. Thomasson:
>
>> Try something like:
>
> I know that I could have done that easier, but I wanted to know
> where's the bug and why my example does find the key value anyway.
>
>> ___________________________
>> #include <iostream>
>> #include <unordered_map>
>> #include <string>
>> #include <cstdlib>
>>
>>
>> int main()
>> {
>>      static std::unordered_map<std::string, long> opts = {
>>        {"--idle", 0 },
>>        {"--below", 1 },
>>        {"--above", 2 },
>>        {"--high", 3 },
>>        {"--realtime", 4 }
>>      };
>>
>>      auto mapped_opt = opts.find("--realtime");
>
> The problem here is that each find creates a string-object,
> which is rather slow.

If you cared about the speed, why did you use unordered_map?

On 9/4/2023 3:43 PM, Pavel wrote:
> Bonita Montero wrote:
>> Am 01.09.2023 um 23:50 schrieb Chris M. Thomasson:
>>
>>> Try something like:
>>
>> I know that I could have done that easier, but I wanted to know
>> where's the bug and why my example does find the key value anyway.
>>
>>> ___________________________
>>> #include <iostream>
>>> #include <unordered_map>
>>> #include <string>
>>> #include <cstdlib>
>>>
>>>
>>> int main()
>>> {
>>>      static std::unordered_map<std::string, long> opts = {
>>>        {"--idle", 0 },
>>>        {"--below", 1 },
>>>        {"--above", 2 },
>>>        {"--high", 3 },
>>>        {"--realtime", 4 }
>>>      };
>>>
>>>      auto mapped_opt = opts.find("--realtime");
>>
>> The problem here is that each find creates a string-object,
>> which is rather slow.
>
> If you cared about the speed, why did you use unordered_map?
>

Yeah. For something done exactly once, with 5 entries, best bet is a
std::array.

On 9/3/2023 8:01 PM, Chris M. Thomasson wrote:
> On 9/3/2023 7:53 PM, Bonita Montero wrote:
>> Am 04.09.2023 um 00:25 schrieb Chris M. Thomasson:
>>
>>> Right. Afaict, there is a way to create the strings on the stack and
>>> use a little adapter logic to make it work with std::unordered_map.
>>> So, no dynamic allocation.
>>
>> You can simply have a string_view as suggested in this thread.
>>
>
> A view into strings stored on the stack.

Check this out, my little experiment with stacks, used in a per-thread
allocator:

https://pastebin.com/raw/f37a23918

https://groups.google.com/g/comp.lang.c/c/7oaJFWKVCTw/m/sSWYU9BUS_QJ

Am 05.09.2023 um 00:43 schrieb Pavel:

> If you cared about the speed, why did you use unordered_map?

My original example wasn't about speed. And the map is static, so it's
initialized thread-safe on the first run. But if I store strings in the
map, a string object is created with every lookup with a string literal,
which may result in a memory allocation. Depending on the case, this may
be too slow.