Re: C++20 concepts rocks

Path	csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From	Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups	comp.lang.c++
Subject	Re: C++20 concepts rocks
Date	Tue, 15 Feb 2022 00:10:42 -0800
Organization	A noiseless patient Spider
Lines	91
Message-ID	<86zgmsh7nh.fsf@linuxsc.com> (permalink)
References	<stj7m4$bim$1@dont-email.me> <87k0easj5d.fsf@bsb.me.uk> <865yptlpgf.fsf@linuxsc.com> <stmeik$a9k$1@redfloyd.dont-email.me> <stmgvd$r0s$1@dont-email.me> <stn5hs$23i$1@redfloyd.dont-email.me> <sto2hk$4ha$1@dont-email.me> <sto62g$b91$1@dont-email.me> <87mtj4qd0h.fsf@bsb.me.uk> <86fsovkdjw.fsf@linuxsc.com> <877da7r7ap.fsf@bsb.me.uk> <86bkzjjs3c.fsf@linuxsc.com> <87k0e6q4j8.fsf@bsb.me.uk> <8635kukb17.fsf@linuxsc.com> <878rumptie.fsf@bsb.me.uk> <86leymiga7.fsf@linuxsc.com> <877da3n2au.fsf@bsb.me.uk> <86czjvi97y.fsf@linuxsc.com> <87czjulvm9.fsf@bsb.me.uk> <868ruhikqf.fsf@linuxsc.com> <su61id$an$1@dont-email.me>
Mime-Version	1.0
Content-Type	text/plain; charset=us-ascii
Injection-Info	reader02.eternal-september.org; posting-host="2ced22d51f2768d5f155d420840b05f4"; logging-data="17944"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18kLFVFW7gmn9Nu744s+eCxaMjSTcGdwDQ="
User-Agent	Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock	sha1:TTAuveF5DdVMEJ/KbtWp3Yu/vZQ= sha1:QyWpVXf8PpExI4EV9QIyVGT4fZM=
Xref	csiph.com comp.lang.c++:83002

Show key headers only | View raw

"Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:

> On 11 Feb 2022 14:41, Tim Rentsch wrote:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Rather than thinking about pointer values, it might help to start
>>>> with objects.  [..illustrative examples..]
>>>>
>>>> Casting a pointer to a different type doesn't change what objects
>>>> it can access.  At least, this rule holds in C, [...]
>>>
>>> Really the only issue I had is resolved by the rule that "the array" is
>>> always the smallest enclosing array that contains the thing pointed to
>>> (before any conversions of course).
>>
>> Interesting.  I hadn't thought of it that way before.  Seems right.
>>
>> I should make a clarifying statement about casting not changing
>> what objects can be accessed.  If we have this code fragment
>>
>>      int foo[10][20];
>>      extern void set_elements( int *, size_t, int )
>>
>>      set_elements( (int*) &foo, 10*20, -1 );
>>
>> an argument could be made that set_elements() cannot use pointer
>> arithmetic (including that implied by use of []) on its first
>> argument other than to access between foo[0][0] and foo[0][19] (or
>> to construct a pointer to foo[0][20]).  The reasoning would be that
>> there is no array of 200 elements, so the conditions for address
>> arithmetic would not be met for index values other than between 0 and
>> 20, and so would technically be undefined behavior.
>
> First, for C++20 the above `reinterpret_cast`-expressed-as-C-cast
> suffers from not involving "interconvertible" pointers, as noted in
> 6.8.2/4.4:
>
> "An array object and its first element are not
> pointer-interconvertible, even though they have the same address."

Amusing.  The language guarantees that the addresses line up, and
then says the cast isn't guaranteed to work (apparently that is a
change since C++14) even though it obviously will.  Too funny for
words.

> Formally notes are not part of the formal language specification,
> they're not "normative".  [...]

It seems clear that what the "Note" says follows from other
normative text.

> [...]
>
>>  It would be
>> surprising if that putative undefined behavior would result in the
>> code "doing the wrong thing", but I feel obliged to point out the
>> possible alternative reading nonetheless.
>>
>> Even if the reading proposed above holds, set_elements() can be
>> written in a way that avoids the putative undefined behavior:
>>
>>      void
>>      set_elements( int *v, size_t n, int value ){
>>          while(  n-- > 0  ){
>>              *(int*)( (char*)v + n * sizeof *v ) = value;
>>          }
>>      }
>>
>> This code has to work for the call that passes '(int*)&foo',
>> because all objects have an implied character array that overlays
>> the entire object, which is all of foo in this case.
>
> Again, for C++ (though I understand you're discussing the C case)
> you're colliding with a formal brick wall.
>
> The general consensus is that only `memcpy` plus one more mechanism I
> don't recall now (citing lack of coffee plus excessive blood sugar
> etc.) is sufficiently formally supported to avoid formal UB for
> copying bytes of objects.

There is no copying of bytes in the above code.

> In particular a `reinterpret_cast`, in the above code expressed as a C
> style cast, is a good way to let loose the strict aliasing demons of
> the g++ compiler.  [...]

In the context the above code is used, there are no violations of
type-based aliasing rules.  Hence no "strict aliasing demons".

Thread

C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-04 13:54 +0100
  Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-04 14:25 +0000
    Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-04 15:31 +0100
      Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-04 14:54 +0000
        Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-04 17:41 +0100
          Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-05 11:31 +0000
            Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-05 12:49 +0100
              Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-05 12:20 +0000
      Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-04 16:15 +0000
        Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-04 17:43 +0100
        Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-05 01:51 +0100
          Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-05 01:59 +0000
          Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-04 23:05 -0500
            Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-05 11:56 +0100
              Re: C++20 concepts rocks David Brown <david.brown@hesbynett.no> - 2022-02-05 13:53 +0100
                Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-05 14:12 +0100
                Re: C++20 concepts rocks Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2022-02-12 11:13 -0800
                Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-12 22:18 -0500
                Re: C++20 concepts rocks Richard Damon <Richard@Damon-Family.org> - 2022-02-13 12:51 -0500
                Re: C++20 concepts rocks Paavo Helde <eesnimi@osa.pri.ee> - 2022-02-13 20:16 +0200
                Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-13 14:12 -0500
                Re: C++20 concepts rocks Richard Damon <Richard@Damon-Family.org> - 2022-02-13 16:22 -0500
                Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-13 17:18 -0500
                Re: C++20 concepts rocks Öö Tiib <ootiib@hot.ee> - 2022-02-14 00:51 -0800
                Re: C++20 concepts rocks "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-02-14 08:29 -0800
          Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-04 23:37 -0800
            Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-05 11:58 +0100
              Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-06 02:16 -0800
            Re: C++20 concepts rocks "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-02-05 12:35 -0800
              Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-06 05:54 -0800
              Re: C++20 concepts rocks Manfred <noname@add.invalid> - 2022-02-06 19:43 +0100
        Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-04 23:53 -0800
          Re: C++20 concepts rocks red floyd <no.spam.here@its.invalid> - 2022-02-05 10:10 -0800
            Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-05 19:51 +0100
              Re: C++20 concepts rocks red floyd <no.spam.here@its.invalid> - 2022-02-05 16:42 -0800
                Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-06 01:39 +0000
                Re: C++20 concepts rocks red floyd <no.spam.here@its.invalid> - 2022-02-05 18:02 -0800
                Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-06 09:57 +0100
                Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-06 10:57 +0100
                Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-06 12:40 +0100
                Re: C++20 concepts rocks Öö Tiib <ootiib@hot.ee> - 2022-02-06 03:53 -0800
                Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-06 14:35 +0000
                Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-06 11:20 -0800
                Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-06 21:53 +0000
                Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-06 19:03 -0800
                Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-07 11:50 +0000
                Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-07 06:26 -0800
                Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-07 15:48 +0000
                Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-07 12:16 -0800
                Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-07 22:27 -0800
                Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-09 21:43 +0000
                Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-09 21:07 -0500
                Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-09 21:25 -0800
                Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-10 13:05 +0000
                Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-10 11:19 -0500
                Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-11 05:41 -0800
                Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-11 17:06 +0100
                Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-11 11:50 -0500
                Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-11 21:13 +0100
                Re: C++20 concepts rocks scott@slp53.sl.home (Scott Lurndal) - 2022-02-11 17:06 +0000
                Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-15 00:10 -0800
                Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-15 20:58 +0100
                Re: C++20 concepts rocks Juha Nieminen <nospam@thanks.invalid> - 2022-02-16 06:40 +0000
                Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-16 09:54 +0100
                Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-16 09:00 +0000
                Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-16 20:25 +0100
                Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-17 08:53 +0000
                Re: C++20 concepts rocks Paavo Helde <eesnimi@osa.pri.ee> - 2022-02-17 16:11 +0200
                Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-17 10:58 -0500
                Re: C++20 concepts rocks Juha Nieminen <nospam@thanks.invalid> - 2022-02-17 07:32 +0000
                Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-19 02:21 -0700
                Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-04-19 11:56 +0200
                Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-25 03:02 -0700
                Re: C++20 concepts rocks Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-02-12 00:01 +0000
                Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-14 23:55 -0800
                Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-07 18:31 +0100
                Re: C++20 concepts rocks scott@slp53.sl.home (Scott Lurndal) - 2022-02-07 17:43 +0000
                Re: C++20 concepts rocks James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-02-06 14:25 -0500
                Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-06 02:01 -0800
                Re: C++20 concepts rocks red floyd <no.spam.here@its.invalid> - 2022-02-06 19:37 -0800
                Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-07 10:18 +0100
                Re: C++20 concepts rocks Paavo Helde <eesnimi@osa.pri.ee> - 2022-02-07 11:32 +0200
                Re: C++20 concepts rocks red floyd <no.spam.here@its.invalid> - 2022-02-07 07:55 -0800
            Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-06 02:11 -0800
              Re: C++20 concepts rocks "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-02-06 13:13 +0100
                Re: C++20 concepts rocks Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-06 04:58 -0800
                Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-06 14:08 +0100
        Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-05 12:48 +0100
    Re: C++20 concepts rocks Juha Nieminen <nospam@thanks.invalid> - 2022-02-04 20:15 +0000
      Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-05 11:32 +0000
        Re: C++20 concepts rocks Juha Nieminen <nospam@thanks.invalid> - 2022-02-06 08:28 +0000
          Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-07 09:52 +0000
            Re: C++20 concepts rocks Juha Nieminen <nospam@thanks.invalid> - 2022-02-08 07:05 +0000
              Re: C++20 concepts rocks Muttley@dastardlyhq.com - 2022-02-08 09:25 +0000
                Re: C++20 concepts rocks Juha Nieminen <nospam@thanks.invalid> - 2022-02-08 10:09 +0000
  Re: C++20 concepts rocks Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-02-04 12:10 -0800
    Re: C++20 concepts rocks Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-05 13:41 +0100
      Re: C++20 concepts rocks "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-02-05 19:28 -0800
  A little benchmark: Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-05 13:22 +0100
    A better benchmark Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-06 14:56 +0100
      A improved routine Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-07 15:19 +0100
      Re: A better benchmark Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-02-07 06:57 -0800
        Re: A better benchmark Bonita Montero <Bonita.Montero@gmail.com> - 2022-02-07 18:30 +0100

csiph-web