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

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

Re: Constexpr evaluation of heavy stuff

Show all headers | View raw

On 5/22/2022 11:23 PM, Alf P. Steinbach wrote:
> 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).
> 

True, pointer differences are one of the problems 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.

Well, obviously it wouldn't be like "just any other array". However, I 
wouldn't call "dumbness" the possibility of using /some/ standard 
library features (like find()) with it.

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

"Unthinking" is obviously out of the picture here - if you are 
programming a system where most of the available memory is dedicated to 
one text buffer, clearly you have to think about how you are using it.
"Special considerations", however, do not necessarily mean that you 
happily discard all of the standard library features with its use.

Just to be clear, having such a system is a rare event. However, since 
you mention embedded, having tight hardware constraints on these 
architectures is not that rare an event.

(Incidentally, I still happily use a 32-bit Linux laptop)

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

Read it, thanks for sharing.
I find that the most convincing point is about signed/unsigned mixed 
arithmetic. Which is a good reason to introduce ssize_t.
Still, throwing away size_t entirely? Hmm, still dubious.

Again, we are talking about the standard library here, which is supposed 
to run /everywhere/, and serve a very broad spectrum of goals. It is 
inherently different from developing any specific application.

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