steerablesafe

Yes, that's still SFINAE. Now `is_constructible_v<S<X>>` evaluates to either `true` or `false`, depending on `X` being complete or not on the point of instantiation, while with the static assert it's always `true`, but you get an error at the point where the default constructor is instantiated. The different value for `is_constructible_v<S<X>>` can cause ODR violation in this variable template itself https://eel.is/c++draft/meta#rqmts-5, or otherwise further down the line.

About your edit: I didn't know about that issue. Apparently it is ODR violation and ill-formed, no diagnostic required according to https://eel.is/c++draft/temp.point#7 :(. I'm not happy about it.

Having said that, yours is not free from ODR violation issues.

I'm not saying that you are making things SFINAE friendly. I'm just curious about a use case you have where you use enable_if on completeness. Not asking for making up a use case where you SFINAE on completeness.

> which would avoid putting (void)sizeof(It) directly inside an SFINAE context. I'm just saying you could do it this way without violating ODR or other stuff I think (unless I'm missing something).

Putting it in an alias template doesn't sidestep putting it in an SFINAE context. The detection idiom works because it can still be an SFINAE context.

> I wish there was a variant of -Wold-style-cast just for pointer types.

And for reference types, pointer to members, pointer to/from integral and dependent types (which could become any of the above upon instantiation). But I do agree, with some concrete types it can be convenient.

I'm curious about a valid use case there. If you have a minimal example, or a link to some public code, I would love to see it.

There is a reason to be cautious there, the standard library also tends to static_assert on completeness instead of trying to be SFINAE-friendly.

Do you `enable_if` on completeness of a type? I would recommend against it, it's prone to ODR violations.

I think the "Static casts can call several conversion constructors" section is misleading. In fact, it has nothing to do with static_cast, it's just you can chain conversions, if you write out some of the conversions explicitly. `BarFoo barfoo = FooBar(foo);` works all the same.

C-style cast also has a weird "super power" when it tries the `static_cast`: it will happily cast to a pointer of private base (with all the offset adjustments), while normal `static_cast` would fail.

I just tried this in python, and it's pretty damn close.

Does this generalize? Like taking 2^0, 2^1, ..., 2^99 -> lexicographical sort -> putting the decimal point, and then comparing to 10^0.00, 10^0.01, ...?

The fun part of OSM is that if you find a glitch like that (likely in the map itself), you can fix it yourself. There was an intersection near me where you could physically not turn left, but it wasn't recorded in the map. It was like a few minutes to fix that once for all.

> There is an unofficial unrar that is free and open-source software, but there is no free and open-source rar as creating one is prohibited by the RAR license.

From the license (EULA), I assume this is the relevant part:

> You may not use, copy, emulate, clone, rent, lease, sell, modify, decompile, disassemble, otherwise reverse engineer, or transfer the licensed software, or any subset of the licensed software, except as provided for in this agreement. Any such unauthorized use shall result in immediate and automatic termination of this license and may result in criminal and/or civil prosecution.

> Neither RAR binary code, WinRAR binary code, UnRAR source or UnRAR binary code may be used or reverse engineered to re-create the RAR compression algorithm, which is proprietary, without written permission.

> The software may be using components developed and/or copyrighted by third parties. Please read "Acknowledgments" help file topic for WinRAR or acknow.txt text file for other RAR versions for details.

Is this actually enforceable? If yes, are there worse outcomes apart from revoking the license? And I mean, the open source unrar, which is supposedly fine, doesn't come with an EULA like this. So it's probably not binding for reverse engineering based on the open source unrar.

edit: I mean if there is a separate patent, then it's a different issue.

An alternative explanation is that you treat the ground as a flat mirror, and the radar detects the distance of your mirror image. The distance between you and your mirror image is (2r), so the signal strength you receive from your mirror image is ~1/(2r)^2, still follows 1/r^2 .

I had the pleasure to measure that in a university lab, it's very apparent when measuring near 0°C takes roughly 2x longer than on room temp.

It might be atomic on the OS level (no processes can see an "intermediate" state), but it might not be atomic when you yank the power cord. POSIX in general doesn't offer any guarantees there, AFAIK.

Good point on accessibility, it could always be black-on-white shapes, numbers, letters.

Not to mention blind users, it looks like OP's captcha had a speaker icon on the captcha, I wonder if it would have made the challenge easier.

Yeah, you know what computers suck at but it's relatively easy for humans? Summing numbers. /s

edit: I mean the captcha could keep all the "hard for robot" elements (recognizing top face, recognizing symbols) and remove the "hard for human" one (sum), like "select the dice that have the following symbols on top: <red circle>, <blue rectangle>, <green triangle>".

> Of course, all the testing agencies are collecting DNA. The records will be somewhere.

The news is from the UK. One can order tests by post, do the tests themselves and only report the test results (either the free ones, but there are travel tests available too). The testing firm never gets the physical test sample.

It doesn't help you when you want to run BSD on your laptop or desktop.

Well, C++ now has constexpr functions that can run in compile time, and do basically arbitrary computation. But it also has implementation limits.

MSVC might not alter layout, but public and private member functions have different name mangling:

https://godbolt.org/z/ddqd3vr5x

Notice the call to `?foo@A@@AEAAXXZ` in one compilation and `?foo@A@@QEAAXXZ` in the other, supposedly to the same function. You might get fun linker errors this way, possibly nothing nastier though.

It looks like it's a C++ standard library requirement:

https://eel.is/c++draft/macro.names#2

Otherwise this is one of the unintended effects (on Itanium ABI):

https://godbolt.org/z/bY4534zhc

Well, I hope you know that in theory it's undefined behavior, and in practice it can actually affect layout of objects.

> C++ specific: Use non-virtual methods

Are they suggesting that all/most of my methods should be virtual? That's just nuts. Next they will say that all of the members should be public, since it's easier to test that way.

I don't know if such rendering is commonplace, but I know for sure that imageworsener handles this correctly for downscaling images. Check out the option `-offsetrb 1/3`.

https://entropymine.com/imageworsener/subpixel/

That would be fine, if alpha blending was handled gamma-correctly in most software, but it isn't. Things go worse with alpha and subpixel-AA, that is just cursed.

This assumes a naive and wrong way to do subpixel-AA. See my other comment: https://news.ycombinator.com/item?id=30330936

That's a very naive and wrong way to do subpixel-AA. Roughly, to calculate the light intensity of a red subpixel, you must also take into account the red light intensity around a whole pixel area around that subpixel, centered on that subpixel. There are better filters to use here, this would be a box filter, which is 1-pixel wide.

There can be various causes for those symptoms:

1. Even if the rendering gets the subpixel order right, the subpixels are rarely equidistant on a display. They tend to be closer to each other within a logical pixel.

2. Some subpixel-AA algorithms are naive, and trade color accuracy to luminance accuracy, causing more color fringes.

3. Incorrect gamma handling.

4. If aiming for more luminance accuracy, incorrectly taking into account the relative luminance of the subpixels (what you observed with the brighter green subpixels).

Imageworsener[1] has an option to downscale with subpixel antialiasing, it's gamma correct by default, and it has an option for adjusting the subpixel offsets within a pixel (instead of the naive default of 1/3). It might be a good way to try out correct subpixel-AA, but it only works on images. I guess you can render text on high resolution and downscale that with imageworsener, but you won't get any hinting that way, but maybe that's desired.

Very few software does AA correctly, let alone subpixel-AA.

[1] https://entropymine.com/imageworsener/

I was assuming that to make a point. The actual subpixel order can either be retrieved by an appropriate API (if available) or be provided by the user (display settings). Point being, subpixels don't usually overlap on the same area, which is what's grayscale's assumption. I agree that if subpixel order is not known, then grayscale is a sane default.

> Greyscale with wrong gamma and/or wrong blend mode isn't fatal, it is fatal with subpixel.

I might not be fatal with black-on-white or white-on-black, but grayscale is pretty much still horrible with colored text and background.