My very similar pet peeve is about websites that use `onclick` handlers and similar to implement navigation. Just use a damn anchor tag, which gets you correct link behavior for free:
* works with middle click for new tab
* integrates with accessibility devices
* works with right click + open in new window or similar options
* etc. etc. etc.
If it's notionally navigation, don't use javascript soup: use a link.
I actually found that particular response to be quite disappointing. It should give pause to those advocating removal of XSLT that these three totally disparate use cases could already be gracefully handled by a single technology which is:
* side effect free (a pure data to data transformation)
* stable, from a spec perspective, for decades
* completely client-side
Isn't this basically an A+ report card for any attempt at making a powerful general tool? The fact that the suggested solution in the absence of XSLT is to toil away at implementing application-specific solutions forever really feels like working toward the wrong direction.
Many of the responses to this comment imply that this is something fundamentally different than perfect pitch and give it some different name ("pseudo absolute pitch", "perfect relative pitch", etc.). While I concede that most people think of perfect pitch as something that is instilled in some way in early childhood rather than achievable through practice, I guess I would ask those commenters... why do you think the latter is fundamentally different, or is using some separate mechanism?
There are many skills which are much easier to instill in early childhood and are simply harder to master if approached in adulthood -- language learning, certain athletic skills, and more -- but we would never consider any of these impossible to achieve through study. Sure, maybe the maximum achievable skill level is less than what could have been possible if study began in early childhood, but we would not say that it is impossible for adults to achieve a level of mastery, or that those who gained a skill through serious practice must be using some separate mechanism than those who learned it in early life.
I contend that it is the same with absolute pitch. After all, there is not even a perfect level of absolute pitch mastery! In layman's terms, "perfect pitch" is usually understood to mean that a person can immediately name a pitch when played -- on a 12-tone western music scale. But some people people with perfect pitch have better precision than that and can estimate quarter tones, etc. If a note is played that's 20 cents sharper than Ab, and person #1 says "that's an Ab" while person #2 says "that's a note a touch sharper than Ab", most people consider neither statement to disqualify them from having absolute pitch. But there is a difference. Moreover, no person on Earth can name a pitch down to, say, a couple decimals of absolute frequency value. Doesn't this imply that the skill exists as achievable points on a spectrum, not as a flat binary?
"A good ear" and grasp of music theory go hand in hand. Strongly disagree that the latter is limited to classical music. The best musicians in jazz and pop music absolutely know how to incorporate the circle of fifths, types of cadences, Roman numeral harmony, etc., in their playing. That's... music theory! While there are musicians who can make it without that, they are the exception, not the rule.
On the contrary; it's quite possible to design automated tests that operate on release artifacts. This is true not only at the integration level (testing the external interfaces of the artifact in a black-box manner), but also at a more granular level; e.g., running lower-level unit tests in your code's dependency structure.
It's true that not all tests which are possible to run in debug configuration can also be run on a release artifact; e.g. if there are test-only interfaces that are compiled out in the release configuration.
I think maybe the source of the confusion in this conversation is perhaps the kind of artifact being tested? For example, if I were developing ffmpeg, to choose an arbitrary example, I would absolutely have tests which operate on the production artifact -- the binary compiled in release mode -- which only exercise public interfaces of the tool; e.g. a test which transcodes file A to file B and asserts correctness in some way. This kind of test should be absolutely achievable both in dev builds as well as when testing the deliverable artifact.
I develop multi-platform C and C++ code (intermingled with some python for testing and automation), and my experience has been that while MSYS + Git Bash works, I run into 'rough edges' on that side much more frequently than on the WSL side.
The exemptions were very imperfect. Even if musicians and certain types of performers were exempted, this legislation has had an enormous effect on theater organizations, for example, especially at the semi-professional / community level. It's typical for these orgs, which have very limited budget, to hire actors and the creative team (set designers, lighting designers, sound etc.) as 1099 workers. The money is simply not there to be able to pay everybody at an hourly rate for the amount of time that's actual spent on these projects, and the outcome has been that many theater companies are unsure whether they can continue to operate at all. Unless the thinking has changed recently and my understanding is out of date, this is a situation that continues to be worrying to both theater artists and directors of theater orgs.
Or, arguably, the C++ equivalent is just the destructor. 'Defer' and 'ScopeExit' are interesting, but I'm not sure if I see the advantage over widely understood first-class language features. If you don't want to write a class just to get cleanup logic at scope exit, consider using std::unique_ptr with a custom deleter -- this construct is for managing resources in a general sense, not necessarily just memory allocation.
I keep seeing people saying this when discussing Rust in relation to C++. It's not untrue, but I would counter by saying that people who were writing C++ without having a full understanding of ownership and lifetime semantics were writing buggy code. Rust just makes understanding those semantics required to get your code to compile.
I also work in the resource-constrained / embedded native space and have had to work within the kinds of constraints you're describing. I think you're severely misunderstanding what the comment you're responding to is proposing.
Having a large body of existing packages would be nice, but if this can be used with a private repository, it's be hugely valuable to me even if it had no open source packages available at all. I work in a corporate context where projects frequently have multiple complex internal proprietary dependencies. The hacks and workarounds I've seen just to get a sane build up and running in this context are unbelievable. After having used Cargo for some personal projects, I yearn for a similar tool in the C / C++ landscape.
What a lot of people miss about the utility of Venmo is that it lowers the social cost of squaring up minor debts.
Think of the example of a large group of friends often gathers in arbitrary subsets of the group to go to dinner. If Alice orders salad every time and Bob orders steak, and we split it down the middle each time, that kind of sucks for Alice. Some people suggest rotating picking up the entire bill between outings, but I'm unconvinced that this really ends up working out equitably in practice.
Or, say Dora has a habit of leaving happy hour after the first round, which was picked up by Charlie. It's not a huge cost, but...
In a world without instant electronic payment, the meek Alices and Charlies of the world lose out because there's a social cost to asking somebody to repay a small debt (paying <$10 by cash is a hassle). By making these frictionless, I'd argue that Venmo reduces that cost by providing an easy way to equitably split without levying the inconvenience on the restaurant, as with separate checks.
- the restaurant doesn't do separate checks for large groups
- friends ordered meals with significant variance in case, and the server wasn't initially told to keep items separated
- you want to split communal items in an arbitrary fashion
> Be that as it may in most cases, the compiler shouldn't make an assumption that this is always the case. If I don't pass any optimization options, and especially if I pass -O0, the correct behavior should be "no surprises".
The problem with this argument is that before the compiler even enters the picture, the C standard has always specified that signed overflow is UB. I'd argue that providing the additional guarantee that "actually, it'd defined" for the -O0 case only is a bigger surprise than "funny stuff with your code." To categorize treating signed overflow as UB as doing "funny stuff" is off the mark; the behavior was always unspecified.
> I think you're underestimating the amount of people who will run "cc foo.c -o foo" and expect it to work, without thinking too much about UB as defined in the C standard, and who haven't ever heard of -fwrapv. By virtue of passing "-O1" in, it's safe for the compiler to assume you know what you're doing, but the default behavior should treat the user as a novice.
I can't remember the last time I actually invoked a C compiler directly on the command line in the way you're describing (rather than through higher-level build configuration; e.g. generated Makefiles, VS solutions, whatever). I would hope such a use case for non-toy code is... rare.
I don't disagree, and I'm not sure what about my comment would suggest that I expect consistency there. What I was arguing was that any code relying on UB is dangerous / broken, so it's a good idea to surface any underlying code issues at all optimization levels by standardizing how it's handled.
* works with middle click for new tab
* integrates with accessibility devices
* works with right click + open in new window or similar options
* etc. etc. etc.
If it's notionally navigation, don't use javascript soup: use a link.