Today, with address sanitizer available on all main compilers and
platforms, maybe this is a better tool to avoid memory access problems, not
only for vectors?

On Sat, Apr 29, 2023 at 10:32 PM Bjarne Stroustrup via SG20 <
sg20_at_[hidden]> wrote:

> "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
>
> --
> SG20 mailing list
> SG20_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg20
>