14 ms·

I have some experience in C++, and I am familiar enough with the standard library to remember that operator[] doesn't check bounds while the at member function

I have some experience in C++, and I am familiar enough with the standard library to remember that operator[] doesn't check bounds while the at member function does. I would assume that the Firefox C++ programmers know this as well. However, maybe I'm wrong or have too much faith? Or, maybe, the programmer was aware that operator[] didn't perform bounds checking, but opted to use it for some reason? A good way to dissuade people from making unidiomatic choices is to make them more verbose. IMO calling the at function isn't particularly verbose, but if the member function that didn't check bounds were called something like "at_unchecked," perhaps people would be less inclined to use it. Also, from the snippet in the blog post, note that you can't tell whether the Firefox code used std::vector, C-style arrays, or some non-STL container type. Projects may use their own container types, but your criticism only applies if the programmers were using the C++ standard library.

masklinn 8y ago
> I have some experience in C++, and I am familiar enough with the standard library to remember that operator[] doesn't check bounds while the at member function does. Everybody knows you're supposed to check pointers for being null, and yet time and time again developers fail. As long as you rely on human nature and provide one API which is simple, convenient, obvious and dangerous and one which is complex, inconvenient, non-obvious and safe, you will just drive users towards the former. > I would assume that the Firefox C++ programmers know this as well. However, maybe I'm wrong or have too much faith? Just because they know when quizzed doesn't mean they'll always remember when actually doing. Even less so when subscripting is safe in pretty much every other language which provides array subscripting, and ::at… only exists in C++? > IMO calling the at function isn't particularly verbose No, but it's still more verbose and less intuitive than [], especially given the above (that tons of languages use [], and very few have an at method) > A good way to dissuade people from making unidiomatic choices is to make them more verbose. Indeed.
- svnpenn 8y ago
  this is so true and has been my experience with unwrap they dont want people to use it but the alternative is so verbose and clunky
  - FreeFull 8y ago
    The alternative tends to be to propagate the error upwards using the `?` operator, up to some point where it makes sense to handle errors
    - barrkel 8y ago
      Aka exceptions. Yes, chaps, that Result<T,E> type is all but isomorphic with checked exceptions, Java-style.
      - masklinn 8y ago
        The "but" is where all the difference lies though, Result (or Either or whatever you want to call it) is the reification of the sum of a return value and an error, and as such manipulable without having to add dedicated tooling… (which java didn't have either, and still does not). Amongst other issues it's possible to pipe one through a generic wrapper without that wrapper having to care about it. e.g. let's say you have an input collection, you map() over it, and the map callback can fail. In Rust or Haskell you… just do that. And the caller deals with a collection of results however it wants. In Swift, you need map to be specifically annotated in `rethrow` so it can be transparent to failure (aka can't fail if its callback can't, but can if its callback can). In Java, you're shit out of luck and jolly well fucked, your generic map can't be generic over generic exceptions, so either it callback can't fail or you need to wrap said callback to convert the checked exception into an unchecked one, and possibly back again outside the map. So… yeah, they're "all but isomorphic" because they're both implementations of the concept of statically checked fallibility. It's just that java's checked exceptions[0] are a bad implementation of the concept. Put an other way, a 2018 fiesta or yaris are "all but isomorphic with" a 1960 corvair or a pinto, but you couldn't pay me to take a road trip in a corvair or a pinto. [0] java's because someone might come up with better ones, though the well's been pretty tainted at this point
pjmlp 8y ago
Most debug builds across major C++ compilers do support it though.
bzbarsky 8y ago
The relevant code in fact uses a non-STL array container. Unfortunately, the performance of the STL containers is fairly unreliable across C++ standard library implementations and can be very poor in some cases. That makes them harder than it should be to use in code where you need to understand the performance characteristics of your data structures.

masklinn 8y ago

> I have some experience in C++, and I am familiar enough with the standard library to remember that operator[] doesn't check bounds while the at member function does. Everybody knows you're supposed to check pointers for being null, and yet time and time again developers fail. As long as you rely on human nature and provide one API which is simple, convenient, obvious and dangerous and one which is complex, inconvenient, non-obvious and safe, you will just drive users towards the former. > I would assume that the Firefox C++ programmers know this as well. However, maybe I'm wrong or have too much faith? Just because they know when quizzed doesn't mean they'll always remember when actually doing. Even less so when subscripting is safe in pretty much every other language which provides array subscripting, and ::at… only exists in C++? > IMO calling the at function isn't particularly verbose No, but it's still more verbose and less intuitive than [], especially given the above (that tons of languages use [], and very few have an at method) > A good way to dissuade people from making unidiomatic choices is to make them more verbose. Indeed.

svnpenn 8y ago
this is so true and has been my experience with unwrap they dont want people to use it but the alternative is so verbose and clunky
- FreeFull 8y ago
  The alternative tends to be to propagate the error upwards using the `?` operator, up to some point where it makes sense to handle errors
  - barrkel 8y ago
    Aka exceptions. Yes, chaps, that Result<T,E> type is all but isomorphic with checked exceptions, Java-style.
    - masklinn 8y ago
      The "but" is where all the difference lies though, Result (or Either or whatever you want to call it) is the reification of the sum of a return value and an error, and as such manipulable without having to add dedicated tooling… (which java didn't have either, and still does not). Amongst other issues it's possible to pipe one through a generic wrapper without that wrapper having to care about it. e.g. let's say you have an input collection, you map() over it, and the map callback can fail. In Rust or Haskell you… just do that. And the caller deals with a collection of results however it wants. In Swift, you need map to be specifically annotated in `rethrow` so it can be transparent to failure (aka can't fail if its callback can't, but can if its callback can). In Java, you're shit out of luck and jolly well fucked, your generic map can't be generic over generic exceptions, so either it callback can't fail or you need to wrap said callback to convert the checked exception into an unchecked one, and possibly back again outside the map. So… yeah, they're "all but isomorphic" because they're both implementations of the concept of statically checked fallibility. It's just that java's checked exceptions[0] are a bad implementation of the concept. Put an other way, a 2018 fiesta or yaris are "all but isomorphic with" a 1960 corvair or a pinto, but you couldn't pay me to take a road trip in a corvair or a pinto. [0] java's because someone might come up with better ones, though the well's been pretty tainted at this point

pjmlp 8y ago

Most debug builds across major C++ compilers do support it though.

bzbarsky 8y ago

The relevant code in fact uses a non-STL array container. Unfortunately, the performance of the STL containers is fairly unreliable across C++ standard library implementations and can be very poor in some cases. That makes them harder than it should be to use in code where you need to understand the performance characteristics of your data structures.