[Andrew]

  * I'm not sure what the deal is with _GLIBCXX_ASSERTIONS and __glibcxx_assert.

When your programming language requires students to be exposed to that much trickery (where they reflective of production practices or not is irrelevant), I would expect that one would take and a pause and reflect on whether that is what should be happening, by default.

Did you see my recent message to SG23?

-- Gaby

From: Ext <ext-bounces_at_[hidden]ocpp.org> On Behalf Of Andrew Tomazos via Ext
Sent: Sunday, April 30, 2023 10:10 AM
To: Ville Voutilainen <ville.voutilainen_at_[hidden]>
Cc: Andrew Tomazos <andrewtomazos_at_[hidden]>; sg20_at_[hidden]; ext_at_[hidden]
Subject: Re: [isocpp-ext] [SG20] namespace composition



On Mon, May 1, 2023 at 3:01 AM Ville Voutilainen <ville.voutilainen_at_[hidden]<mailto:ville.voutilainen_at_[hidden]>> wrote:
On Sun, 30 Apr 2023 at 19:50, Andrew Tomazos via SG20
<sg20_at_[hidden]<mailto:sg20_at_lists.isocpp.org>> wrote:
>
> On Mon, May 1, 2023 at 2:15 AM Gabriel Dos Reis via Ext <ext_at_[hidden]<mailto:ext_at_[hidden]>> wrote:
>>
>> Ideally, students should be taught practices they can deploy in production setting. While sanitizers and fuzzers have become accepted elements of the dev toolbox, they can't be deployed in production. That is part of why it is critical that we have a standard mechanism for turning bound checking on - or better yet, have bound checking on by default and have mechanism to opt out, after profiling data have shown that's what is needed.
>
>
> If/when we ship contracts, aren't we going to eventually add them to the standard library to check preconditions? and bounds-checking of the standard containers would be amongst them? Isn't turning contracts on-and-off exactly that standard mechanism to turn bounds checking on-and-off? Or are we talking about bound-checking at the lower builtin-array level?

We are talking about students that will be taught this year and the
next. The forthcoming contracts don't arrive in time for that.

Well then perhaps worth mentioning is that libstdc++ (at least) has something like it today. This is std::vector::operator[] from libstdc++

    reference
    operator[](size_type __n)
    {
        __glibcxx_requires_subscript(__n);
        return *(this->_M_impl._M_start + __n);
    }

That __glibcxx_requires_subscript is like a C assert or something:

#ifndef _GLIBCXX_ASSERTIONS
# define __glibcxx_requires_subscript(_N)
#else
# define __glibcxx_requires_nonempty() __glibcxx_assert(!this->empty())
#endif

I'm not sure what the deal is with _GLIBCXX_ASSERTIONS and __glibcxx_assert. Maybe jwakely would know.