I am also jumping into this late, but here are some of my observations after having taught a high-performance computing course at the University of Washington for six years now. I use C++ as the programming language for the course.

TL;DR — Bounds-checked vectors are a Good Thing for novice students. The most important thing to keep in mind is that these are students and students have to be met where they are, not where we are. There are innumerable things that we take for granted that novices have no experience with and no mental model for.

The course I have been teaching has a mix of seniors and first-year graduate students. Most are not from computer science; they would qualify as “rank amateurs” and my observations should apply to CS students early in their program. However, they are not rank amateurs in other ways, as they have had 3-4-5 years of university to mature their thought processes, whereas 1st-year students are only slightly removed from high-school.

Coming in to my course I observe:

  * These are smart students
  * The students have programmed extensively in Python and Matlab prior to taking this course. Even in many CS programs, Python is the introductory language
  * The students have experience with various IDEs associated with Python and Matlab
  * They have no mental model for how a program actually executes on a CPU, including registers, hierarchical memory, assembly language, instruction sets, fetch-decode-execute
  * They have no mental model for compilation, nor linking, nor object files, nor binaries. They have some notion of libraries but no notion of interface vs implementation.
  * They have never used a command line
  * A quarter (as we have at the UW) or a semester is a finite (and short) amount of time. There is only so much material that can be taught, and much of it is just establishing the right mental models. Getting novice students to where programmers who have years of experience are is going to take years of experience.

Consequently

  * The students understand the notion of a vector since they have seen similar things in Python and Matlab.
  * They understand the notion of indexing. With Python they understand the notion of 0-based indexing. Matlab (quite quite unfortunately) has 1-based indexing. However, I have found students don’t have a problem with 0-based indexing. Usually.
  * They understand the notion of out of bounds access, since that will have been reported when they have made that error in Python in Matlab
  * An out of bounds error will be natural and even expected
  * The students have to be brought up to speed on all of those things above for which they have no mental model
  * The students are nowise ready to work in a “production environment” — yes, CS students should be ready for that when they graduate, but that will be spread over many courses over the period of years — it isn’t going to happen in one semester with novice students
  * It is inconceivable that they would be able to make any sense of the output from a sanitizer
  * It is inconceivable that they would be able to make use of a command-line debugger (possibly something in an IDE, but I have strong doubts)

My approach varies a bit from what one might use for first-year CS students, as the goals of an HPC course are somewhat different from first-year CS. But, again, I think many of these would be applicable.

  * One can teach a slice through C++ that is almost that “tiny language trying to get out”
  * Since this is an HPC course, I introduce a layer of abstraction based on std::vector that includes Matrix and Vector classes, which is where bounds-checking happens (using NDEBUG to selectively include it or not). They do alot of implementations of things like matrix matrix multiply — using loops and indexing.
  * I don’t introduce any “using” statements, so when students use std::vector, they write std::vector (similarly for all standard library algorithms and data structures)
  * Some things have to be treated somewhat as “magic” — things that are necessary to use but for which the students are not yet ready and can’t be taught in the time available.
  * I do include “excursus” for some of the advance concepts for students who do want to dig a bit deeper
  * Namespaces are one of those things. Bjarne’s approach is to remove them for introductory treatment while I treat “std::” as just part of the name of things in C++.
  * A bounds-checked vector class would be extremely helpful to students. If I were to use std::vector directly in my approach I would just put them in a separate namespace and tell them they need to use stdx::vector if they want bounds checking.
  * I make selective use of C++ Core Guidelines
  * I absolutely avoid raw pointers
  * Since it is an HPC course, we do get into concurrency (and distributed computing via MPI), which might be a topic that CS students might not see in an introductory course (though I think it might not be a bad thing if they did, cf: https://tcpp.cs.gsu.edu/curriculum/)

If anyone is curious, the 2021 offering of the course can be found here: https://amath583.github.io/sp21/units/index.html

(Disclaimer. If you peruse the course long enough, you will find a place where raw pointers sort of come up — the students don’t create them, but do have to interface to them. I give them &x(0) or &A(0,0) as the magic spell — I do discuss memory addresses and so forth at that point to explain what is going on, but I don’t expect them to have any deep understanding of the concept of a raw pointer.)

Best Regards,
Andrew Lumsdaine





On May 1, 2023, at 2:56 AM, Peter Sommerlad (C++) via SG20 <sg20_at_[hidden]> wrote:

Hi Bjarne,

I am late on this thread, but I teach C++ in a way, where indexing is
(almost) never used, at least not for beginners. So I never felt the
need to ask for range checking (iterator invalidation is another
unfortunately related topic).

I teach beginners (who know other programming languages a bit, such as
Java or Python) an algorithm-first approach, similar (but now much
easier thanks to generic lambdas) as Barbara Moo and Andrew Koenig in
"Accelerated C++".

Using a decent IDE (which I unfortunately no longer can maintain:
Cevelop) with some student-oriented static analysis checks also helped a
lot.

Also using namespace std never was a real problem, especially after we
implemented namespace- and qualified name- related refactorings.

I understand this might not help your situation, but at least I found my
workaround.

Regards
Peter.



Bjarne Stroustrup via Ext wrote on 28.04.23 21:12:
This question is in the context of teaching novices. For experienced
programmers, I have workarounds.

I would like to make all of the standard library available

    as a module based on module std

    with guaranteed range checking

    without requiring students to write std:: all the time

    and add a few supporting features

I have successfully done that for tens of thousands of students over
more than a decade using some disgusting macro tricks. Think

    #define vector My_checked_vector

Having guaranteed range checking is a great help to students. I estimate
that it eliminates more than 50% of crashes and lots of frustration.

Modules and disgusting macro tricks don't go well together

I was planning to use

    using vector = My_checked_vector

but I can't find a way for that to work together with

    using namespace std;

Am I being blind?

Any suggestions?

I can get away with a single #using "PPP_support.h" containing three
macros, but I would really like to avoid that.

I suspect the fundamental problem is that there is no way of composing a
module or a namespace saying "I want all of Foo, except that I want my
own versions of Foo::X and Foo:Y." I would *love* to be proven wrong
about that. The original namespace design had such a mechanism, but I
have not been able to get it to work.

_______________________________________________
Ext mailing list
Ext_at_[hidden]<mailto:Ext_at_[hidden]>
Subscription: https://urldefense.com/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/ext__;!!K-Hz7m0Vt54!g8zw6XdZqmIvOgay8CzR8Ltp0Qyk6-a_l7mKoBSfLXuyOg1BmsdADwgPcfO_TbW94_RyG7Gq5wKruQY$
Link to this post: https://urldefense.com/v3/__http://lists.isocpp.org/ext/2023/04/21140.php__;!!K-Hz7m0Vt54!g8zw6XdZqmIvOgay8CzR8Ltp0Qyk6-a_l7mKoBSfLXuyOg1BmsdADwgPcfO_TbW94_RyG7Gqelk-rDg$


--
Peter Sommerlad

Better Software: Consulting, Training, Reviews
Modern, Safe & Agile C++

peter.cpp_at_[hidden]<mailto:peter.cpp_at_[hidden]>
+41 79 432 23 32
--
SG20 mailing list
SG20_at_[hidden]<mailto:SG20_at_[hidden]>
https://urldefense.com/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/sg20__;!!K-Hz7m0Vt54!g8zw6XdZqmIvOgay8CzR8Ltp0Qyk6-a_l7mKoBSfLXuyOg1BmsdADwgPcfO_TbW94_RyG7GqGNeuJ3M$