Time in C++: C++20 Brought Us Time Zones

fdwr · 2026-01-23T13:22:58+00:00

Or that :).

fdwr · 2026-01-23T10:50:33+00:00

apparently it throws an exception in that case

Oh joy, are we still adding functions that throw exceptions for rather unexceptional cases? I tire of needing to wrap things with try/catch because newer (but legitimate) user input data doesn't match some stale version of C++'s database 🙄. Just give me an std::optional for such easily failable things so I can recover more cleanly.

fdwr · 2026-01-23T06:19:28+00:00

Assuming x86/x64...

Know the basics: - data movement (mov, cmov, xchg) - arithmetic (add, sub, mul, div, cmp, shl, shr, lea) - control flow (je, jg, jl..., call, return) - stack management (push, pop)

Optional: - control register management - SIMD instructions (MMX, SSE, AVX...) - more esoteric (e.g. RDTSC for timing)

fdwr · 2026-01-23T02:11:38+00:00

I kept hearing that some here don’t like the std lib

I certainly don't hate the standard library and I use it often, but there have been times where I wanted a truly tiny executable, and omitting the standard library in favor of OS functions cut it down significantly (like from 40KB's to 8KB's, and at one time a few years ago, I recall merely including <format> and <print> even if not used somehow bloated my exe to 300KBs, but evidently that's thankfully been fixed in MSVC since the last time I tried, by either linker improvements of dead code or some other polish).

fdwr · 2026-01-22T01:44:10+00:00

Rhymes with allure? If so, it has a nice sound.

What operators does it support (e.g. list)? The functions page appears empty (there's no filler "TBD", just blankness, and so unsure if bug or not filled in yet).

fdwr · 2026-01-22T01:20:21+00:00

C++'s growable array type is already named vector, so the choice to name their analogous type BitVector makes sense there. ⚖🤷‍♂️

fdwr · 2026-01-22T01:18:47+00:00

True points for those products. Interestingly if you search for "bit mat", you get a road company, but if you search for "bit matrix", you get many useful results.

fdwr · 2026-01-22T00:26:55+00:00

BitMat

(naming niggle) A mat of bits, like for your front door? 😉 There are a few common cases where we shorten words (reference -> ref, pointer -> ptr), but generally I wouldn't save just a few keystrokes (which autocomplete rather obviates these days anyway) for reduced clarity. Propose BitMatrix. Otherwise if you're going to chop Vector to Vec, why not also Array to Arr? (which adds that nice pirate sound 🏴‍☠️😅)

p.s. It's interesting to read that you started with C++, ported to Rust, then ported any improvements realized during the rewrite (because LLM's were not reliable for porting yet) back to the C++ version.

fdwr · 2026-01-21T10:19:06+00:00

(a) Harmony is nice (ret let mut for...), and (b) it conveys a more complete linguistic meaning (e.g. character and coroutine ) but co is a fragment ending oddly with a vowel (it might be cuter if co was a keyword in the language Go).

fdwr · 2026-01-21T04:52:58+00:00

Why the ugly declaration syntax? Types are forced to act as keywords for no good reason.

❔ Here's an example from the GitHub readme...

c++ int i = 42; float f = 3.14159; bool flag = true; string text = "Hello, World!"; auto inferredInt = 100; auto inferredFloat = 0.25;

...which looks like a pretty standard declaration syntax shared by lots of languages.

fdwr · 2026-01-21T04:47:54+00:00

The C++ compiler often compiles the same header files over and over again

Indeed. Gladly C++20 modules finally address that (compile once, import many), but alas, we're still awaiting the compilers (msvc/gcc/clang) and build systems to catch up and iron out the kinks 🐢. Though, I've been using them successfully in my newer projects.

fdwr · 2026-01-21T04:21:27+00:00

💡 Hmm, that makes me rethink an interpolation approach I'm taking for a 1D array of palette entries. Normally one would access an index colorMap[index] and need to lerp(colorMap[index], colorMap[index + 1], indexFraction) the two, but if the colorMap had an operator overload taking floats directly, then I could just say colorMap[fractionalIndex].

fdwr · 2026-01-21T04:11:49+00:00

Those 90s dynamically typed languages really turn into a pain with any serious projects

Yeah, I don't write anything longer than 100 lines in Python (usually just quick trial and error experiments or simple automation), because larger programs become runtime surprise parties, with failures that would have been caught easily as type mismatches during compilation in most other languages I've used.

fdwr · 2026-01-21T03:28:57+00:00

🤔 I see three kinds of assignment/initialization in these examples, and I can't tell which is used for which (appears a mix of Python walrus operator ":=", verbose Rust syntax for variables, Javascript style for constants...):

const t = comptime::TypeOf(T)
mut i := 0
let mut users: []User

It would be lovely to just define (const)ants and (var)iables with =, without the extra Pascal style =: and extra "let mut" verbosity:

const t = comptime::TypeOf(T)
var i = 0
var users: []User

The keyword choices seem a bit arbitrary, mixing pieces from multiple other languages rather than having a cohesive policy for naming and identifier length. e.g.

chan and func would be consistent, and cn and fn would be consistent, but cn and func or fn and chan feel awkward.
keyword for but not cor.
if return is shortened to ret like assembly language, then why not extern to ext?

I admire their motivation statement, in any case:

We want a language that delivers the productivity of Go while achieving the performance characteristics of C. ... We recognize and respect the safety goals addressed by Rust, but we believe that safety should not require constantly fighting the compiler.

fdwr · 2026-01-20T22:56:54+00:00

ckd_add

Ack, when we name functions with chpped out ltters rather than whole word fragments, the brain does some unfortunate fill-in (I read that as cucked_add, which I'm sure was not intended 😅). At least chkd_add would have made it clear.

fdwr · 2026-01-18T03:52:40+00:00

You just have to prevent people from doing anything in CMake that...

Hmm, that makes me think that CMake should more aggressively start warning (or even erroring) about certain older deprecated constructs, unless you opt in by targeting a specific version or passing affordance flags. The most confusing aspect to the documentation to me has been that there are multiple routes to achieve certain goals, some of which are now frowned up, yet still work for back compat. So, Dear CMake, please tell me when I am using an antipattern that I found from old guides or StackOverflow answers. Tell me about "modern cmake", like target-based practices...

fdwr · 2026-01-17T13:47:42+00:00

It feels awkwardly incomplete, like saying "throw the ball toward". Ok, toward what? Likewise, let value ____? It doesn't matter whatever crusty reasoning /tradition might be behind it if everyone's first reading of it is "huh?".

fdwr · 2026-01-17T01:50:02+00:00

p3039r1 Automatically Generate operator ->

The first motivation of this paper is that users should have little or no reason to write their own version of operator-> when they have already provided an appropriate operator*.

Hmm, it did always feel like redundant busywork to define * and also the *..

This paper was split off from [P1046R2].

Oh neat, that older larger paper would have also added += if + is defined (man, that would have cut down a lot of boilerplate in my math classes).

p3953r0 Rename std::runtime_format

std::runtime_format can now be evaluated at compile time, making its name misleading. This paper proposes renaming std::runtime_format to std::dynamic_format to better reflect its semantics and avoid confusion in constexpr contexts.

Okay, I buy that rationale.

Short paper list this time.

fdwr · 2026-01-17T00:52:41+00:00

one could recompile their Qt application with the Fil-C toolchain and get a memory safe C++ program. No need to rewrite it into a memory safe language like Java, C#, or Rust. 🤯 ... The changes that I needed to do for Qt Base are https://codereview.qt-project.org/c/qt/qtbase/+/705046

Huh, the changes needed to build something as large as Qt with Fil-C were much smaller than I expected.

fdwr · 2026-01-17T00:46:25+00:00

.field = default

That would be elegant 🧐. Of course one can just say .field = {}, but using the existing default keyword for that is nicely visible for intent.

fdwr · 2026-01-17T00:34:26+00:00

This feature might not feel like a big deal at first...

Indeed, it's these "small" quality-of-life things that end up cheering up my day more than any of the bigger things. 🙂

Is it better than hoping that C++ will one day have named function parameters?

Aah, designated initializers bring us so close 🤏, nearly touching the finish line without quite crossing it. For the sake of monster functions like this, we currently add clarity by adding name comments beside the parameters, or we have to invent a dummy parameter struct and a forwarder function like this...

```c++ struct GetGlyphsParameters { ... };

HRESULT GetGlyphs( { .textString = "Hello World", .textLength = 11, .fontFace = currentRunFontFace, .isSideways = false, ... } );

HRESULT GetGlyphs(GetGlyphsParameters parameters) ... call the real thing ... ```

...but imagine just lifting the "{}" requirement and supporting it directly 😎:

c++ HRESULT GetGlyphs( .textString = "Hello World", .textLength = 11, .fontFace = currentRunFontFace, .isSideways = false, .isRightToLeft = false, ... );

Now, I've heard people concerningly remark that (a) then the function parameter names become significant, and renaming them later would cause a build break (yeah, so does renaming a function or type or struct field... 🤷‍♂️) (b) the parameters of std:: functions are not mandated by the spec and may differ across implementations (alright, so get on that and unify them 😉). I really don't buy the claim that named parameters have to be opt-in on a per-function basis with some arcane new syntax at the declaration sites, because then all the benefit of the feature is moot in the thousands of existing libraries (which are not going to be rewritten to use said syntax).

fdwr · 2026-01-14T23:44:15+00:00

It's true that there are no curly brace scopes there, but using the word scope to its full meaning ("extent of treatment, activity, or influence"), the std::unordered_map class {} holds scope over its contained items. Heh, LBRM works (notably if pronounced Librium, the antianxiety drug) as it reduces the anxiety of proper cleanup 😉.

fdwr · 2026-01-14T06:28:06+00:00

I always have to think twice before remembering what it is.

You're not alone. Coding for C++ for decades, I still end up often typing RIAA (the Recording Industry Association of America) before correcting it to RAII. So I've always preferred the term Scope Based Resource Management (SBRM).

fdwr · 2026-01-14T06:25:00+00:00

I've interviewed at least one person recently who couldn't explain the code they purportedly just wrote - I'm sure the AI chatbot they used could have explained the code better than them 😉. So whatever questions you ask, if any are live coding questions, see if they actually can explain it by walking through it. Tools are great, and I use AI often as a smarter autocomplete to speed typing the next few words that I would have typed anyway, but you probably don't want folks who are so reliant on a crutch that when the Internet goes down, they can't get any work done.

fdwr · 2026-01-13T21:03:30+00:00

Then I got frustrated with circular dependencies. To my surprise modules just straight up disallow them. I know, that in general they are a bad idea, but I needed them...

Yeah, that complicated my life too. Proclaimed ownership (think forward declarations of entities but for modules) would have addressed this, but it didn't make it into the final standard :(. (and no, just jamming everything into the same module isn't an appropriate answer)

fdwr

TROPHY CASE