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

C++20 concepts rocks

Started by	Bonita Montero <Bonita.Montero@gmail.com>
First post	2022-02-04 13:54 +0100
Last post	2022-02-07 18:30 +0100
Articles	20 on this page of 103 — 18 participants

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

  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

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →

#82948

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2022-02-07 10:18 +0100
Message-ID	<stqo4f$97u$2@dont-email.me>
In reply to	#82947

ssize() and size() is what you want.

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

#82949

From	Paavo Helde <eesnimi@osa.pri.ee>
Date	2022-02-07 11:32 +0200
Message-ID	<stqov7$fjv$1@dont-email.me>
In reply to	#82947

07.02.2022 05:37 red floyd kirjutas:
> 
> C++ should define
> 
> template<typename T, size_t N>
> constexpr size_t array_size(T(&)[N]) { return N; }

It does. It's called std::size().

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

#82958

From	red floyd <no.spam.here@its.invalid>
Date	2022-02-07 07:55 -0800
Message-ID	<strfd0$fut$1@redfloyd.dont-email.me>
In reply to	#82949

On 2/7/2022 1:32 AM, Paavo Helde wrote:
> 07.02.2022 05:37 red floyd kirjutas:
>>
>> C++ should define
>>
>> template<typename T, size_t N>
>> constexpr size_t array_size(T(&)[N]) { return N; }
> 
> It does. It's called std::size().

Thanks.  I'm not particularly familiar with C++17 and 20.
Didn't know that.

Then a completely standard compliant way to address it
without the (to me) ugliness would be:

char *ep = result + std::size(result) - 1;

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

#82931

From	Tim Rentsch <tr.17687@z991.linuxsc.com>
Date	2022-02-06 02:11 -0800
Message-ID	<86wni8jodo.fsf@linuxsc.com>
In reply to	#82920

red floyd <no.spam.here@its.invalid> writes:

> On 2/4/2022 11:53 PM, Tim Rentsch wrote:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>
>>>> Am 04.02.2022 um 15:25 schrieb Muttley@dastardlyhq.com:
>>>>
>>>>> On Fri, 4 Feb 2022 13:54:27 +0100
>>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>>
>>>>>> I've just written a small routine:
>>>>>>
>>>>>> [.. some c++ code ..]
>>>>>
>>>>> Thats nice.  Personally I'd just use printf().
>>>>
>>>> You can't do what I did with (s)printf().
>>>
>>> template<typename StringType>
>>> requires is_same_v<StringType,
>>>                     basic_string<typename StringType::value_type,
>>>                                  typename StringType::traits_type,
>>>                                  typename StringType::allocator_type>>
>>> StringType formatClockCycles(uint64_t clockCycles)
>>> {
>>>     char result[28], *ep = (&result)[1];
>>>     do {
>>>        sprintf(ep - 4, "%03lu", clockCycles % 1000);
>>>        if (ep != (&result)[1]) ep[-1] = '.';
>>>        ep -= 4;
>>>     } while (clockCycles /= 1000);
>>>     while (*ep == '0' && ep[1]) ep++;
>>>     return ep;
>>> }
>>>
>>> (the appropriate comment on the 28 is left as an exercise to the reader!)
>>
>> Most of the work can be done using only a single call to sprintf().
>> (Disclaimer:  not compiled.)
>>
>>
>>      template< typename StringType >
>>          requires
>>              is_same_v<
>>                  StringType,
>>                  basic_string<
>>                      typename StringType::value_type,
>>                      typename StringType::traits_type,
>>                      typename StringType::allocator_type
>>                  >
>>              >
>>      StringType
>>      formatClockCycles( uint64_t clockCycles ){
>>          char result[ 27 ];
>>          int n = sprintf( result, "%" PRIu64, clockCycles );
>>          char *ep = (&result)[1];
>>
>>          *--ep = 0;
>>          while(  n > 3  ){
>>              memmove( ep -= 3, &result[ n -= 3 ], 3 );
>>              *--ep = '.';
>>          }
>>          do  *--ep = result[ --n ];  while(  n > 0  );
>>
>>          return  ep;
>>      }
>
> Why the oddly unreadable initialization of ep?

Because it was used in the posting to which I was responding.  I
simply copied it from there, not wanting to confuse matters with
unnecessary changes.

> Why not just
>
>     char *ep = result + sizeof(result)?

My usual practice is a somewhat different construction, suitably
encapsulated so as not to sprinkle idiomatic phrases throughout
the main program text.

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

#82935

From	"Alf P. Steinbach" <alf.p.steinbach@gmail.com>
Date	2022-02-06 13:13 +0100
Message-ID	<stoe1r$6fl$1@dont-email.me>
In reply to	#82931

On 6 Feb 2022 11:11, Tim Rentsch wrote:
> red floyd <no.spam.here@its.invalid> writes:
> 
>> On 2/4/2022 11:53 PM, Tim Rentsch wrote:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>
>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>
>>>>> Am 04.02.2022 um 15:25 schrieb Muttley@dastardlyhq.com:
>>>>>
>>>>>> On Fri, 4 Feb 2022 13:54:27 +0100
>>>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>>>
>>>>>>> I've just written a small routine:
>>>>>>>
>>>>>>> [.. some c++ code ..]
>>>>>>
>>>>>> Thats nice.  Personally I'd just use printf().
>>>>>
>>>>> You can't do what I did with (s)printf().
>>>>
>>>> template<typename StringType>
>>>> requires is_same_v<StringType,
>>>>                      basic_string<typename StringType::value_type,
>>>>                                   typename StringType::traits_type,
>>>>                                   typename StringType::allocator_type>>
>>>> StringType formatClockCycles(uint64_t clockCycles)
>>>> {
>>>>      char result[28], *ep = (&result)[1];
>>>>      do {
>>>>         sprintf(ep - 4, "%03lu", clockCycles % 1000);
>>>>         if (ep != (&result)[1]) ep[-1] = '.';
>>>>         ep -= 4;
>>>>      } while (clockCycles /= 1000);
>>>>      while (*ep == '0' && ep[1]) ep++;
>>>>      return ep;
>>>> }
>>>>
>>>> (the appropriate comment on the 28 is left as an exercise to the reader!)
>>>
>>> Most of the work can be done using only a single call to sprintf().
>>> (Disclaimer:  not compiled.)
>>>
>>>
>>>       template< typename StringType >
>>>           requires
>>>               is_same_v<
>>>                   StringType,
>>>                   basic_string<
>>>                       typename StringType::value_type,
>>>                       typename StringType::traits_type,
>>>                       typename StringType::allocator_type
>>>                   >
>>>               >
>>>       StringType
>>>       formatClockCycles( uint64_t clockCycles ){
>>>           char result[ 27 ];
>>>           int n = sprintf( result, "%" PRIu64, clockCycles );
>>>           char *ep = (&result)[1];
>>>
>>>           *--ep = 0;
>>>           while(  n > 3  ){
>>>               memmove( ep -= 3, &result[ n -= 3 ], 3 );
>>>               *--ep = '.';
>>>           }
>>>           do  *--ep = result[ --n ];  while(  n > 0  );
>>>
>>>           return  ep;
>>>       }
>>
>> Why the oddly unreadable initialization of ep?
> 
> Because it was used in the posting to which I was responding.  I
> simply copied it from there, not wanting to confuse matters with
> unnecessary changes.
> 
>> Why not just
>>
>>      char *ep = result + sizeof(result)?
> 
> My usual practice is a somewhat different construction, suitably
> encapsulated so as not to sprinkle idiomatic phrases throughout
> the main program text.

Consider just using `std::end` rather than a DIY encapsulation.


- Alf

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

#82936

From	Tim Rentsch <tr.17687@z991.linuxsc.com>
Date	2022-02-06 04:58 -0800
Message-ID	<86o83kjgnk.fsf@linuxsc.com>
In reply to	#82935

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

> On 6 Feb 2022 11:11, Tim Rentsch wrote:
>
>> red floyd <no.spam.here@its.invalid> writes:

[...]

>>> Why not just
>>>
>>>      char *ep = result + sizeof(result)?
>>
>> My usual practice is a somewhat different construction, suitably
>> encapsulated so as not to sprinkle idiomatic phrases throughout
>> the main program text.
>
> Consider just using `std::end` rather than a DIY encapsulation.

When feasible, I prefer constructions that work in both
C and C++.

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

#82937

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2022-02-06 14:08 +0100
Message-ID	<stoh8m$1rg$1@dont-email.me>
In reply to	#82936

Am 06.02.2022 um 13:58 schrieb Tim Rentsch:
> "Alf P. Steinbach" <alf.p.steinbach@gmail.com> writes:
> 
>> On 6 Feb 2022 11:11, Tim Rentsch wrote:
>>
>>> red floyd <no.spam.here@its.invalid> writes:
> 
> [...]
> 
>>>> Why not just
>>>>
>>>>       char *ep = result + sizeof(result)?
>>>
>>> My usual practice is a somewhat different construction, suitably
>>> encapsulated so as not to sprinkle idiomatic phrases throughout
>>> the main program text.
>>
>> Consider just using `std::end` rather than a DIY encapsulation.
> 
> When feasible, I prefer constructions that work in both
> C and C++.

Thats compulsive. ;-)

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

#82913

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2022-02-05 12:48 +0100
Message-ID	<stlo62$s9s$1@dont-email.me>
In reply to	#82899

Am 04.02.2022 um 17:15 schrieb Ben Bacarisse:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
> 
>> Am 04.02.2022 um 15:25 schrieb Muttley@dastardlyhq.com:
>>> On Fri, 4 Feb 2022 13:54:27 +0100
>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> I've just written a small routine:
>>>>
>>>> template<typename StringType>
>>>> 	requires is_same_v<StringType, basic_string<typename
>>>> StringType::value_type, typename StringType::traits_type, typename
>>>> StringType::allocator_type>>
>>>> StringType formatClockCycles( uint64_t clockCycles )
>>> Some C++ prototypes are almost comical they're so unreadable.
>>
>> For those who are familiar with concepts that's readable.
>>
>>>> 	using dig_arr_t = array<uint8_t, 20>; // max 20 digits for 64 bit
>>>> 	using dig_arr_it = dig_arr_t::iterator;
>>>> 	dig_arr_t reverseDigits;
>>>> 	dig_arr_it rDigitsEnd = reverseDigits.begin();
>>>> 	do
>>>> 		*rDigitsEnd++ = clockCycles % 10,
>>>> 		clockCycles /= 10;
>>>> 	while( clockCycles );
>>>> 	size_t
>>>> 		digitsLen = rDigitsEnd - reverseDigits.begin(),
>>>> 		groups = (digitsLen - 1) / 3;
>>>> 	StringType str( digitsLen + groups, '\0' );
>>>> 	typename StringType::iterator wrt = str.end();
>>>> 	dig_arr_it digit = reverseDigits.begin();
>>>> 	for( dig_arr_it groupsEnd = reverseDigits.begin() + groups * 3; digit
>>>> != groupsEnd; wrt -= 4, digit += 3 )
>>>> 		wrt[-1] = digit[0] + '0',
>>>> 		wrt[-2] = digit[1] + '0',
>>>> 		wrt[-3] = digit[2] + '0',
>>>> 		wrt[-4] = '.';
>>>> 	do
>>>> 		*--wrt = *digit++ + '0';
>>>> 	while( digit != rDigitsEnd );
>>>> 	return str;
>>>> }
>>>>
>>>> The cool thing here that the concept above doesn't have an error if
>>>> ....::value_type, ...::traits_type and ...::allocator_type are missing;
>>>> I just get an error as if I'd also included a check for the existence
>>>> of these types.
>>> Thats nice. Personally I'd just use printf().
>>
>> You can't do what I did with (s)printf().
> 
> template<typename StringType>
> requires is_same_v<StringType,
>                     basic_string<typename StringType::value_type,
>                                  typename StringType::traits_type,
>                                  typename StringType::allocator_type>>
> StringType formatClockCycles(uint64_t clockCycles)
> {
>     char result[28], *ep = (&result)[1];
>     do {
>        sprintf(ep - 4, "%03lu", clockCycles % 1000);

You're not casting clockCycles % 1000 to an unsigned long.
This results in the codes is only likely to run on little
endian machines.

>        if (ep != (&result)[1]) ep[-1] = '.';
>        ep -= 4;
>     } while (clockCycles /= 1000);
>     while (*ep == '0' && ep[1]) ep++;
>     return ep;
> }
> 
> (the appropriate comment on the 28 is left as an exercise to the reader!)
>

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

#82903

From	Juha Nieminen <nospam@thanks.invalid>
Date	2022-02-04 20:15 +0000
Message-ID	<stk1gn$ttr$1@gioia.aioe.org>
In reply to	#82896

Muttley@dastardlyhq.com wrote:
> On Fri, 4 Feb 2022 13:54:27 +0100
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>I've just written a small routine:
>>
>>template<typename StringType>
>>       requires is_same_v<StringType, basic_string<typename 
>>StringType::value_type, typename StringType::traits_type, typename 
>>StringType::allocator_type>>
>>StringType formatClockCycles( uint64_t clockCycles )
> 
> Some C++ prototypes are almost comical they're so unreadable.

And this comment contributed to the discussion how, exactly?

If you are just going to whine, why don't you go somewhere else to do so?

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

#82912

From	Muttley@dastardlyhq.com
Date	2022-02-05 11:32 +0000
Message-ID	<stln94$1h2q$1@gioia.aioe.org>
In reply to	#82903

On Fri, 4 Feb 2022 20:15:21 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
>Muttley@dastardlyhq.com wrote:
>> On Fri, 4 Feb 2022 13:54:27 +0100
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>I've just written a small routine:
>>>
>>>template<typename StringType>
>>>       requires is_same_v<StringType, basic_string<typename 
>>>StringType::value_type, typename StringType::traits_type, typename 
>>>StringType::allocator_type>>
>>>StringType formatClockCycles( uint64_t clockCycles )
>> 
>> Some C++ prototypes are almost comical they're so unreadable.
>
>And this comment contributed to the discussion how, exactly?

Its a comment on C++ syntax. Last time I looked this was a C++ group.

>If you are just going to whine, why don't you go somewhere else to do so?

You clearly don't understand what "whine" means. Also I'll let you figure out
the irony of your comment.

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

#82927

From	Juha Nieminen <nospam@thanks.invalid>
Date	2022-02-06 08:28 +0000
Message-ID	<sto0s0$1uni$1@gioia.aioe.org>
In reply to	#82912

Muttley@dastardlyhq.com wrote:
> On Fri, 4 Feb 2022 20:15:21 -0000 (UTC)
> Juha Nieminen <nospam@thanks.invalid> wrote:
>>Muttley@dastardlyhq.com wrote:
>>> On Fri, 4 Feb 2022 13:54:27 +0100
>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>I've just written a small routine:
>>>>
>>>>template<typename StringType>
>>>>       requires is_same_v<StringType, basic_string<typename 
>>>>StringType::value_type, typename StringType::traits_type, typename 
>>>>StringType::allocator_type>>
>>>>StringType formatClockCycles( uint64_t clockCycles )
>>> 
>>> Some C++ prototypes are almost comical they're so unreadable.
>>
>>And this comment contributed to the discussion how, exactly?
> 
> Its a comment on C++ syntax. Last time I looked this was a C++ group.

And that helped who and how, exactly?

>>If you are just going to whine, why don't you go somewhere else to do so?
> 
> You clearly don't understand what "whine" means. Also I'll let you figure out
> the irony of your comment.

It sounded a lot like you whining about you not liking some syntax, instead
of saying something constructive and which actually adds something to the
discussion.

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

#82950

From	Muttley@dastardlyhq.com
Date	2022-02-07 09:52 +0000
Message-ID	<stqq5a$1mec$1@gioia.aioe.org>
In reply to	#82927

On Sun, 6 Feb 2022 08:28:50 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
>Muttley@dastardlyhq.com wrote:
>> On Fri, 4 Feb 2022 20:15:21 -0000 (UTC)
>> Juha Nieminen <nospam@thanks.invalid> wrote:
>>>Muttley@dastardlyhq.com wrote:
>>>> On Fri, 4 Feb 2022 13:54:27 +0100
>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>>I've just written a small routine:
>>>>>
>>>>>template<typename StringType>
>>>>>       requires is_same_v<StringType, basic_string<typename 
>>>>>StringType::value_type, typename StringType::traits_type, typename 
>>>>>StringType::allocator_type>>
>>>>>StringType formatClockCycles( uint64_t clockCycles )
>>>> 
>>>> Some C++ prototypes are almost comical they're so unreadable.
>>>
>>>And this comment contributed to the discussion how, exactly?
>> 
>> Its a comment on C++ syntax. Last time I looked this was a C++ group.
>
>And that helped who and how, exactly?

How is your moaning now helping anyone?

>>>If you are just going to whine, why don't you go somewhere else to do so?
>> 
>> You clearly don't understand what "whine" means. Also I'll let you figure out
>
>> the irony of your comment.
>
>It sounded a lot like you whining about you not liking some syntax, instead
>of saying something constructive and which actually adds something to the
>discussion.

Oh ok, so we only say nice things about C++ do we snowflake? Got it.

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

#82965

From	Juha Nieminen <nospam@thanks.invalid>
Date	2022-02-08 07:05 +0000
Message-ID	<stt4n3$1rg2$1@gioia.aioe.org>
In reply to	#82950

Muttley@dastardlyhq.com wrote:
>>It sounded a lot like you whining about you not liking some syntax, instead
>>of saying something constructive and which actually adds something to the
>>discussion.
> 
> Oh ok, so we only say nice things about C++ do we snowflake? Got it.

It seems that you have difficulty in understanding what "something
contructive that actually adds something to the discussion" means.

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

#82968

From	Muttley@dastardlyhq.com
Date	2022-02-08 09:25 +0000
Message-ID	<sttcue$1gqm$1@gioia.aioe.org>
In reply to	#82965

On Tue, 8 Feb 2022 07:05:09 -0000 (UTC)
Juha Nieminen <nospam@thanks.invalid> wrote:
>Muttley@dastardlyhq.com wrote:
>>>It sounded a lot like you whining about you not liking some syntax, instead
>>>of saying something constructive and which actually adds something to the
>>>discussion.
>> 
>> Oh ok, so we only say nice things about C++ do we snowflake? Got it.
>
>It seems that you have difficulty in understanding what "something
>contructive that actually adds something to the discussion" means.

Why don't you take your own advice and shut up then?

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

#82969

From	Juha Nieminen <nospam@thanks.invalid>
Date	2022-02-08 10:09 +0000
Message-ID	<sttfh3$nmh$1@gioia.aioe.org>
In reply to	#82968

Muttley@dastardlyhq.com wrote:
> On Tue, 8 Feb 2022 07:05:09 -0000 (UTC)
> Juha Nieminen <nospam@thanks.invalid> wrote:
>>Muttley@dastardlyhq.com wrote:
>>>>It sounded a lot like you whining about you not liking some syntax, instead
>>>>of saying something constructive and which actually adds something to the
>>>>discussion.
>>> 
>>> Oh ok, so we only say nice things about C++ do we snowflake? Got it.
>>
>>It seems that you have difficulty in understanding what "something
>>contructive that actually adds something to the discussion" means.
> 
> Why don't you take your own advice and shut up then?

Perhaps because it's fun to see how long you will keep up responding,
without being able to stop without having the last word.

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

#82902

From	Andrey Tarasevich <andreytarasevich@hotmail.com>
Date	2022-02-04 12:10 -0800
Message-ID	<stk17i$pad$1@dont-email.me>
In reply to	#82895

On 2/4/2022 4:54 AM, Bonita Montero wrote:
> The cool thing here that the concept above doesn't have an error if
> ...::value_type, ...::traits_type and ...::allocator_type are missing;

Why would it? To a large degree concepts are just glorified SFINAE. You 
are simply seeing the NAE in SFINAE.

-- 
Best regards,
Andrey Tarasevich

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

#82917

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2022-02-05 13:41 +0100
Message-ID	<stlr9d$e4l$1@dont-email.me>
In reply to	#82902

Am 04.02.2022 um 21:10 schrieb Andrey Tarasevich:
> On 2/4/2022 4:54 AM, Bonita Montero wrote:
>> The cool thing here that the concept above doesn't have an error if
>> ...::value_type, ...::traits_type and ...::allocator_type are missing;
> 
> Why would it? To a large degree concepts are just glorified SFINAE.
> You are simply seeing the NAE in SFINAE.

Right, that's NAE. I've overseen that.

But wrong, concepts arent't such a gorified SFINAE since it
is much more complicated to to the same things you can do
with concepts with SFINAE.

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

#82926

From	"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date	2022-02-05 19:28 -0800
Message-ID	<stnf95$h3s$1@dont-email.me>
In reply to	#82917

On 2/5/2022 4:41 AM, Bonita Montero wrote:
> Am 04.02.2022 um 21:10 schrieb Andrey Tarasevich:
>> On 2/4/2022 4:54 AM, Bonita Montero wrote:
>>> The cool thing here that the concept above doesn't have an error if
>>> ...::value_type, ...::traits_type and ...::allocator_type are missing;
>>
>> Why would it? To a large degree concepts are just glorified SFINAE.
>> You are simply seeing the NAE in SFINAE.
> 
> Right, that's NAE. I've overseen that.

Wow! I remember when you were steadfast in your believe of certian 
things that turned out to be totally wrong. Your comment here is very 
good. :^D

> 
> But wrong, concepts arent't such a gorified SFINAE since it
> is much more complicated to to the same things you can do
> with concepts with SFINAE.

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

#82916 — A little benchmark:

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2022-02-05 13:22 +0100
Subject	A little benchmark:
Message-ID	<stlq6s$8pc$1@dont-email.me>
In reply to	#82895

Here's a little benchmark of mine, Tim's and Ben's variant:
I've stipped the construction of the strging-object because
the memory-allocation could be a major part of the operation.
So I'm just returning a pointer into thread local memory.

#include <iostream>
#include <concepts>
#include <array>
#include <cstdio>
#include <cstring>
#include <chrono>
#include <random>

using namespace std;
using namespace chrono;

#if defined(_MSC_VER)
	#pragma warning(disable : 4996) // disable deprecated sprintf
	#pragma warning(disable : 6200) // array out of range
#endif

template<typename char_t>
	requires same_as<char_t, char> || same_as<char_t, wchar_t>
char_t *formatClockCyclesMine( uint64_t clockCycles );
char *formatClockCyclesTim( uint64_t clockCycles );
char *formatClockCyclesBen( uint64_t clockCycles );

int main()
{
	auto bench = []<typename FccFn>( FccFn fn )
		requires requires( FccFn fn, uint64_t clockCycles ) { { fn( 
clockCycles ) } -> same_as<char *>; }
	{
		static size_t const N = 10'000'000;
		char volatile sum = 0;
		mt19937_64 mt;
		uniform_int_distribution<uint64_t> uid( 0, -1 );
		auto start = high_resolution_clock::now();
		for( size_t n = N; n--; )
			sum += *fn( uid( mt ) + (char)sum );
		return (double)(int64_t)duration_cast<nanoseconds>( 
high_resolution_clock::now() - start ).count() / (double)N;
	};
	cout << "mine: " << bench( &formatClockCyclesMine<char> ) << endl;
	cout << "Tim:  " << bench( formatClockCyclesTim ) << endl;
	cout << "Ben:  " << bench( formatClockCyclesBen ) << endl;
}

#if defined(_MSC_VER)
	#define NOINLINE __declspec(noinline)
#elif defined(__GNUC__) || defined(__llvm__)
	#define NOINLINE __attribute__((noinline))
#endif

template<typename char_t>
	requires same_as<char_t, char> || same_as<char_t, wchar_t>
NOINLINE
char_t *formatClockCyclesMine( uint64_t clockCycles )
{
	using dig_arr_t = array<uint8_t, 20>; // max 20 digits for 64 bit
	using dig_arr_it = typename dig_arr_t::iterator;
	dig_arr_t reverseDigits;
	dig_arr_it rDigitsEnd = reverseDigits.begin();
	do
		*rDigitsEnd++ = clockCycles % 10,
		clockCycles /= 10;
	while( clockCycles );
	size_t
		digitsLen = rDigitsEnd - reverseDigits.begin(),
		groups = (digitsLen - 1) / 3;
	using str_arr_t = array<char_t, 20 + (20 - 1) / 3 + 1>;
	using str_arr_it = typename str_arr_t::iterator;
	thread_local str_arr_t str;
	str_arr_it wrt = str.begin() + digitsLen + groups;
	*wrt = '\0';
	dig_arr_it digit = reverseDigits.begin();
	for( dig_arr_it groupsEnd = reverseDigits.begin() + groups * 3; digit 
!= groupsEnd; wrt -= 4, digit += 3 )
		wrt[-1] = digit[0] + '0',
		wrt[-2] = digit[1] + '0',
		wrt[-3] = digit[2] + '0',
		wrt[-4] = '.';
	do
		*--wrt = *digit++ + '0';
	while( digit != rDigitsEnd );
	return &*wrt;
	}

NOINLINE
char *formatClockCyclesTim( uint64_t clockCycles )
{
	thread_local char result[20 + (20 - 1) / 3 + 1];
	size_t n = (unsigned)sprintf( result, "%llu", (unsigned long 
long)clockCycles );
	char *ep = (&result)[1];
	*--ep = 0;
	while( n > 3 )
		memmove( ep -= 3, &result[n -= 3], 3 ),
		*--ep = '.';
	do
		*--ep = result[--n];
	while( n );
     return ep;
}

NOINLINE
char *formatClockCyclesBen( uint64_t clockCycles )
{
	thread_local char result[20 + (20 - 1) / 3 + 1];
	char *ep = (&result)[1];
	do
	{
		// initially with a missing cast, actually would have run only on 
little endian machines
		sprintf( ep - 4, "%03lu", (unsigned long)(clockCycles % 1000) );
		if( ep != (&result)[1] )
			ep[-1] = '.';
		ep -= 4;
	} while( clockCycles /= 1000 );
	for( ; *ep == '0' && ep[1]; ++ep );
	return ep;
}

These are the results with MSVC in ns per operation:

MSVC 2022:
	mine: 45.8883
	Tim:  129.673
	Ben:  562.441

g++ 11.1.0:
	mine: 46.0794
	Tim:  128.617
	Ben:  586.362

clang++ 10.0.0:
	mine: 42.8998
	Tim:  110.695
	Ben:  580.442

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

#82939 — A better benchmark

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2022-02-06 14:56 +0100
Subject	A better benchmark
Message-ID	<stok2f$eg7$1@dont-email.me>
In reply to	#82916

Now I have an even distribution from 1 to 20 digits.

#include <iostream>
#include <concepts>
#include <array>
#include <cstdio>
#include <cstring>
#include <chrono>
#include <vector>
#include <random>

using namespace std;
using namespace chrono;

#if defined(_MSC_VER)
	#pragma warning(disable : 4996) // disable deprecated sprintf
	#pragma warning(disable : 6200) // array out of range
#endif

template<typename char_t>
	requires same_as<char_t, char> || same_as<char_t, wchar_t>
char_t const *formatClockCyclesMine( uint64_t clockCycles );
char const *formatClockCyclesTim( uint64_t clockCycles );
char const *formatClockCyclesBen( uint64_t clockCycles );

int main()
{
	auto bench = []<typename FccFn>( FccFn fn )
		requires requires( FccFn fn, uint64_t clockCycles ) { { *fn( 
clockCycles ) } -> convertible_to<char>; }
	{
		static size_t const N_VALUES = 10'000, N = 1'000;
		vector<uint64_t> values( N_VALUES );
		mt19937_64 mt;
		uniform_int_distribution<size_t> uidLength( 1, 20 );
		uniform_int_distribution<unsigned> uidDigit( 0, 9 );
		auto getNumber = [&]() -> uint64_t
		{
			uint64_t number = 0, nextNumber;
			size_t initialLength = uidLength( mt ), length = initialLength;
			unsigned digit;
			do
				if( (nextNumber = number * 10 + (digit = uidDigit( mt ))) >= number )
					number = nextNumber;
				else
					number = 0,
					length = initialLength + 1;
			while( --length );
			return number;
		};
		for( uint64_t &v : values )
			v = getNumber();
		char volatile sum = 0;
		auto start = high_resolution_clock::now();
		for( size_t n = N; n--; )
			for( uint64_t v : values )
				sum += *fn( v );
		return (double)(int64_t)duration_cast<nanoseconds>( 
high_resolution_clock::now() - start ).count() / ((double)N * 
(double)N_VALUES);
	};
	cout << "mine: " << bench( formatClockCyclesMine<char> ) << endl;
	cout << "Tim:  " << bench( formatClockCyclesTim ) << endl;
	cout << "Ben:  " << bench( formatClockCyclesBen ) << endl;
}

#if defined(_MSC_VER)
	#define NOINLINE __declspec(noinline)
#elif defined(__GNUC__) || defined(__llvm__)
	#define NOINLINE __attribute__((noinline))
#elif
	#define NOINLINE
#endif

template<typename char_t>
	requires same_as<char_t, char> || same_as<char_t, wchar_t>
NOINLINE
char_t const *formatClockCyclesMine( uint64_t clockCycles )
{
	using dig_arr_t = array<uint8_t, 20>; // max 20 digits for 64 bit
	using dig_arr_it = typename dig_arr_t::iterator;
	dig_arr_t reverseDigits;
	dig_arr_it rDigitsEnd = reverseDigits.begin();
	do
		*rDigitsEnd++ = clockCycles % 10,
		clockCycles /= 10;
	while( clockCycles );
	size_t
		digitsLen = rDigitsEnd - reverseDigits.begin(),
		groups = (digitsLen - 1) / 3;
	using str_arr_t = array<char_t, 20 + (20 - 1) / 3 + 1>;
	using str_arr_it = typename str_arr_t::iterator;
	thread_local str_arr_t str;
	str_arr_it wrt = str.begin() + digitsLen + groups;
	*wrt = '\0';
	dig_arr_it digit = reverseDigits.begin();
	for( dig_arr_it groupsEnd = reverseDigits.begin() + groups * 3; digit 
!= groupsEnd; wrt -= 4, digit += 3 )
		wrt[-1] = digit[0] + '0',
		wrt[-2] = digit[1] + '0',
		wrt[-3] = digit[2] + '0',
		wrt[-4] = '.';
	do
		*--wrt = *digit++ + '0';
	while( digit != rDigitsEnd );
	return &*wrt;
}

NOINLINE
char const *formatClockCyclesTim( uint64_t clockCycles )
{
	thread_local char result[20 + (20 - 1) / 3 + 1];
	size_t n = (unsigned)sprintf( result, "%llu", (unsigned long 
long)clockCycles );
	char *ep = (&result)[1];
	*--ep = 0;
	while( n > 3 )
		memmove( ep -= 3, &result[n -= 3], 3 ),
		*--ep = '.';
	do
		*--ep = result[--n];
	while( n );
     return ep;
}

NOINLINE
char const *formatClockCyclesBen( uint64_t clockCycles )
{
	thread_local char result[20 + (20 - 1) / 3 + 1];
	char *ep = (&result)[1];
	do
	{
		// initially with a missing cast, actually would have run only on 
little endian machines
		sprintf( ep - 4, "%03lu", (unsigned long)(clockCycles % 1000) );
		if( ep != (&result)[1] )
			ep[-1] = '.';
		ep -= 4;
	} while( clockCycles /= 1000 );
	for( ; *ep == '0' && ep[1]; ++ep );
	return ep;
}

These are the resuls:

MSVC 2022:
	mine: 29.8306
	Tim:  109.97
	Ben:  320.64

g++ 11.1.0:
	mine: 28.3386
	Tim:  110.586
	Ben:  317.135

clang++ 10.0.0:
	mine: 29.7089
	Tim:  100.721
	Ben:  311.768

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

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →

csiph-web

C++20 concepts rocks

Contents

#82948

#82949

#82958

#82931

#82935

#82936

#82937

#82913

#82903

#82912

#82927

#82950

#82965

#82968

#82969

#82902

#82917

#82926

#82916 — A little benchmark:

#82939 — A better benchmark