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...
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.
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.
How to clone a Windows Runtime vector in the face of possible concurrent modification, part 4
Translating to C++/CX and dealing with some quirks of that language.
I saw the article on my mastodon feed. When it's interesting I usually post it here
Why does the compiler complain about a missing constructor when I'm just resizing my std::vector to a smaller size?
The compiler doesn't know that you're shrinking.
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
Introduction State of the art Design principles Data structure Algorithms Lookup Insertion Visitation API Benchmarks Conclusions and next st...
Fastest Branchless Binary Search
Fastest general and simple binary search C++ implementation
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.
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
I saw a reactive ui library for WebView in c++ not so long ago: https://nuicpp.org/
Hope it helps :)
IMO this change is more useful than I thought. Anybody knows if it's implemented in Clang too?
GitHub - orlp/polymur-hash: The PolymurHash universal hash function
The PolymurHash universal hash function. Contribute to orlp/polymur-hash development by creating an account on GitHub.