Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #91514 > unrolled thread

What a bug

Back to article view | Back to comp.lang.c++

Contents

  What a bug Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-01 19:35 +0200
    Re: What a bug "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2023-09-01 23:09 +0200
      Re: What a bug "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-01 14:52 -0700
      Re: What a bug Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-02 06:23 +0200
        Re: What a bug Muttley@dastardlyhq.com - 2023-09-02 10:25 +0000
          Re: What a bug Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-02 12:56 +0200
            Re: What a bug Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-02 14:35 +0200
              Re: What a bug Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-02 14:41 +0200
            Re: What a bug Muttley@dastardlyhq.com - 2023-09-02 15:30 +0000
              Re: What a bug Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-02 18:10 +0200
    Re: What a bug "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-01 14:50 -0700
      Re: What a bug Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-02 06:19 +0200
        Re: What a bug "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-03 15:25 -0700
          Re: What a bug Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-04 04:53 +0200
            Re: What a bug "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-03 20:01 -0700
              Re: What a bug Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-04 06:59 +0200
                Re: What a bug Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-04 11:11 +0200
              Re: What a bug "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-04 18:48 -0700
                Re: What a bug "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-14 16:27 -0700
          Re: What a bug scott@slp53.sl.home (Scott Lurndal) - 2023-09-04 14:24 +0000
            Re: What a bug "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-18 16:20 -0700
        Re: What a bug Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-04 18:43 -0400
          Re: What a bug red floyd <no.spam.here@its.invalid> - 2023-09-04 17:36 -0700
          Re: What a bug Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-05 05:49 +0200
            Re: What a bug Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-06 12:00 -0400
              Re: What a bug Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-06 19:46 +0200
                Re: What a bug Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-06 14:44 -0400
                  Re: What a bug Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-07 04:51 +0200
                    Re: What a bug Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-06 23:54 -0400
                      Re: What a bug Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-07 06:58 +0200
                        Re: What a bug Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-07 11:08 -0400
                          Re: What a bug Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-07 17:56 +0200
                            Re: What a bug Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-07 18:04 +0200
                              Re: What a bug Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2023-09-07 19:35 -0400
                          Re: What a bug Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-07 17:46 +0200
    Re: What a bug jak <nospam@please.ty> - 2023-09-02 23:15 +0200
      Re: What a bug jak <nospam@please.ty> - 2023-09-03 23:17 +0200
        Re: What a bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-03 17:37 -0700
          Re: What a bug jak <nospam@please.ty> - 2023-09-05 11:01 +0200
            Re: What a bug Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-05 11:12 +0200
            Re: What a bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-05 03:04 -0700
              Re: What a bug jak <nospam@please.ty> - 2023-09-07 01:18 +0200
                Re: What a bug James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-08 00:09 -0400
          Re: What a bug Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-05 11:11 +0200
        Re: What a bug red floyd <no.spam.here@its.invalid> - 2023-09-05 20:53 -0700
          Re: What a bug Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-05 21:14 -0700
            Re: What a bug red floyd <no.spam.here@its.invalid> - 2023-09-06 17:51 -0700
          Re: What a bug Bonita Montero <Bonita.Montero@gmail.com> - 2023-09-06 06:49 +0200

Page 1 of 3  [1] 2 3  Next page →

#91514 — What a bug

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?

[toc] | [next] | [standalone]

#91515

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

[toc] | [prev] | [next] | [standalone]

#91517

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

[toc] | [prev] | [next] | [standalone]

#91519

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.

[toc] | [prev] | [next] | [standalone]

#91520

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?

[toc] | [prev] | [next] | [standalone]

#91521

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.

[toc] | [prev] | [next] | [standalone]

#91522

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.

[toc] | [prev] | [next] | [standalone]

#91523

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.

[toc] | [prev] | [next] | [standalone]

#91524

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.

[toc] | [prev] | [next] | [standalone]

#91525

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.

[toc] | [prev] | [next] | [standalone]

#91516

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;
}
___________________________

?

[toc] | [prev] | [next] | [standalone]

#91518

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.

[toc] | [prev] | [next] | [standalone]

#91528

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.

[toc] | [prev] | [next] | [standalone]

#91532

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.

[toc] | [prev] | [next] | [standalone]

#91533

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.

[toc] | [prev] | [next] | [standalone]

#91534

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.

[toc] | [prev] | [next] | [standalone]

#91535

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

[toc] | [prev] | [next] | [standalone]

#91539

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

[toc] | [prev] | [next] | [standalone]

#91716

On 9/4/2023 6:48 PM, Chris M. Thomasson wrote:
> 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
^^^^^^^^^^^

Wow, way back in 2009. How time flies!

[toc] | [prev] | [next] | [standalone]

#91536

"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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web