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