Oh yeah. Their work LOL.

Working on 7 years for nothing but a completely utter historical mistake like std::format, charconv instead of finding a solution to fix iostream? Std::addressof a C++11 feature only made freestanding after C++23?

Exceptions being a completely joke even before I was born?

What are the work WG21 is doing?

I think I have very right to attack and insult politicians in WG21.

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

From: Jonathan Wakely<mailto:cxx_at_[hidden]>
Sent: Sunday, September 3, 2023 04:25
To: C++ Proposals<mailto:std-proposals_at_[hidden]>
Cc: trtaab trtaab<mailto:tvfvof_at_[hidden]>
Subject: Re: [std-proposals] Std-Proposals Digest, Vol 54, Issue 17


On Sun, 3 Sept 2023, 02:21 trtaab trtaab via Std-Proposals, <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
Yes std::addressof does. Because they need to work in constexpr context. That is why all standard library implements it with __builtin_addressof

std::addressof is only freestanding after C++23 which means you cannot reliably get address of object in freestanding.

WG21 definitely fucks up for freestanding.

For once in your life can you just stop attacking and insulting other people for their work not living up to your expectations?

You contribute nothing of value to the community, just a terrible attitude and toxic behaviour. Nobody is going to be motivated to solve your problems because you can't discuss them reasonably.








Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

From: std-proposals-request_at_[hidden]<mailto:std-proposals-request_at_[hidden]>
Sent: Saturday, September 2, 2023 21:19
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Subject: Std-Proposals Digest, Vol 54, Issue 17

Send Std-Proposals mailing list submissions to
        std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
or, via email, send a message with subject or body 'help' to
        std-proposals-request_at_[hidden]<mailto:std-proposals-request_at_[hidden]>

You can reach the person managing the list at
        std-proposals-owner_at_[hidden]<mailto:std-proposals-owner_at_[hidden]>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Std-Proposals digest..."


Today's Topics:

   1. Re: PR: std::allocator<T>::allocate is not freestanding
      (Jason McKesson)
   2. Re: PR: std::allocator<T>::allocate is not freestanding
      (Jens Maurer)
   3. Re: PR: std::allocator<T>::allocate is not freestanding
      (Frederick Virchanza Gotham)
   4. Re: Make std::bitset a C++20 range? (Julien Jorge)
   5. Re: PR: std::allocator<T>::allocate is not freestanding
      (connor horman)
   6. Re: Std-Proposals Digest, Vol 54, Issue 16 (trtaab trtaab)


----------------------------------------------------------------------

Message: 1
Date: Sat, 2 Sep 2023 17:36:14 -0400
From: Jason McKesson <jmckesson_at_[hidden]<mailto:jmckesson_at_[hidden]>>
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Subject: Re: [std-proposals] PR: std::allocator<T>::allocate is not
        freestanding
Message-ID:
        <CANLtd3UmjfiFf86gj4LUPe8vvLNKvNJD3eNSZVkfPoEF=CmKPA_at_[hidden]<mailto:CmKPA_at_[hidden]>>
Content-Type: text/plain; charset="UTF-8"

On Sat, Sep 2, 2023 at 3:22?PM trtaab trtaab via Std-Proposals
<std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
>
> Currently there is no way to allocate memory at constexpr context in freestanding environment. This desperately needs a fix.
>
>
>
> N4958 does not mark std::allocator<T> as freestanding so there is no way to allocate memory in freestanding.
>
>
>
> This is std::addressof situation 2.0

Not really.

`addressof` is something that doesn't require any real language
support; it's just a trick to get around an unfortunate language
feature. It *should* be required for freestanding implementations.

The ability to allocate memory at compile-time requires language
support. As such, *requiring* all freestanding implementations to
support it is a rather big ask.

It should also be noted that freestanding requirements are just that:
requirements. Freestanding implementations have to implement those
things, but they can *choose* to implement more of the standard
library than the bare minimum that is required. So if your
freestanding implementation doesn't offer compile-time allocation,
maybe complaining to the implementers would be better.


------------------------------

Message: 2
Date: Sun, 3 Sep 2023 00:00:39 +0200
From: Jens Maurer <jens.maurer_at_[hidden]<mailto:jens.maurer_at_[hidden]>>
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Subject: Re: [std-proposals] PR: std::allocator<T>::allocate is not
        freestanding
Message-ID: <51e5cc06-ae26-2def-a855-3ee9e6501660_at_[hidden]<mailto:51e5cc06-ae26-2def-a855-3ee9e6501660_at_[hidden]>>
Content-Type: text/plain; charset=UTF-8



On 02/09/2023 23.36, Jason McKesson via Std-Proposals wrote:
> On Sat, Sep 2, 2023 at 3:22?PM trtaab trtaab via Std-Proposals
> <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
>>
>> Currently there is no way to allocate memory at constexpr context in freestanding environment. This desperately needs a fix.
>>
>>
>>
>> N4958 does not mark std::allocator<T> as freestanding so there is no way to allocate memory in freestanding.
>>

> The ability to allocate memory at compile-time requires language
> support. As such, *requiring* all freestanding implementations to
> support it is a rather big ask.

In general, the "freestanding" subset of C++ is a library subset
to accommodate environments where an operating system might not
be available, or that are otherwise constrained. For example,
std::cout will probably never be part of freestanding
(because e.g. a fridge does not have that).

The language, however, needs to be supported by freestanding
implementations in its entirety, and that includes full
support for constant evaluation.

Jens


------------------------------

Message: 3
Date: Sat, 2 Sep 2023 23:09:58 +0100
From: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]<mailto:cauldwell.thomas_at_[hidden]>>
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Subject: Re: [std-proposals] PR: std::allocator<T>::allocate is not
        freestanding
Message-ID:
        <CALtZhhM3QnSYNbM7i99FQtUpMbs4y6Ax4jq-KwOKazsFJ+GAnQ_at_[hidden]<mailto:CALtZhhM3QnSYNbM7i99FQtUpMbs4y6Ax4jq-KwOKazsFJ%2BGAnQ_at_[hidden]>>
Content-Type: text/plain; charset="UTF-8"

On Sat, Sep 2, 2023 at 11:00?PM Jens Maurer wrote:
>
> In general, the "freestanding" subset of C++ is a library subset
> to accommodate environments where an operating system might not
> be available, or that are otherwise constrained. For example,
> std::cout will probably never be part of freestanding
> (because e.g. a fridge does not have that).


I'm programming an Arduino microcontroller here right now, and I have
it set up so that I can use 'cout' as follows:

class Flush {} flush;
std::ostream &operator<<(std::ostream &os, Flush const &f) {
Serial.flush(); return os; }
std::ostream &operator<<(std::ostream &os, String const &s) { return
os << s.c_str(); }
extern "C" int _write(int const fd, char const *const ptr, int const len)
{
  (void)fd;
  return Serial.write(ptr, len);
}


------------------------------

Message: 4
Date: Sun, 03 Sep 2023 00:29:06 +0200
From: Julien Jorge <julien.jorge_at_[hidden]<mailto:julien.jorge_at_[hidden]>>
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>, Arthur O'Dwyer via Std-Proposals
        <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Subject: Re: [std-proposals] Make std::bitset a C++20 range?
Message-ID: <0391B03F-4B9D-4D8F-A51F-AFEE8757F507_at_[hidden]<mailto:0391B03F-4B9D-4D8F-A51F-AFEE8757F507_at_[hidden]>>
Content-Type: text/plain; charset=utf-8

Le 30 ao?t 2023 19:49:43 GMT+02:00, Arthur O'Dwyer via Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> a ?crit?:
> Bad idea. See
> https://quuxplusone.github.io/blog/2022/11/05/bit-vectors/#from-the-vantage-point-of-2022-y
>> If you were going to iterate over the ?contents? of such an object, what
>> would you expect to see?
>> std::bitset<1000> bs;
>> bs.set(42);
>> for (auto elt : bs) {
>> std::cout << bs;
>> }
>> Surely you wouldn?t expect to see ?false, false, false, false, ??!

Why would you expect another output? The standard says:
> The header <bitset> defines a class template and several related functions for representing and manipulating fixed-size sequences of bits.

Since it's fixed-size these zero bits exist and thus they must be considered by the loop. The loop must do 1000 iterations.

Am I missing something?

Julien



------------------------------

Message: 5
Date: Sat, 2 Sep 2023 18:40:16 -0400
From: connor horman <chorman64_at_[hidden]<mailto:chorman64_at_[hidden]>>
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Subject: Re: [std-proposals] PR: std::allocator<T>::allocate is not
        freestanding
Message-ID:
        <CADLV35joFGxxKzextVM=kW9v7EK+j9j=tY2dZn6YO8LOHJb7dA_at_[hidden]<mailto:tY2dZn6YO8LOHJb7dA_at_[hidden]>>
Content-Type: text/plain; charset="utf-8"

Keep in mind that operator new is required in freestanding. Having
std::allocator as required would just allow constexpr allocations in
freestanding.
So from that standpoint, std::allocator<T> doesn't really require anything
new of the implementation environment.

On Sat, Sep 2, 2023 at 18:10 Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:

> On Sat, Sep 2, 2023 at 11:00?PM Jens Maurer wrote:
> >
> > In general, the "freestanding" subset of C++ is a library subset
> > to accommodate environments where an operating system might not
> > be available, or that are otherwise constrained. For example,
> > std::cout will probably never be part of freestanding
> > (because e.g. a fridge does not have that).
>
>
> I'm programming an Arduino microcontroller here right now, and I have
> it set up so that I can use 'cout' as follows:
>
> class Flush {} flush;
> std::ostream &operator<<(std::ostream &os, Flush const &f) {
> Serial.flush(); return os; }
> std::ostream &operator<<(std::ostream &os, String const &s) { return
> os << s.c_str(); }
> extern "C" int _write(int const fd, char const *const ptr, int const len)
> {
> (void)fd;
> return Serial.write(ptr, len);
> }
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
-------------- next part --------------
HTML attachment scrubbed and removed

------------------------------

Message: 6
Date: Sun, 3 Sep 2023 01:19:15 +0000
From: trtaab trtaab <tvfvof_at_[hidden]<mailto:tvfvof_at_[hidden]>>
To: "std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>" <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>,
        Jonathan Wakely <jwakely.gcc_at_[hidden]<mailto:jwakely.gcc_at_[hidden]>>
Subject: Re: [std-proposals] Std-Proposals Digest, Vol 54, Issue 16
Message-ID:
        <DM4PR02MB9069F88CD9098A9691FEE0FEC7EAA_at_[hidden]<mailto:DM4PR02MB9069F88CD9098A9691FEE0FEC7EAA_at_[hidden]>>

Content-Type: text/plain; charset="us-ascii"

You are wrong.

::operator new and ::operator delete are NOT constexpr.

https://github.com/microsoft/STL/issues/1532
https://github.com/microsoft/STL/issues/4002

There is no way to allocate memory in CONSTEVAL context.

It is a standard bug.

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

From: std-proposals-request_at_[hidden]<mailto:std-proposals-request_at_[hidden]><mailto:std-proposals-request_at_[hidden]<mailto:std-proposals-request_at_[hidden]>>
Sent: Saturday, September 2, 2023 15:35
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]><mailto:std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Subject: Std-Proposals Digest, Vol 54, Issue 16

Send Std-Proposals mailing list submissions to
        std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
or, via email, send a message with subject or body 'help' to
        std-proposals-request_at_[hidden]<mailto:std-proposals-request_at_[hidden]>

You can reach the person managing the list at
        std-proposals-owner_at_[hidden]<mailto:std-proposals-owner_at_[hidden]>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Std-Proposals digest..."


Today's Topics:

   1. Re: Real World Programming, private = public (Andrey Semashev)
   2. Re: Real World Programming, private = public (Jason McKesson)
   3. PR: std::allocator<T>::allocate is not freestanding
      (trtaab trtaab)
   4. Re: PR: std::allocator<T>::allocate is not freestanding
      (trtaab trtaab)


----------------------------------------------------------------------

Message: 1
Date: Sat, 2 Sep 2023 19:38:18 +0300
From: Andrey Semashev <andrey.semashev_at_[hidden]<mailto:andrey.semashev_at_[hidden]>>
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Real World Programming, private = public
Message-ID: <41295a7c-9b88-1081-df3e-f172a89d0e3b_at_[hidden]<mailto:41295a7c-9b88-1081-df3e-f172a89d0e3b_at_[hidden]>>
Content-Type: text/plain; charset=UTF-8

On 9/2/23 19:22, Frederick Virchanza Gotham via Std-Proposals wrote:
> On Sat, Sep 2, 2023 at 4:18?PM Jason McKesson wrote:
>>
>> You keep talking about syntax as though that was the problem. It isn't.
>>
>> You are asking to be able to trivially bypass access controls. That's
>> the feature you want.
>>
>> That is not a thing the language should provide. It renders access
>> controls essentially meaningless. The syntax by which it is provided
>> is irrelevant when the *functionalty itself* is a bad idea.
>
>
> Computer programmers are one of very few kinds of technical worker in
> which this attitude is pervasive.
>
> You can have a tight system in place, adhere to that system and abide
> by its stipulations thoroughly, and yet _still_ provide a means to
> circumvent the system in the event of a corner case.
>
> You also seem to have no concept of harm reduction. C++ programmers
> around the world today are typing out "#define private public".

This last claim needs some proof. In my >20 years of programming, I
never had to do this, and I have a really hard time believing this is
such a widely used practice that it requires to be part of the language.



------------------------------

Message: 2
Date: Sat, 2 Sep 2023 12:41:45 -0400
From: Jason McKesson <jmckesson_at_[hidden]<mailto:jmckesson_at_[hidden]>>
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Subject: Re: [std-proposals] Real World Programming, private = public
Message-ID:
        <CANLtd3UjDoExAc0C2Cixvo2ji8X7=r9PS6FZg8JX-HwwbVKTHw_at_[hidden]<mailto:r9PS6FZg8JX-HwwbVKTHw_at_[hidden]>>
Content-Type: text/plain; charset="UTF-8"

On Sat, Sep 2, 2023 at 12:22?PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>> wrote:
>
> On Sat, Sep 2, 2023 at 4:18?PM Jason McKesson wrote:
> >
> > You keep talking about syntax as though that was the problem. It isn't.
> >
> > You are asking to be able to trivially bypass access controls. That's
> > the feature you want.
> >
> > That is not a thing the language should provide. It renders access
> > controls essentially meaningless. The syntax by which it is provided
> > is irrelevant when the *functionalty itself* is a bad idea.
>
> Computer programmers are one of very few kinds of technical worker in
> which this attitude is pervasive.
>
> You can have a tight system in place, adhere to that system and abide
> by its stipulations thoroughly, and yet _still_ provide a means to
> circumvent the system in the event of a corner case.

If you lock a door but put a sign up saying that the key is under the
mat, the door is *functionally* unlocked. Protections are only as good
as the means to circumvent them.

Features you add to the language will be used against whatever purpose
you added them to the language for. If you give everyone a trivially
accessible key to an object's privates, people *will use them*
whenever access controls make their lives even slightly more
difficult.

> You also seem to have no concept of harm reduction.

I guess that depends on how you define "harm".

When a programmer declares something private, what they're saying is
that it should not be accessed by code outside of their control. Why?
One reason is that it is *subject to change*. By declaring something
private, they're saying that they reserve the right to change it, but
in a way that is compatible with the class's public interface.

By accessing something you aren't supposed to, you are denying that
programmer the right to change it. If they change it, now everyone who
accessed those privates gets broken. Which restricts their ability to
change it. It forces people to use the Pimpl idiom just to prevent
people from inhibiting their ability to later modify their own code.

I consider that to be "harm". Therefore, your feature suggestion does
not reduce "harm"; it exacerbates it.

> C++ programmers around the world today are typing out "#define private public".

Programmers doing bad things is not a good reason to add a language
feature. Also, that's a good argument for further adoption of modules,
since it renders this linguistically impossible.

Lastly, [citation needed]. Like, I'm sure that *some* programmers have
done that. But what makes you think that this is a tool that is in
even mildly significant use/demand?


------------------------------

Message: 3
Date: Sat, 2 Sep 2023 19:22:32 +0000
From: trtaab trtaab <tvfvof_at_[hidden]<mailto:tvfvof_at_[hidden]>>
To: "std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>" <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Subject: [std-proposals] PR: std::allocator<T>::allocate is not
        freestanding
Message-ID:
        <DM4PR02MB90694B8CE1AA7F9DCF16FBF3C7EBA_at_[hidden]<mailto:DM4PR02MB90694B8CE1AA7F9DCF16FBF3C7EBA_at_[hidden]>>

Content-Type: text/plain; charset="us-ascii"

Currently there is no way to allocate memory at constexpr context in freestanding environment. This desperately needs a fix.

N4958 does not mark std::allocator<T> as freestanding so there is no way to allocate memory in freestanding.

This is std::addressof situation 2.0


Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

-------------- next part --------------
HTML attachment scrubbed and removed

------------------------------

Message: 4
Date: Sat, 2 Sep 2023 19:35:32 +0000
From: trtaab trtaab <tvfvof_at_[hidden]<mailto:tvfvof_at_[hidden]>>
To: "std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>" <std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Subject: Re: [std-proposals] PR: std::allocator<T>::allocate is not
        freestanding
Message-ID:
        <DM4PR02MB90697361512FDBD3941CDC3CC7EBA_at_[hidden]<mailto:DM4PR02MB90697361512FDBD3941CDC3CC7EBA_at_[hidden]>>

Content-Type: text/plain; charset="us-ascii"

BTW:
::std::allocator_traits<T>::allocate with a hint has the same issues too.
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows

From: trtaab trtaab<mailto:tvfvof_at_[hidden]>
Sent: Saturday, September 2, 2023 15:22
To: std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]><mailto:std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>>
Subject: PR: std::allocator<T>::allocate is not freestanding

Currently there is no way to allocate memory at constexpr context in freestanding environment. This desperately needs a fix.

N4958 does not mark std::allocator<T> as freestanding so there is no way to allocate memory in freestanding.

This is std::addressof situation 2.0


Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows


-------------- next part --------------
HTML attachment scrubbed and removed

------------------------------

Subject: Digest Footer

Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals


------------------------------

End of Std-Proposals Digest, Vol 54, Issue 16
*********************************************

-------------- next part --------------
HTML attachment scrubbed and removed

------------------------------

Subject: Digest Footer

Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals


------------------------------

End of Std-Proposals Digest, Vol 54, Issue 17
*********************************************

--
Std-Proposals mailing list
Std-Proposals_at_[hidden]<mailto:Std-Proposals_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals