Kometes Kometes

Niner since 2011


  • Bjarne Stroustrup - The Essence of C++: With Examples in C++84, C++98, C++11, and C++14

    @01:33:00 concerning efficient string handling: you can build a "constant string reference" class using constexpr and variadic char templates that at compile time can: get the string length; concatenate strings (no concatenation is actually done it's just a type); iterate over the string etc. This has already been done in production code! Maybe it could be a TR for C++14, once standardized it will be the nail in the coffin for null-terminated C strings.

  • Interactive Panel: Ask Us Anything!

    @0:31:00: Wow, is there really a debate on what a module is? Just combine the outdated concept of header / source into one file -- that's a module. Now solve all the language problems that crop up. I agree it's a huge change, modules will have to exist side-by-side with the old system for backwards compatibility.

    "#include file" is similar to "from file import *", always a bad idea.  C++ will need fine-grained symbol import/export control for macros, namespaces, templates, classes, functions and variables.  Look at Python for inspiration: "from module import symbol as local_symbol"

    Of course "#include" does more than just import symbols, but the idea is to develop new language to divide its power until it's no longer needed; it's a sledgehammer of a directive and should be deprecated.

  • C&B 2011 Panel: Herb Sutter, Andrei Alexandrescu and Scott Meyers - C++11

    In response to lambda arg types at 49:00, I don't think it would be too much to ask for something like function_arity<T> and function_arg<T, int> to get the number and type of arguments of any regular/member/bind/lambda function.  I've written such a meta function for regular/member, but it's not possible for bind/lambda.

  • Writing modern C++ code: how C++ has evolved over the years

    I'm surprised that the range-for, a language extension, made it into the standard when a beautifully composable library extension using for_each was *so* close to being realized.  Just need those polymorphic lambdas [&](auto& e) {...}