Trigraphs are handled by the preprocessor, so if you’re not handling that, then that’s fine. Digraphs are handled by the tokenizer, however.

Are digraphs and trigraphs deprecated?

Did you reference the standard?

It’s at least partially because the specification was designed to detect and thwart attempts to tee the video and audio data in order to bypass copy protection on DVDs and Blu-Rays, iirc.

deleted by creator

This doesn’t specifically use the template metaprogramming interface for C++, but seems to do what you want regardless. https://github.com/jmmartinez/easy-just-in-time

I’ve never used the library myself though.

Yup

That episode aired in March 2002.

LHC began operating in 2010 and the Higgs Boson was confirmed in 2012.

The focus of the 2002 episode was on the SSC, the boondoggle of a collider that was being built in Texas and was cancelled in 1993.

Yeah, definitely :)

The default dev profile is defined as:

[profile.dev]
opt-level = 0
debug = true
split-debuginfo = '...'  # Platform-specific.
strip = "none"
debug-assertions = true
overflow-checks = true
lto = false
panic = 'unwind'
incremental = true
codegen-units = 256
rpath = false

You can find more information in the cargo book page on profiles

As mentioned in the article, this concerns release mode, which already does not have symbols by default for user code. It does have symbols for the standard library code, however, due to how the binaries for the standard library are shipped (i.e. with symbols only). This change simply also removes standard library symbols.

If you need symbols, you can use default debugging build, or if you need both compiler optimizations and debugging symbols you can create a custom profile that inherets from release with debug = true. The second you already need to do to get full debugging symbols right now, so this isn’t really much of a change from a workflow standpoint.

My possibly wrong, not researched, and half remembered from college first impressions are: the band gap is lower than Silicon, so it might not be appropriate in room temperature applications/very small gate sizes due to dark current. But the mobility is very high, meaning lower voltage gates might be possible, or higher switching speed/lower latency gates.

oh dang! I am a dummy and completely missed the first one somehow.

Not actually a use-after-free bug, just memory corruption due to a non-aligned pointer. (Calculated from the unsound math in safe code you mentioned.)

Non-aligned memory access in CPUs is a “don’t care” condition that can do whatever is most convenient for the processor implementation. Typically, the cause for the memory corruption is due to caching. Cache lines are a certain size, in this case 128 bytes. Let’s say you want to fetch 16 bytes of data, and the processor specifies for simplicity that all data you fetch or this width should have an address divisible by 16. This is so that the data in question is entirely within a single cache line, and the memory controller doesn’t have to handle fetching two cache lines for a single load, which would be slower for no good reason.

If we violate this contract, let’s say we load a pointer with an offset that is 15 mod 16. Then the processor fetchs the cache line where the data starts, slots it into the cache memory, then reads from the cache memory and you get back either:

1. 7/8 times: the entire correct data, because the pointer is not also at the end of the cache line
2. 1/8 times: the first byte of the correct data and 15 bytes of other data from the cache, which data exactly is governed by the caching behavior of the L1 cache and can be difficult to predict.

This affects both loads and stores, so you can overwrite other cache lines. And doing so may mark them dirty depending on implementation. When they get evicted from the cache if they’re marked as dirty (either from this or some other write) they’ll be committed, either to the L2 cache, or if the cache is write through, also to memory. This is the most likely source of the memory corruption, to my understanding.

There are many other ways of making methane, it’s not a very complicated molecule: CH4. It gets exciting when there’s a lot of it, because it’s not the most energetically stable molecule.

EDIT: looks like the article goes into it.

The last draft before publication: https://j3-fortran.org/doc/year/23/23-007r1.pdf

This is a cool idea. There are other programming languages that have libraries that expose similar behavior. For instance, Rust has the uom crate, Haskell has the units package, and C++ has the header only library SI.

But there is something to be said about it being built in.

Change to Haskell formatted commas and the problem goes away :D

{ "a": 1
, "b": 2
, "c":
    [ 3
    , 6
    , 9
    ]
}

If the streching is so small as to be unnoticable (and I agree it’s pretty subtle) then I also don’t really understand the benefit.

Typically, the idea behind this sort of design is that it should be unnoticeable. The motivation is that, with other monospace fonts, the differences in character width, along with the inconsistent spacing and line thicknesses are both noticable and distracting. Some of this badness is avoidable, and this is what this font attempts.

and yeah that height difference is really weird. That almost seems like a bug.

I’ve been informed, (and had to double check because I didn’t believe it,) that the two "i"s are actually the exact same height. The first looking larger than the second is an optical illusion. Font design is hard.

True, they are the exact same height. Holy optical illusion, Batman!

I suppose this is part of what makes font design so difficult.

Here’s your code example in the editor. I don’t personally think the difference between the 'm’s is super noticable. But what did strike me a lot more is the difference in height between the two 'i’s in the first line. I think that difference is pretty bad.

If you’re looking for a text, a short web search turned up Clifford’s D-Branes (TOC), it seems to be reasonably well reviewed. It is, of course, a graduate level text.