On Sun, 3 Sept 2023, 02:21 trtaab trtaab via Std-Proposals, <
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]
> *Sent: *Saturday, September 2, 2023 21:19
> *To: *std-proposals_at_[hidden]
> *Subject: *Std-Proposals Digest, Vol 54, Issue 17
>
>
>
> Send Std-Proposals mailing list submissions to
> 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]
>
> You can reach the person managing the list at
> 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]>
> To: std-proposals_at_[hidden]
> Subject: Re: [std-proposals] PR: std::allocator<T>::allocate is not
> freestanding
> Message-ID:
> <CANLtd3UmjfiFf86gj4LUPe8vvLNKvNJD3eNSZVkfPoEF=
> 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]> 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]>
> To: 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]>
> 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]> 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]>
> To: std-proposals_at_[hidden]
> Subject: Re: [std-proposals] PR: std::allocator<T>::allocate is not
> freestanding
> Message-ID:
> <
> CALtZhhM3QnSYNbM7i99FQtUpMbs4y6Ax4jq-KwOKazsFJ+GAnQ_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]>
> To: std-proposals_at_[hidden], Arthur O'Dwyer via Std-Proposals
> <std-proposals_at_[hidden]>
> Subject: Re: [std-proposals] Make std::bitset a C++20 range?
> Message-ID: <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]> 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]>
> To: std-proposals_at_[hidden]
> Subject: Re: [std-proposals] PR: std::allocator<T>::allocate is not
> freestanding
> Message-ID:
> <CADLV35joFGxxKzextVM=kW9v7EK+j9j=
> 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]> 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]
> > 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]>
> To: "std-proposals_at_[hidden]" <std-proposals_at_[hidden]>,
> Jonathan Wakely <jwakely.gcc_at_[hidden]>
> Subject: Re: [std-proposals] Std-Proposals Digest, Vol 54, Issue 16
> Message-ID:
> <
> 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]>
> Sent: Saturday, September 2, 2023 15:35
> To: 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]
>
> 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]
>
> You can reach the person managing the list at
> 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]>
> To: std-proposals_at_[hidden]
> Subject: Re: [std-proposals] Real World Programming, private = public
> Message-ID: <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]>
> To: std-proposals_at_[hidden]
> Subject: Re: [std-proposals] Real World Programming, private = public
> Message-ID:
> <CANLtd3UjDoExAc0C2Cixvo2ji8X7=
> 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]> 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]>
> To: "std-proposals_at_[hidden]" <std-proposals_at_[hidden]>
> Subject: [std-proposals] PR: std::allocator<T>::allocate is not
> freestanding
> Message-ID:
> <
> 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]>
> To: "std-proposals_at_[hidden]" <std-proposals_at_[hidden]>
> Subject: Re: [std-proposals] PR: std::allocator<T>::allocate is not
> freestanding
> Message-ID:
> <
> 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] <tvfvof_at_[hidden]>>
> Sent: Saturday, September 2, 2023 15:22
> To: 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]
> 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]
> 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]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>