Contracts will not arrive any day soon and remember that not all
students have access to the latest compilers and the latest tools.

In many places the computer, compiler, and tool use is determined by the
professor - and despite our efforts, many professors prefer older tool
chains with which they are familiar, usually what they get "right out of
the box" or a "teching environment" in which it is hard to add new
components. Many also prefer to teach an older style of C++. That's what
I'm up against. I always have problems with getting people to use a
"non-standard" header file, even when that header contains nothing
non-standard. Setting options is often a no-no. Note that this can be
reasonable. It is hard to teach a couple of hundred students using a
couple of dozen different tool chains. I have done it. It is hard, and
we can't impose that on everybody.

Range-checking compiler options are great. I recommend them, but they
are not standard and setting options is difficult for some students.

Part of the problem is that some students have never written a line of
code in their lives, for some their "coding" experience is radically
different from C++ (mine-craft anyone?), and some absolutely freeze in
terror when faced with a command window. A crash without an error
message is very hard for a student to cope with in the first couple of
weeks. Not all debuggers can be described as novice friendly.

Part of the problem is scale. I'm not talking abut me teaching a dozen
students. I'm thinking of dozens or hundreds of courses taught be
teachers and TAs with varying backgrounds,with an aggregate of thousands
of students, and an approach and support text that might be used several
years from now.

Just FYI: this has worked for more than a decade; not perfectly, of
course, but with a reasonable degree of success.


On 4/30/2023 12:50 PM, Andrew Tomazos via SG20 wrote:
> On Mon, May 1, 2023 at 2:15 AM Gabriel Dos Reis via Ext
> <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?
>
>