Skip Navigation
discourse.llvm.org LLVM 17.0.1 released!

We are happy to announce that LLVM 17.0.1 is now released! Note that 17.0.0 was pushed out, but contained errors in the version information, so we decided to quickly follow up with 17.0.1 - the first public version of LLVM 17.x. Stats This release contains 6 months of LLVM community work and many i...

LLVM 17.0.1 released!
0
shafik.github.io Let's enumerate the UB

Blog about C++, C, Undefined Behavior and Compilers

Let's enumerate the UB
0
Opinions on trailing return type?
  • But what about something like this?

    template<typename T>
    auto make_foo(T&& foo_arg) {
        return foo<std::decay_t<T>>{std::forward<T>(foo_arg)};
    }
    

    This is exactly the pathological case you gave as example, but I find this extremely readable. Specifying the return type would actually not help at all and the pattern the easily recognizable in the end.

    If your naming is bad, arguments not clear, and implementation not recognizable and hard to infer what it's doing then that's a totally different problem and I would say trailing return type and deduced return type is the least of my concerns.

  • Opinions on trailing return type?
  • I use trailing return type exclusively. It just makes the code more readable. Compactness is almost unaffected and readability is more important anyway. Trailing return type is also more compact in many normal cases non temaplate case so I think that argument is moot.

    The name of the function is the first thing you want to read. The most important thing once you found your function is then it's parameters. If you found the right overload, you know the parameters and what they mean then you want to know what it returns.

    Trailing return type just have better ergonomics for the reader and also align the functions as a bonus. It so make name resolution better too.

  • Why use pointers?
  • There are things you'll want to do that will eventually require pointers. For example, as soon as you want a type that contains a reference that could be rebound, you need a pointer.

    If you want to implement polymorphism you'll need pointers. If you instead want type erasure, you'll need pointers to implement your type erasure container.

    Sure it's possible to implement a lot without pointers, but the code will be harder to write and will probably be slower.

  • Inside boost::concurrent_flat_map
    bannalia.blogspot.com Inside <code>boost::concurrent_flat_map</code>

    Introduction State of the art Design principles Data structure Algorithms Lookup Insertion Visitation API Benchmarks Conclusions and next st...

    Inside <code>boost::concurrent_flat_map</code>
    0
    It's great that you provide operator overloads, but it's also nice to have names - The Old New Thing
  • I had designed a system with what I thought was a good API, wrote the test for it and I was satisfied how simple it was to use the thing but then, when it came to integrate it, it was clunky and no good way to actually use the system.

    I don't think it's always obvious when an API is good or bad, even with tests.

  • maskray.me C++ standard library ABI compatibility

    For a user who only uses one C++ standard library, such as libc++, there are typically three compatibility goals, each with increasing compatibility requirements: Can the program, built with a specif

    0
    InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)GR
    gracicot @programming.dev
    Posts 10
    Comments 7