Yes, std::remove_cvref_t combines the other two, in fact I believe it does so precisely (see the "Possible Implementation" on cppreference.com). The "...with a little extra" that I mention for std::decay_t in the article is that it does the same as std::remove_cvref_t plus some standardization of array and function types to pointer types (again, see the "Possible implementation" of it on cppreference.com). For my purposes it doesn't really matter which to use, and I mostly prefer std::decay_t for its brevity.
Pattern Matching Template Types
How to check if a template type matches a pattern? Something like `is_like_v>`.
The last in a series of blog posts on a C++ technique that I've put to use for a numerical library. Was a fun little exercise, sharing here.
Jekyll-Responsive-Magick v1.3.0 Released
Added support for arbitrary image formats #5. Added format option for global override of output format #6. Thanks to @d9beuD for the contributions!
Update to the open source jekyll-responsive-magick plugin for generating responsive images for a Jekyll 4 website using ImageMagick.
You might want to confirm that it is indeed zypper packages before you rearrange too much: Disk Usage Analysis on the desktop, or du -sch * on the console will get you some numbers by directory. It could also be cached packages, clean them up with zypper clean --all.
I'm not sure about specifying different destination directories with zypper, but you could try installing something like vscode from Flatpak rather than zypper, and specifying --user so it goes into your home directory (if that's a different partition).
I'd also look at your containers with podman and clean up any old ones, they can take up a lot of space.
Overloading the Spaceship Operator, A Recipe
How to overload the three-way comparison (spaceship) `operator<=>`, and a reminder to overload `operator==` as well.
The spaceship operator took me longer than it should (my mistake). A note to my future self, and maybe of use to you.
Nice. I'd not thought of that one.
Forwarding references, overload resolution, and seizing back control
Consider merging overloads into one function with forwarding reference parameters
The intersection of forwarding references and overload resolution has been bugging me, and I've been caught out a few times on the wrong overload, so here's an idea.
For the array type it can be useful to allow implicit copy to different arithmetic types (design choice, I'm now back to explicit constructors to disallow this for what it's worth). If allowed though, I still wanted a compile time check like this to ensure that it wasn't happening by accident in particular circumstances.
Yes, that's right, generic context, and you may be right on return value optimization. It was for implementing a collection of numerical functions that take array arguments, where the elements of those arrays could be of various arithmetic types, and the return type should be an array of a particular arithmetic type given promotion etc. The implementation was generic, and I was wanting to validate its correctness wrt return values having the correct arithmetic type without implicit copy.
That's a fair criticism around relying on implicit type conversion mechanics, and part of the tradeoff to make. On the other hand, I imagine (and my imagination may be limited) that one downside of static_assert is to increase verbosity, something like:
auto r = f();
static_assert(std::is_same_v<decltype(r),MyReturnType>> || !is_expensive_conversion_v<MyReturnType>);
return r;
C++: Disable implicit conversion in specific contexts only
C++ trick I pulled today. Like an explicit constructor but context dependent. Any alternatives from folks who've needed to do similar? One thing I still need to dig into a little deeper is how copy elision behaves here.
This would be better style in my opinion, but by way of correctness it seems the more fundamental issue is "return" missing in the if... else if... blocks.
Your get() function will always just return the value of the root node. I think you mean to have return get(value, ...) in each of its if statements.
Combinatorial instantiation of C++ templates with std::variant
Compiler optimizations can break it, function attributes can fix it.
This one was quite a struggle, thought I'd share for the C++ programmers here.
I have a use case where for many function templates I have to instantiate them for a bunch of different parameter types, e.g. unary, binary and ternary functions where each argument can be one of 9 different types, giving 9, 9^2 = 81 or 9^3 = 729 instantiations of each function. Clearly I don't want to write those out as explicit template instantiations, and using macros is error prone too.
I've found this approach with std::variant and std::visit to be useful. Would appreciate any insight on edge cases where this may not work, or other suggested approaches.
I have Ubuntu 22.04 on a Dell XPS Plus 13 with OLED display. Looks great, battery life is good. Not sure how tuned the drivers are etc but definitely no need to avoid.
Welcome to C! Tiny suggestion to add to other comments: value is already Boolean, so there's no need to write if (value == 1), you can just write if (value). Similarly, following @[email protected]'s suggestion of using the ternary operator, you can write return value ? "Yes" : "No";.