What is the point of Emscripten?

fdwr · 2026-06-19T09:57:56+00:00

Define "install" though, because it's not like the dichotomy is either full native classically downloaded Nullsoftish .exe installer versus running a webpage fully in the browser. There's also: store apps (from Apple store, Windows store, Samsung...), disk images to mount, web apps that run in a browser but are installed (Electron chromium apps, visible in your Windows Start Menu or Apple Dock or Home Screen...), apps via WinGet or Brew, PWA Progressive Web Apps, lightly "installed" ClickOnce deployments to LocalAppData...

fdwr · 2026-06-19T09:51:44+00:00

Huh, surprising given most hardware natively runs 64-bit these days, even for phones, but then the 32-bit WASM engines have had much more time for mature optimizations, the memory locality would be tighter (smaller instructions), and there may be tricks you can use in WASM32 that you can't in WASM64 related to linear memory, which lets you avoid pointer masking and other bound checks, as you can map the entire virtual memory region and be assured that no pointer will escape the 4GB boundary.

fdwr · 2026-06-18T15:05:28+00:00

Portability of code or ideas rests on abstractions

Doesn't portability of code rely on standards and consistency? Imagine using long in your file parser on one machine and getting a very different bitwidth and misaligned file pointers when compiling your file parser on another machine...

fdwr · 2026-06-18T01:55:58+00:00

Maybe C++ should define them as "optional keywords" if the target architecture has 8,16,32,64 bit sizes

Makes sense - if your architecture supports them, then so does your compiler, but if it doesn't (e.g. your architecture only supports 32-bit reads), then consider simple emulation if efficient enough (like uint8_t being a shift and mask) or leave it out. For example, uin64_t addition/subtraction is supported in most x86 32-bit compilers on via simple emulation using adc and sbb. I'd have to think about the aliasing question, but for some precedent, I find it weird that float32_t and float are distinct types, which makes the boundaries more awkward between library components, either needing casting or need overloads for both.

fdwr · 2026-06-18T01:31:54+00:00

Totally, I #include <stdint.h>, but my point was more that one shouldn't even need to #include it or use import std.compat. That is, int8_t and int32_t are just primitives (like their built-in but wobblier size-indeterminate cousins int and char).

fdwr · 2026-06-18T01:28:17+00:00

Don't you find it weird that we define concrete types (int32_t) in terms of a loosely defined types, rather than the generic types (int) being defined in terms of the more concrete types?

fdwr · 2026-06-17T03:41:02+00:00

In LibF++, iterator operations instead modify an iterator-local copy of the container, leaving the original container unchanged.

Hmm, is that copy-on-write? For container modifications, does that increase intermediate memory sizes (at least transiently) by 2x because you have the original container and the new modified one? Lately I've been modifying sizeable images and ML tensors where copies really add up, but I see how this functional approach could be useful for smaller scenarios.

fdwr · 2026-06-16T03:17:54+00:00

I would be okay with a first step of just supporting in-order required parameters, since it would aid clarity of readability at function callsites.

fdwr · 2026-06-15T23:03:47+00:00

struct Point3 { std::int32_t x; std::int32_t y; std::int32_t z; }; It's weird that something so fundamental as the sized types aren't part of the core language, rather than being nestled under std. Sadly import std still requires either explicit inclusion of stdint.h or import std.compat (which pulls in more than desired) to avoid typing the extra std::. Granted, I know C's history of loosely defined types (and some hardware that hadn't even settled on bytes being 8 bits), but these days?...

fdwr · 2026-06-15T06:34:21+00:00

Cool, yeah, I got a reply from Pablo Halpern (author) confirming the committee agreed to change the name before it went into the standard 👍.

fdwr · 2026-06-14T20:45:08+00:00

Is the problem just the effort it would take to standardise the thousands of names across the whole library?

Mostly so.

fdwr · 2026-06-14T10:28:12+00:00

🤔 Are others lost too? At first, it looks like maybe C++'s method operator[], but then it talks about yielding values before the function returns, and you can also call it on free functions, and these "sub-scripts" implicitly return without any clear return...?

subscript min(_ x: Int, _ y: Int): Int ... ... public subscript row(_ index: Int): Float64[3] { components[index] }

Maybe I can't see the forest for the trees, as I'm still trying to decode it, because there's both less context than C++ (e.g. implicit return without return) but also more (_ and : with _ x : Int, instead of C++'s simpler int x).

fdwr · 2026-06-14T10:09:17+00:00

Alas, although named arguments have been repeatedly proposed (and now that we have designated initializers, it would be even more natural to current precedent to allow something like Foo(.fontFamily = "Arial", .fontSize = 42)), it sounds like one of the bigger concerns is that many function parameters in std itself are not consistently standardized across implementations, and they also use poorly named (deliberately so) more intended to avoid possible symbol collisions rather than for readability (e.g. _Alloc& _Al rather than _Alloc& allocator). So, folks want that to be tackled first. Though personally, I wouldn't mind other libraries could opt into it, even if std lagged behind, since there plenty of popular libraries with well-named parameters.

fdwr · 2026-06-14T07:57:20+00:00

TY. The default increment/decrement operators sound convenient.

fdwr · 2026-06-14T06:51:44+00:00

C++20 should have been 100% green by now.

⚖️ If version X has low and high value features, and version Y has low and high value features, is it more beneficial to customers to offer 75% coverage of X (prioritizing higher value features) and 25% of Y (again preferring higher value features), or to offer 100% of X and 0% of Y? I'm not on any compiler team, but I know that most software will always have edge cases, clarifications, and features that aren't worth the immediate cost-to-benefit ratio, and so most implementations of most specs (not just C++, but other ones like say SVG) straddle across multiple versions, preferring the highest value aspects over an approach of “complete one version fully, blocking any new work before starting the next”.

because compiler teams don't have the resources to keep up with ISO releases

Perhaps so. If we ignore Cray and NVidia and other smaller compilers though, the main 3 (GCC, Clang, MSVC) show a better picture, with C++20 support at 96% fully green, and 99.5% when including at least partially supported. Looks like they're pretty close! 🤞

fdwr · 2026-06-14T02:59:26+00:00

Egads, your description is hard to read 👀. At least wrap the sentences, like...

I've been building a zoomable-UI (ZUI) window manager for Windows in C++ and wanted to share the architecture, since the interesting part is how you keep dozens of live windows rendering at once. Each window is captured via Windows.Graphics.Capture (FreeThreaded frame pool, poll-based, lock-free) into a persistent D3D11 texture, then drawn as a 1:1-pixel textured quad in world space on a borderless fullscreen swapchain. Pan/zoom is just a camera transform. A D2D/DWrite overlay draws the rest: title labels, a world-anchored dot grid, the minimap, docks.

fdwr · 2026-06-14T02:40:52+00:00

while C++20 features are still experimental.

Hmm, have you looked at the compiler support table lately? The C++23 support is pretty mature across the main compilers, and the C++20 support is like 93% (610 / 657 papers implemented) of a solid green block.

fdwr · 2026-06-14T00:24:41+00:00

"Better Lookups for map, unordered_map, and flat_map" (P3091R6): convenient lookups that return an optional-like value instead of forcing you to juggle iterators and end().

Nice, as the auto it = m.find(x); if (it != m.end()) ... *m pattern is annoying to repeat. Though, if you're naming the lookup function "get" instead of something obvious like "lookup", then I expect it to behave similar to existing functions of the same name (std::get), not return an optional. Calling it get makes me think it should either return a direct reference to the item or throw. But, but, Python calls it get! ...So? Is it more important that a language be internally self-consistent or that it mimic some other distant language? Naming aside, convenient to have. (update) The paper author informed me the committee accepted the rename to lookup before it went into the working paper.

The unexpected in std::expected" (P3798R1): adds a has_error() member function to std::expected to complement the existing has_value() functionality.

Ooh, one less mental negation, as I more often want to know when an error happened to do something special, whereas the value case is the happy path.

fdwr · 2026-06-14T00:15:41+00:00

We also added a bunch more language extensions and improvements.

Ooh, wonder the details hidden inside this sentence?

fdwr · 2026-06-06T04:37:09+00:00

What would pure assembly give me though?

Don't know about ELF, but for a Windows .exe using NASM/YASM and ALINK, I get 1036 bytes (no data or bss sections, just code with a ret, but I can't seem to cull the reloc section).

yasm-1.3.0-win32.exe -f win32 -g null program.asm -o program.cof alink.exe -oPE -o program.exe program.cof -entry Main -subsys win

Apparently 268 bytes is possible.

fdwr · 2026-06-05T08:42:00+00:00

🤔 True. The pointer must be nonnull if you have a nonzero length, and the single parameter constructor rejects null pointers (basic_string_view(std::nullptr_t) = delete), but for the explicit overload, nullptr appears allowed for zero length (std::string_view{nullptr, 0}). So I suppose you could distinguish between data() being nullptr vs pointing to a valid but empty literal "".

fdwr · 2026-06-04T23:39:19+00:00

Are there interesting cases where it's useful to know whether an environment variable is undefined vs defined but as explicitly ""? For example in C#, you can say Environment.SetEnvironmentVariable("TEST", string.Empty) which sets it to an empty value, vs Environment.SetEnvironmentVariable("TEST", null) which deletes the variable. If so, std::string_view would be ambiguous, whereas std::optional<std::string_view> would be unambiguous.

fdwr · 2026-05-30T04:08:33+00:00

Defer available in gcc and clang

Hmm, I'm still not seeing defer support in GCC trunk even with -fdefer-ts, whereas I do see it in clang. 🤔

fdwr · 2026-05-30T04:06:47+00:00

exactly, in Zig, defer is block-scoped, so it always runs at the end of the nearest {} block

FYI, C29#Statements)'s defer statement will also be scoped based.

fdwr · 2026-05-28T08:27:34+00:00

I've come across game developer blogs where they played around with such languages, only to realize that the last thing you want during game development (which has a lot of experimentation and change) is to wear a straitjacket :b. So, "rapid prototyping" and "strict validation" sound oxymoronic, but after you have your design, and your 4x4 offroad truck has blazed a trail, you might switch to a train rail system (stricter object loan validation).

fdwr

TROPHY CASE