"As close as possible, but no closer" as the old slogan has it.

I once observed a freshman class in an excellent university. Over the
first couple of months more than 50% of the errors and even more of the
frustration was range errors. That is counter productive when trying to
teach programming. What I do is simply to get the errors reported
promptly; I turn UB into predictable, guaranteed, reported errors.

If the standard offered a standard way to get range checking I would not
need hacks and I would be very happy. I would also recommend using it
for essential all development, so it would be "realistic."

I guess that I should be happy that the standard rules are tight enough
to make my hack unnecessary.


On 4/29/2023 12:22 PM, Arthur O'Dwyer wrote:
> On Fri, Apr 28, 2023 at 9:46 PM Bjarne Stroustrup via Ext
> <ext_at_[hidden]> wrote:
>
> On 4/28/2023 8:55 PM, Ville Voutilainen wrote:
> > On Sat, 29 Apr 2023 at 03:40, Bjarne Stroustrup
> <bjarne_at_[hidden]> wrote:
> >>> Name lookup in C++ is complicated. :P
> >> Too complicated, and there is probably little we can do about it.
> > Right, but we would curse the language if it just allowed what
> you're
> > trying to do, when programming at scale(*). You have
> > an altruistic hack here, but it's still a hack.
>
> Agreed. What we need is a way of getting a portable guarantee that
> range
> checking is done for at least non-sneaky uses. This fits with
> "profiles".
>
>
> Isn't this roughly what the "GSL" project tried to do, several years
> back? You'd write something like this:
>
> #include <gsl/vector.h>
> int main() {
> gsl::vector<int> v = {1,2,3};
> v[4] = 2; // guaranteed abort (or exception, or whatever) here
> }
>
> By using `gsl::vector` instead of `std::vector`, you'd be guaranteed
> to get the behavior designed by the type author of `gsl::vector`,
> rather than the "non-portable" (in this context) behavior of
> `std::vector`.
> Bloomberg does something similar with `bsl::vector` instead of
> `std::vector`. Now, I believe Bloomberg also has some machinery in
> place so that you can write `std::vector` in the source code and get
> `bsl::vector` under the hood; maybe someone who actually works with
> BSL will comment here. They also of course have more resources to
> devote to library hacks (e.g., "reimplement the entire STL from
> scratch so it does exactly what you want, portable to all
> architectures you care about") than the average C++ trainer.
>
> When teaching C++, I advise teaching as close as possible to what the
> students will be expected to do in real life; that means teaching them
> how to use namespaces (especially the `std` namespace), how to
> #include third-party libraries, and so on. This is Day-1 material in
> any beginner class, AFAIC.
>
> > You're trying to take
> > everything that's in std, but sneak
> > in an alternative for vector, with slightly different semantics. The
> > language quite reasonably says "Whoa. If you
> > want that, establish a new namespace where you can decide what the
> > rules are, but no such sneaking under
> > my watch." [...]
> >
> > (*) I mean, imagine working on a large project, getting puzzled why
> > your vectors don't seem to work as expected,
> > and then finding out a sneak-in. You would curse. You would
> think that
> > the language shouldn't allow such
> > sneaking to occur.
>
>
> +100.
> Corollary: When teaching C++, please don't teach this kind of hack,
> either. Teach the actual, real-world way to deal with suboptimal
> libraries: how to replace them with third-party dependencies, for
> example. Even if the "third party" is just the instructor, and the
> dependency is just a single file containing a basic reimplementation
> of `vector`.
>
> (Of course the instructor's reimplementation won't get picked up by
> places that /the STL itself/ uses `vector`, such as `seed_seq` and
> `regex` and now `flat_set`. But again, that's going to be a problem in
> the real world too, so you shouldn't train students to expect anything
> unrealistic.)
>
> –Arthur