lyricaljoke
It really feels like the types of software which have inexplicable pauses / hiccups has grown. Sometimes even my OS (a Debian flavor, although it's a corporate managed distribution that might be to blame) locks up from time to time when I'm tethering on my phone with limited bandwidth, which is highly suspicious.
* 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.
* 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.
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?
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.
Isn't that just normal "crying wolf"?
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.
My comment was more responding to the claim that this wouldn't be a useful tool without a large body of open-source packages, which I disagree with.
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
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 understand that there are some use cases where teams release binaries compiled with -O0 if they've identified that avoiding unexpected effects of aggressive optimization is more important than raw performance. But in this case, it seems like the right solution is to allow such teams to specifically opt in to allowing overflow via -fwrapv.
This person is describing an error-prone reimplementation of std::unique_ptr with a custom deleter. I could understand the value of an article like this if the use of C++11 were not allowed, but given that the article is written with C++11 in mind, I fear the author has totally missed the point of RAII-style resource management that the newer language-level constructs provide.
Deterministic destruction and associated logic, as well as the RAII strategies that follow, are perhaps the greatest strength of C++. Languages like Rust have gone on to improve this even further by eliminating some of the greatest sources of error. Capabilities like this don't seem accurately described as C++ learning from D; indeed, if D provides hooks for running logic when names fall out of scope, that seems more accurately described as vice versa.