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 <email@example.com> 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?
Ext mailing list
Link to this post: http://lists.isocpp.org/ext/2023/04/21189.php