> 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.

We can distribute compilers which are easy to install. Something similar to
`rustup` here https://rustup.rs/cwhere you can install the compiler you
need for your system with a single command.

I have been testing out such a system here: https://gitlab.com/cupstack/
Where installing a compiler is as simple as
`cupstack.sh --compiler $COMPILER --version $VERSION --prefix
$ABS_TMP_DIR/opt/cupstack`.

That would incentives teacher to use latest version of compilers..



On Mon, 1 May 2023, 00:09 Bjarne Stroustrup via Ext, <ext_at_[hidden]>
wrote:

> 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?
>
>
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
> Link to this post: http://lists.isocpp.org/ext/2023/04/21189.php
>