Const: The Final Chapter

In scientific programming, you often need routines to change values in more than one data structure (basically because the routine's invariants relate physical values that are represented in different data structures, typically arrays). So in a language like Fortran, where functions can only return one thing, you often call subroutines, passing in a number of mutable data structures whose contents all may need to be updated.

In case you're interested in more details on Fortran (take these with a grain of salt, since it's been a few years since I used it daily)... In general, if you pass in "Type x" you're really passing in what C would call "Type x". The language makes this opaque, and some compilers will actually copy in and copy out if [Type] isn't too large. You can tag the ones that the function can't change with "parameter", which acts like the first "const" in "const Type const x". Subroutines allow you to change those arguments, but functions treat every argument as a parameter, and a conforming compiler should complain if you try to modify them. Finally, modern Fortran also provides explicit pointers, though they don't act quite like you'd expect if you come from a C background.

I can recall spending the sum of many hours tracking down various compilation errors due to missing consts. Invariably the problem is miles away from the actual error message (which itself is usually long, cryptic and involving std::allocator).

And without fail, each time the error is either a complete fabrication, presumably invented by the compiler in order to spite me, or a genuine bug that I would have fixed in a great deal less time by actually running the fucking code.

If only const gave warnings, not errors, then we could eat our cake and have it too.

    url = url_normalize(url)