1. 15
  1.  

  2. 12

    I feel like he doesn’t address some questions properly.

    • when asked about rust and linear types, he says he tried to do that fifteen years ago, but with a purely linear implementation (where you pass a unique pointer to the callee, and it returns it to you when it’s done). That’s not quite as convenient as what rust does with borrowing and affine types.
    • maybe C++ proposed “epochs” are different than rust editions, I don’t know; but his rambling about not being able to use tooling from older epochs in newer ones is exactly the problem rust editions address. The whole point is to be able to deprecate things or change some parts of the language in newer editions, while being able to interoperate with old code!! So your legacy codebase of 3Mloc still works, but you can use a stricter, more modern language in new code. The compilers must be able to understand new and old epochs and have them interoperate, of course; in practice it means they should unsugar both old and new constructs to a similar IR.
    • the whole thing about people not using the STL, as far as I know, is because the STL’s API, not implementation, prevents it from being efficient. So when he says people should just stick to the STL interfaces when redoing their thing is flawed from the start. Alternative standard libraries and hashtables and whatnot are faster because they are not compatible with the STL. 🤷
    1. 4

      And towards the end, he couldn’t resist noting that longevity has its advantages. “It’s highly humorous when some of the Rust people come up and accuse me of having stolen some of their ideas without acknowledging — when some of the things I did I actually did almost 40 years ago.”

      “Don’t call it a comeback. I’ve been here for years!”

      Seriously, though, that’s silly. I’m reminded of a guy on Slashdot lecturing larry@wall.org about Perl back in the 90’s, or the recruiters who demand 12 years experience with Rust or something.

      (A funny if only tangentially-related story. Years ago I and my girlfriend-at-the-time had to watch her much younger step-sister, who was…12? at the time. We all watched Casablanca and when it was over we asked the little sister what she thought. “It was good,” she said. “But it’s been done before.”)

      1. 3

        Nice to hear reflection mentioned. But there is a chance it may not get in to the C++ 23 either. So somewhat disappointed… after so many years, reflection still does not get the priority.

        I always felt that without built-in reflection it is much harder to develop usable GUI, Web/Text and database processing libraries. And, also, much harder for end users to consume those libraries.

        In such libraries it is always the intention of the authors to use host language (eg C++) to describe ‘schema’ of the objects in their particular domain. (eg Database tables, json, GUI form fields, etc) With that, the library authors tend to offer helpers (either at compile time or runtime) that leverage the C++ descriptions of the target domain schemas. To do that, they attempt to generate get/set/serialize/deserialize helpers, and aid with integration of those domain objects into C++ lists/iterators and other standard constructs.

        Without reflection is impossible to do (at least I do not know how).

        So libraries dealing with that type of end up offering their own (perhaps, also, incompatible) reflection implementations (eg Qt MOC, boost’s type reflection, boost’s mirror, rttrorg/RTTR)

        But overall all these ‘non-standard’ solutions create cognitive overload, add complexity through the library usage and make usage of the language feel less polished.

        For me, it seems, that reflection is one of those features, that’s hard to keep on the back burner…

        Of course less it is less important than solving the biggest usability nightmare: build/distribution system, but C++ standard is not aiming to solve that.

        1. 3

          intention of the authors to use host language (eg C++) to describe ‘schema’ of the objects in their particular domain

          Rust solves this without reflection with “macro derive”. It’s a syntax sugar for AST transformations, which are used to implement self-describing types, without actual reflection support in the language. It works pretty well for serde (serialization) and diesel (db schema).

        2. 0

          Excuse me, tea in five minutes