Variance doesn't affect generated code because it acts earlier than that: determining whether code is valid or not and in doing so preventing invalid code (UB) from being compiled in the first place.
The simplest example of incorrect variance → UB is that `&'a mut T` must be invariant in T. If it were covariant, you could take a `&'a mut &'static T`, write a `&'b T` into it for some non-static lifetime `'b` (since `'static: 'b` for all `'b`), and then... kaboom. 'b ends but the compiler thought this was a `&'a mut &'static T`, and you've got a dangling reference.
`&'a mut T` can't be covariant in T for a similar reason: if you start with a `&'a mut &'b T`, contravariance would let you cast it to a `&'a mut &'static T`, and then you'd have a `&'static T` derived from a `&'b T`, which is again kaboom territory.
So, variance’s effect is to guide the compiler and prevent dangling references from occurring at runtime by making code that produces them invalid. Neither of the above issues is observable at runtime (barring compiler bugs) precisely because the compiler enforces variance correctly.
It doesn't have zero effect. Like everything about type systems, it helps prevent incorrect, and possibly unsound, code from compiling. So I guess the giant runtime effect is that you either have a program to run or not.
I'm pretty sure that "don't operate your radar in enemy airspace" is right below "don't email your flight plan to the enemy" on the list of tips for stealth pilots who want to survive a mission.
stealth does in general go out the window when you turn on your radar. It's much like dressing in black and then running around with a flashlight at night. (and yes, there are equivalents to the various forms of night vision here, with associated tradeoffs)
Doubt: the APQ-181 radar on the B-2 is a Ku band radar, about 15 GHz. Tamara is about 1 GHz. This is entirely incompatible frequency ranges.
Also, the APQ-181 is a LPI radar, which means it’s specifically designed to avoid correlation of signals such that you can track by the signals emitted. There are presumably some downsides to working in LPI, but the upside is that the signal is designed to be indistinguishable from an increased noise floor.
My guess is, it has to do with cam streamers and ability for people to develop extensions for streaming platforms for their devices.
Lovesense, for example, became shorthand for "toy controlled by chat" on streaming sites.
> They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and keep up with.
I never got this. Can't you just decide to use subset of the language?
No-one forces people to use every single feature. It's okay to use C++ like "C with classes" and occasionally cool new thing, when it is right tool for the job.
Only people where this argument is truly valid are compiler/tools people.
> Can't you just decide to use subset of the language?
No, you can't. Not in the long run, at least. You will have to use libraries that have chosen a different subset, new people will join your team, things will get sloppy as the company grows, etc. Committing to a subset of the language is not free, it's hard and it's a lot of work. And for what?
> Can't you just decide to use subset of the language?
That is harder than it sounds. First you have to select which subset to use, it is almost impossible to get any two engineers to agree on that - if you do get agreement that is a bad sign - generally it means the people in the room don't know C++ well enough to make the decision and so you choose the wrong one. The best you can hope for is a compromise where nobody is happy - and thus everyone will look for an excuse to bring in their pet part of C++ not in the subset because there is a "good reason" for an exception.
Even if you select a subset it is almost impossible to enforce whatever subset because even if you don't allow your people to use it directly odds are you bring in a third party library that does use it (the C++ standard library being the big one!)
There are a few exceptions to the above. No exceptions/no RTTI are commonly disabled exceptions and so you will get some compiler and library support. Game companies commonly write their own standard library. Both of these are done for performance reasons and have specific domain specific reasons that can be validated in a profiler to set their rules.
Not related to reflection, but C++26 is also likely to get profiles which will disable specific old constructs, (new/delete) which are proven to be error prone and thus result in security issues. These are a good subset to use, but it is about security and so mostly doesn't get the types of subsets you are talking about.
You can still enforce a style guide and limit certain constructs via code review.
Plenty of the modern C++ people already do this by enforcing things like "no raw loops", "no raw pointers", or "no raw synchronization primitives" during code review.
The issue is that it's a lot harder to justify avoiding new features than it is to justify avoiding old features unless you have a tooling specific reason (ex lack of support) to do so.
There is the problem - code reviews are done by humans and so it is really easy to read some code and not think "wait this is new code it can't do that anymore". I read a lot of old code as part of my job and it often isn't worth the bother to update working code to new standards.
> it's a lot harder to justify avoiding new features than it is to justify avoiding old features
The problem is the opposite - people keep using old features when the new is better. I realize not everything new is better, but most of them are, yet people keep refusing to learn and use the new thing without good justification.
> The problem is the opposite - people keep using old features when the new is better. I realize not everything new is better, but most of them are, yet people keep refusing to learn and use the new thing without good justification.
I think we are saying the same thing here. Often the new is better so it's hard to really justify sticking to the old outside of project specific reasons (i.e. toolchain doesn't support new std). That people do it has less to do with justification and more to do with time commitment or laziness and the excuses given tend to fall away once pressed.
Personally I think this is true. C++ is multi paradigm and can be effectively used with many different subsets of the language and those subsets still interact well.
However that opinion is kind of a minority. There are a lot of people in the community who don't want to have to learn new features just because a dependency happens to use/expose them. I don't personally see the issue with it.
I'd rather learn std features any day over non-std features. It's just a better use of my time because they work everywhere and someday I might need them. However again not everyone shares this opinion.
or people who need to maintain someone else's code, debug their own, write a library someone else might use, or understand compiler error messages, all of which involve understanding language features you don't yourself use (at least intentionally)
If you're writing library code that someone else might use, you don't have much need to understand the features you don't use, unless you have to handle them at the interface. If you're debugging your own code, you really shouldn't have to understand features that you didn't use. (Mostly - see the next paragraph.)
You did say "intentionally". You could wind up using a feature unintentionally, but it's not very common, because most of the new features are either in a new library (which you have to explicitly call), or a new syntax. There are definitely exceptions - I could easily see you using a move constructor without meaning to.
Maintaining someone else's code... yeah. You have to understand whatever they used, whether or not it made any sense for them to use.
i accidentally used the new implicit constructors for aggregates in c++ the other day, and then my code didn't compile with the version of clang i have installed on my cellphone
LOL. What used to be a typo is now becoming valid syntax (and of course the compiler can't warn you because it's now valid). Ouch. At least an old compiler saved you...
Tbh this is why you need to set the C++ std version when you compile. Don't just assume the default for the compiler but hard lock it at a specific version so you can know which compilers you can support and compilers can warn you if you use new features.
i set it to c++20 on purpose, i just didn't know the feature existed (and didn't know that my clang didn't support that feature; i'm a little uncertain as to whether my clang is an outdated version without full c++20 support, or whether gcc is implementing a proposed extension that didn't actually make it in)
Yeah, I think gcc has a std c++20 mode as well as a with extensions mode. And adding `-pedantic` helps because it forces extensions (unless specified in the std type) and non-conformant code to be rejected.
And that clang likely just didn't have full c++20 support. Which tbf I actually don't think any clang has full c++20 support currently as even bleeding edge clang still is missing a few things in the lang and library departments.
I dont think this is about workers preference.
People without oversight can get unsure about how to execute task and need validation, but when directly asked nobody will tell you they like micromanaged (seen this).
Other thing I've seen is people without supervision producing less/lower quality results.
> People without oversight can get unsure about how to execute task and need validation
This sounds more like it could occur at least temporarily when most people get some categorically new task that's potentially costly to screw up, and I could imagine it being voluntarily requested rather than overbearingly applied.
> Other thing I've seen is people without supervision producing less/lower quality results.
I feel like managers identify a risk and apply their toolkit to it, which often ends up being increased oversight regardless of whether or not it's a good idea. It may or may not be I suppose, but it seems like only a niche person would respond with greater effectiveness in response to more frequent and perhaps intrusive scrutiny.
> An insurer/ health insurer, employer, government, etc will require it, and just like that the "just don't use them" crowd will hold up their hands and pretend that no one could have imagined this disaster.
On Android where alternate storefronts are a possibility, I have yet to be made aware of a single instance of this happening.
Not even Epic in their crusade against established mobile stores made its' own platform.
1. You're not looking very hard, surveillance ware exists for employment, examinations and so on. It's not available on iOS, but is available on Android via side loading. Both Facebook and Google used iOS certificates to side load tracking apps onto iOS for regular consumers. Even rental cars brands have utilised surveillance software to track speed and apply fines. The more you dig here the more you find: it's not some outlandish concept.
2. The inability to run such types of software on iOS prevents these approaches from moving forward across the industry. Much the same way that QR codes weren't widely utilised until both Android and iOS supported it.
