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

Groups > comp.lang.c++ > #84240

Re: Constexpr evaluation of heavy stuff

Show all headers | View raw

On 22 May 2022 21:46, Manfred wrote:
> On 5/22/2022 8:24 AM, Öö Tiib wrote:
>> On Saturday, 21 May 2022 at 22:56:22 UTC+3, Manfred wrote:
>>> On 5/20/2022 9:31 PM, Paavo Helde wrote:
>>>> 20.05.2022 19:57 Christian Gollwitzer kirjutas:
>>>>> Am 20.05.22 um 16:15 schrieb Paavo Helde:
>>>>>> 20.05.2022 16:33 Öö Tiib kirjutas:
>>>>>>
>>>>>>> Modular arithmetic around likes of 42949672956 however is typically
>>>>>>> utterly useless.
>>>>>> I agree in general, but I have found one use case. Suppose we have a
>>>>>> string s which might or might not contain a separator like ':' and we
>>>>>> want to either return the part after separator, or the whole string
>>>>>> if there is no separator. This is the code:
>>>>>>
>>>>>> return s.substr(s.find(':')+1);
>>>>>>
>>>>> And where exactly do you need mod "ridiculous number" here? WHy is
>>>>> that better than having a signed index variable, where negative values
>>>>> indicate invalid indices?
>>>>
>>>> You are right, if std::string::find() returned a signed integer -1 for
>>>> no-find, this code would work just as fine. The only thing is that it
>>>> doesn't work that way, it returns size_t(-1) which is typically
>>>> 18446744073709551615ULL nowadays.
>>> But your example is still valid: size_t(-1) + 1 yields the correct value
>>> because of unsigned wrapping, which is defined behaviour. For the rest,
>>> using an unsigned number as an index inside a string makes sense,
>>> especially in the standard library - a signed type would waste half its
>>> range for this use.
>>
>> The history shows that either half of that range is enough or way too 
>> short.
>> So where 7 bit ASCII is not enough there usage of 16 bit UCS-2 can become
>> obsolete decade later.
> 
> Your example about character sets is wrong, however I may agree that 
> your argument about size distribution is often valid for application 
> development - or rather most of it.
> But, as I wrote, this is part of the standard library, where efficiency 
> is a must.
> 
> So, no, gratuitous waste of half the range is not acceptable in the 
> standard library.
> 
> Especially in a case like this, where there is a trivial solution to 
> that, which by the way is the one adopted by the standard.

That was (and for embedded possibly still is) in support of 16-bit systems.

And that support is half-baked with the pointer difference type being 
signed, and therefore required to be at least 17 bits (not joking here).

When you have an array of bytes that fills up more than half the address 
range (not very common) and you feel the urgent need to treat it 
code-wise as just any other array, nothing special, no ma!, well, dumbness.

Of course it's OK to not use half of the possible size range for the 
direct size representation (it comes into play in other contexts). As a 
concrete example, it's decidedly OK on a 64-bit system. And as another 
concrete example, it was OK in 32-bit Windows, where half the range was 
all you had available anyway without very special configuration, which I 
believe was quite risky. It can be more difficult to argue in favor of 
unsigned sizes for the cases of 32-bit Linux and 16-bit embedded. But 
the former is a hopefully soon extinct beast, and the latter requires 
special considerations anyway, not just unthinking use of vanilla C++.

I gather that that reality is very much part of why the language 
designer Bjarne Stroustrup says it's OK with that apparent/alleged range 
waste, and a mistake to use unsigned for sizes. For example, Bjarne is 
one of the three main authors of the C++ Core Guidelines that recommends 
signed types for numbers. He's even written a paper titled "Subscripts 
and sizes should be signed", available at <url: 
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1428r0.pdf>; 
please read it.



Cheers,

- Alf

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Constexpr evaluation of heavy stuff Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-18 16:17 -0700
  Re: Constexpr evaluation of heavy stuff "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-19 09:19 +0200
    Re: Constexpr evaluation of heavy stuff David Brown <david.brown@hesbynett.no> - 2022-05-19 11:59 +0200
      Re: Constexpr evaluation of heavy stuff "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-19 12:37 +0200
        Re: Constexpr evaluation of heavy stuff David Brown <david.brown@hesbynett.no> - 2022-05-19 14:49 +0200
          Re: Constexpr evaluation of heavy stuff Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-19 06:19 -0700
            Re: Constexpr evaluation of heavy stuff Paavo Helde <eesnimi@osa.pri.ee> - 2022-05-19 20:32 +0300
              Re: Constexpr evaluation of heavy stuff Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-20 01:12 -0700
                Re: Constexpr evaluation of heavy stuff Juha Nieminen <nospam@thanks.invalid> - 2022-05-20 08:37 +0000
                Re: Constexpr evaluation of heavy stuff Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-20 02:21 -0700
                Re: Constexpr evaluation of heavy stuff Ben <ben.usenet@bsb.me.uk> - 2022-05-20 11:25 +0100
                Re: Constexpr evaluation of heavy stuff David Brown <david.brown@hesbynett.no> - 2022-05-20 12:47 +0200
                Re: Constexpr evaluation of heavy stuff Ben <ben.usenet@bsb.me.uk> - 2022-05-20 12:13 +0100
                Re: Constexpr evaluation of heavy stuff David Brown <david.brown@hesbynett.no> - 2022-05-20 14:27 +0200
                Re: Constexpr evaluation of heavy stuff Öö Tiib <ootiib@hot.ee> - 2022-05-20 06:33 -0700
                Re: Constexpr evaluation of heavy stuff Paavo Helde <eesnimi@osa.pri.ee> - 2022-05-20 17:15 +0300
                Re: Constexpr evaluation of heavy stuff Christian Gollwitzer <auriocus@gmx.de> - 2022-05-20 18:57 +0200
                Re: Constexpr evaluation of heavy stuff Paavo Helde <eesnimi@osa.pri.ee> - 2022-05-20 22:31 +0300
                Re: Constexpr evaluation of heavy stuff Manfred <noname@add.invalid> - 2022-05-21 21:56 +0200
                Re: Constexpr evaluation of heavy stuff Öö Tiib <ootiib@hot.ee> - 2022-05-21 23:24 -0700
                Re: Constexpr evaluation of heavy stuff Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-22 04:56 -0700
                Re: Constexpr evaluation of heavy stuff Öö Tiib <ootiib@hot.ee> - 2022-05-22 06:15 -0700
                Re: Constexpr evaluation of heavy stuff Manfred <noname@add.invalid> - 2022-05-22 21:46 +0200
                Re: Constexpr evaluation of heavy stuff "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-22 23:23 +0200
                Re: Constexpr evaluation of heavy stuff Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-22 16:26 -0700
                Re: Constexpr evaluation of heavy stuff Manfred <noname@add.invalid> - 2022-05-23 17:24 +0200
                Re: Constexpr evaluation of heavy stuff Richard Damon <Richard@Damon-Family.org> - 2022-05-23 19:41 -0400
                Re: Constexpr evaluation of heavy stuff scott@slp53.sl.home (Scott Lurndal) - 2022-05-24 16:15 +0000
                Re: Constexpr evaluation of heavy stuff Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-05-24 05:37 -0700
                Re: Constexpr evaluation of heavy stuff Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-05-20 04:19 -0700
                Re: Constexpr evaluation of heavy stuff Ben <ben.usenet@bsb.me.uk> - 2022-05-20 12:32 +0100
                Re: Constexpr evaluation of heavy stuff Juha Nieminen <nospam@thanks.invalid> - 2022-05-20 10:40 +0000
                Re: Constexpr evaluation of heavy stuff David Brown <david.brown@hesbynett.no> - 2022-05-20 12:31 +0200
                Re: Constexpr evaluation of heavy stuff Juha Nieminen <nospam@thanks.invalid> - 2022-05-20 10:43 +0000
                Re: Constexpr evaluation of heavy stuff David Brown <david.brown@hesbynett.no> - 2022-05-20 14:52 +0200
          Re: Constexpr evaluation of heavy stuff "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-19 15:34 +0200
    Re: Constexpr evaluation of heavy stuff "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-19 17:03 +0200
  Re: Constexpr evaluation of heavy stuff Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-05-19 08:53 -0700
    Re: Constexpr evaluation of heavy stuff Marcel Mueller <news.5.maazl@spamgourmet.org> - 2022-05-19 18:33 +0200

csiph-web