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 3 of 3 — ← Prev page 1 2 [3]

#91544

jak <nospam@please.ty> writes:
[...]
> I probably expressed myself badly. I agree with what you answered and
> everything is clear to me. What I am contesting is the part where you
> say "...may or may not be stored at the same memory location" because
> that would mean that a program like this:
>
> #include <iostream>
>
> int main()
> {
>     auto eif = [] (bool t) {
>         std::cout << ( t ? "equal" : "not equal" ) << std::endl;
>     };
>
>     char const *sp = "hello";
>     char sl[] = "hello";
>
>     eif( sp == sp );
>
>     eif( "hello" == sp );
>
>     eif( "hello" == "hello" );
>
>     eif( "hello" == sl );
>
>     return 0;
> }
>
> which has this as a result:
>
> equal
> equal
> equal
> not equal
>
> could give different results depending on how the compiler acts when
> deciding where to store strings (because here we are comparing
> pointers).

Yes, that's exactly what it means.

>            I simply think that different objects shouldn't be lumped
> together just because they contain the same things, otherwise I would
> have declared a single string and would have used its pointer around the
> code. Pointers are for that too. it is my opinion that the program I
> posted should have this as a result:
>
> equal
> not equal
> not equal
> not equal

I suggest the language standard is more relevant than either of our
opinions.

C++17 5.13.5 [lex.string] paragraph 16:

    Evaluating a *string-literal* results in a string literal
    object with static storage duration, initialized from the given
    characters as specified above. Whether all string literals are
    distinct (that is, are stored in nonoverlapping objects) and
    whether successive evaluations of a *string-literal* yield the
    same or a different object is unspecified. [ Note: The effect
    of attempting to modify a string literal is undefined. — end
    note ]

I believe that all versions of C and C++ have similar rules.

Which means that ("hello" == "hello") may be either true or false, and
an implementation is not required to document which.

In your program above, this:
    sp == sp
is guaranteed to be true, these:    
    "hello" == sp
    "hello" == "hello"
may be either true or false, and this:
    "hello" == sl
is false because sl is distinct and explicitly defined array object.

If you compile your program with clang++, it prints warnings on all four
comparisons.

-- 
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 */

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

#91556

Keith Thompson ha scritto:
> jak <nospam@please.ty> writes:
> [...]
>> I probably expressed myself badly. I agree with what you answered and
>> everything is clear to me. What I am contesting is the part where you
>> say "...may or may not be stored at the same memory location" because
>> that would mean that a program like this:
>>
>> #include <iostream>
>>
>> int main()
>> {
>>      auto eif = [] (bool t) {
>>          std::cout << ( t ? "equal" : "not equal" ) << std::endl;
>>      };
>>
>>      char const *sp = "hello";
>>      char sl[] = "hello";
>>
>>      eif( sp == sp );
>>
>>      eif( "hello" == sp );
>>
>>      eif( "hello" == "hello" );
>>
>>      eif( "hello" == sl );
>>
>>      return 0;
>> }
>>
>> which has this as a result:
>>
>> equal
>> equal
>> equal
>> not equal
>>
>> could give different results depending on how the compiler acts when
>> deciding where to store strings (because here we are comparing
>> pointers).
> 
> Yes, that's exactly what it means.
> 
>>             I simply think that different objects shouldn't be lumped
>> together just because they contain the same things, otherwise I would
>> have declared a single string and would have used its pointer around the
>> code. Pointers are for that too. it is my opinion that the program I
>> posted should have this as a result:
>>
>> equal
>> not equal
>> not equal
>> not equal
> 
> I suggest the language standard is more relevant than either of our
> opinions.
> 
> C++17 5.13.5 [lex.string] paragraph 16:
> 
>      Evaluating a *string-literal* results in a string literal
>      object with static storage duration, initialized from the given
>      characters as specified above. Whether all string literals are
>      distinct (that is, are stored in nonoverlapping objects) and
>      whether successive evaluations of a *string-literal* yield the
>      same or a different object is unspecified. [ Note: The effect
>      of attempting to modify a string literal is undefined. — end
>      note ]
> 
> I believe that all versions of C and C++ have similar rules.
> 
> Which means that ("hello" == "hello") may be either true or false, and
> an implementation is not required to document which.
> 
> In your program above, this:
>      sp == sp
> is guaranteed to be true, these:
>      "hello" == sp
>      "hello" == "hello"
> may be either true or false, and this:
>      "hello" == sl
> is false because sl is distinct and explicitly defined array object.
> 
> If you compile your program with clang++, it prints warnings on all four
> comparisons.
> 
Thanks for sending the paragraph. Unfortunately I had only sought it
just before your post.
However, it is obvious that it prints the warnings, I extracted the test
intentionally from the function/method, because otherwise the compiler
does not recognize the UB. If I modified my program in this way:

$ cat ./pp.cpp
#include <iostream>

int main()
{
     auto eif = [] (char const *a, char const *b) {
         std::cout << ( ( a == b ) ? "equal" : "not equal" ) << std::endl;
     };
     char const *sp = "hello";
     char sl[] = "hello";

     eif( sp, sp );
     eif( "hello", sp );
     eif( "hello", "hello" );
     eif( "hello", sl );

     return 0;
}

$ g++ -Wall -Wpedantic -Werror -std=c++17 ./pp.cpp -o ./pp

$ ./pp
equal
equal
equal
not equal

$ _

The warnings disappear but the UB remain. For this reason I think that
making objects unique because they have the same content is a bad
practice. Furthermore, the fact that it may happen or not makes the fact
even worse.

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

#91591

On 9/6/23 19:18, jak wrote:
...
> However, it is obvious that it prints the warnings, I extracted the test
> intentionally from the function/method, because otherwise the compiler
> does not recognize the UB. If I modified my program in this way:
> 
> $ cat ./pp.cpp
> #include <iostream>
> 
> int main()
> {
>      auto eif = [] (char const *a, char const *b) {
>          std::cout << ( ( a == b ) ? "equal" : "not equal" ) << std::endl;
>      };
>      char const *sp = "hello";
>      char sl[] = "hello";
> 
>      eif( sp, sp );
>      eif( "hello", sp );
>      eif( "hello", "hello" );
>      eif( "hello", sl );
> 
>      return 0;
> }
> 
> $ g++ -Wall -Wpedantic -Werror -std=c++17 ./pp.cpp -o ./pp
> 
> $ ./pp
> equal
> equal
> equal
> not equal
> 
> $ _
> 
> The warnings disappear but the UB remain.

What UB are you referring to?

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

#91542

Am 04.09.2023 um 02:37 schrieb Keith Thompson:

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

A string_view is much more perfromant and allows to reference
external strings - if applicable.

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

#91545

On 9/3/2023 2:17 PM, jak wrote:

>> 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:
>

No, I believe that std::unordered_map has a specialization for both
const char* and const wchar_t*.

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

#91546

red floyd <no.spam.here@its.invalid> writes:
> On 9/3/2023 2:17 PM, jak wrote:
>>> 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:
>
> No, I believe that std::unordered_map has a specialization for both
> const char* and const wchar_t*.

I don't believe that's correct.  Do you have a reference?

-- 
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 */

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

#91557

On 9/5/2023 9:14 PM, Keith Thompson wrote:
> red floyd <no.spam.here@its.invalid> writes:
>> On 9/3/2023 2:17 PM, jak wrote:
>>>> 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:
>>
>> No, I believe that std::unordered_map has a specialization for both
>> const char* and const wchar_t*.
> 
> I don't believe that's correct.  Do you have a reference?
> 

Isn't it based on std::less<>?

Just checked.  My mistake, forget I said anything.

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

#91547

Am 06.09.2023 um 05:53 schrieb red floyd:

> No, I believe that std::unordered_map has a specialization
> for both const char* and const wchar_t*.

Would be nice but actually this isn't true.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web