1. 9
  1. 3

    Posting this mainly to post my disagreement with Titus.

    A C++ standard library without a hash table is the kind of insanity only a true academic could propose ;)

    My perspective: I joined the C++ believers about three years ago during the port of a large OO codebase. I have maintained and further developed this codebase since. At first C++ was quite challenging and unfamiliar, and without having a reasonably trustworthy standard library it would have been much more difficult. Now that I have several years behind me, it has clicked, and I find I prefer it in many contexts. To be fair, part of that is the familiarity I feel with C++, because I have known C fairly well for decades. It feels right, like an old power tool without quite so many safety switches. Dangerous, and efficient in a deft hand.

    I agree that C++ is not a great beginners language, but if you close the doors to transitional programmers you will kill the language.

    And as for std::map WRT stdlib ossification, just swallow your dang pride and specify std::map2 and let’s all move on, happier, and faster, and cleaner.

    Bonus prediction: within the next few years there we will see C++ “borrow checkers” come online, and at least one major compiler will support borrow checking, on some basis.

    1. 3

      A C++ standard library without a hash table is the kind of insanity only a true academic could propose ;)

      The problem is that to have a hash map, you must decide how to implement it and you can’t necessarily please all C++ users. For example, by default, Qt’s QHash doesn’t work without a cryptographic-grade random number source. Probably the right choice for many applications, where security might be a concern, but not appropriate for low level embedded systems.

      you will kill the language.

      As a professional C++ programmer, I am very much in favour of this.

      1. 2

        I’m working on a large C++ open source project. I originally chose C++ because I need a high performance systems language, and because the libraries I need are written in C++. My most recent requirement is to compile most of my code into WebAssembly, which C++ supports. I’m not super happy with C++, I’d consider rewriting in another language if there was a better choice. My wish list of language features would be:

        • Memory safe by default, lets you write small amounts of unsafe code encapsulated behind an API, in order to get high performance for a special data structure. (Like Rust.)
        • Generates small, fast WebAssembly code. (C is good for this; there isn’t tons of code bloat from the standard library and template expansion.)
        • Easy integration with C++ libraries, because of these highly specialized libraries I need, not available in other languages. (C++ is the only obvious choice.)
        • Easy to use, low friction coding. (Rust is the opposite of this, and C++ can be frustrating as well.) C is a simple language, but I used to be a C programmer, and I don’t want to go back to having to manually manage reference counts in my reference counted objects, which are pervasive in my current code. I’d prefer an easy to use, memory safe language.
        1. 1

          If you haven’t already, have a look at D. I haven’t used it enough to recommend it yet, but it might fit some of your requirements:

          If you have already considered/tried D, I’d be interested to hear how well it lived up to its promises.

          1. 2

            Thanks for recommending D. It may not be suitable, though: I think I need a non-garbage-collected systems language. I’m implementing a dynamically typed language, and using D with garbage collection would prevent me from using either tagged pointers or NaN boxing to efficiently represent boxed values, because that would confuse the D garbage collector, causing memory corruption. Not using the garbage collector apparently means I can’t use the D standard library, which might be a problem. With no GC, I need reference counted smart pointers, which are not supported by D. D has RefCounted, but that doesn’t support instances of classes, or destructors, which makes it pretty useless for my purposes.

            The C++ interop looks good, better than other non-C++ languages I have considered.

            Another alternative that I haven’t researched is to use a dynamically typed language with an optimizing, ahead-of-time compiler, fast enough so that my own interpreter runs at acceptable speed. I would benefit from the underlying GC and tagged pointer support for efficient boxed objects: no need to implement any of that myself. But then I still need good webassembly support (with compact executables) and some story for C++ interop.

        2. 1

          Sounding flippant, but not meaning to be flippant:

          If you want C++ with fewer features or library support, have you considered C?

          Basically, and allowing room for me to be bad, I want Java without garbage collection and with pass by value and good multiplatform support, including a serviceable standard library.

        3. 1

          I agree with Titus. As he points out, C++ has a standard hash table (std::unordered_map), but it’s not very good, and it can’t be fixed to make it good, so you should use an external library (like Abseil) instead to get a decent hash table implementation. But C++ has the worst story for managing external dependencies in the industry. As Titus said, it’s chaos. And that’s why suggestions to use high quality external libraries fall flat.

          I looked at a draft of the proposed C++ graphics library about a year ago, and it was shockingly incompetent. The authors did not understand how colour spaces worked, I noticed, so it would be impossible to get correct results using the APIs they proposed. Maybe that’s improved, but after reading that draft, I don’t trust the process, and I would rather use a C++ graphics library that is written by industry veterans and used in real products.

          Take a look at Rust, which has a relatively small standard library, plus a really really good package manager and build system. Rust will never have graphics in the standard library, for good reason. If it is really easy to discover the best external C++ libraries, and it is really easy to add a library you discovered to a project you are working on, then that’s a better situation than including half-baked, amateurish standard library facilities (which can never be fixed to work correctly once there is experience with them in the field). And that’s also what Titus said.

          1. 1

            I looked at a draft of the proposed C++ graphics library about a year ago, and it was shockingly incompetent. The authors did not understand how colour spaces worked, I noticed, so it would be impossible to get correct results using the APIs they proposed. Maybe that’s improved, but after reading that draft, I don’t trust the process, and I would rather use a C++ graphics library that is written by industry veterans and used in real products.

            I won’t argue with that, I agree, graphics is going too far. But saying that the old hash table is bad and therefore we shouldn’t have a stdlib hash table seems to me like a non-sequitor, it’s not like the std namespace is full and cannot accept a new symbol.

            Take a look at Rust

            I have. And I got as far as hyper and tokio and walked away after spending hours (days?) trying to spin up a small web server capable of handling some basic client reporting.

            To be clear, rust itself is fine, so let’s don’t crucify me. And I would have used it for the port I mentioned if the platform tooling had been there, but it wasn’t, and it was for C++.

          2. 1

            If they start stripping things like hashtables out of the STL, I foresee a npm-style apocalypse of future C++ projects.

            Overall, though, this feels rather luddite-esque. A step before saying “We don’t need no stinkin’ C++! C can do everything without all the nonsense!”

            Edit: I think this also punts the issue of on-boarding new programmers. It’s already difficult enough to explain that you really have to learn THREE systems: the language, the STL, and the tool-chain. Now we’d just be moving more complexity from the STL into the tool-chain.

          3. 2

            So, what should go in the standard library? Fundamentals. Things that can only be done with compiler support, or compile-time things that are so subtle that only the standard should be trusted to get it right.

            I tend to agree with this, but as long as there’s no package manager to make libraries easily accessible, people will keep wasting their time arguing to get things into the standard library, because that’s currently the only way to make them accessible to the masses.