On 5/1/2023 1:40 PM, Andrew Lumsdaine via SG20 wrote:
> 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.

+1

much good experiential stuff below.


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