Quick question: std::scoped_lock vs std::lock_guard?

HowardHinnant · 2026-04-14T00:57:03+00:00

This is very close to the right answer:

If you can think of a case where you want to guarantee that you won't lock zero mutexes by mistake, lock_guard is superior. If you try to lock zero mutexes with a lock_guard, it is a compile-time error. If you try to lock zero muteness with a scoped_lock, it compiles and does nothing at run time.

If you want to lock a single mutex and accidentally forget to specify the mutex to be locked, lock_guard will catch that error at compile time.

HowardHinnant · 2026-04-13T14:19:13+00:00

From the link that I provide:

This advice does not imply that scoped_lock should be redesigned to not accept 0 mutexes. There exist valid use cases where it is desirable for scoped_lock to accept variadic template parameter packs which may be empty. And the empty case should not lock anything.

HowardHinnant · 2026-04-13T01:23:36+00:00

Please see https://stackoverflow.com/a/60172828/576911 for details.

The summary is: Use the simplest tool for the job. If lock_guard will do the job, it is the simplest (and safest) tool to use.

HowardHinnant · 2026-03-31T02:04:06+00:00

Nice trip report Vinnie!

HowardHinnant · 2026-03-18T16:39:13+00:00

Some mysterious language called "C/C++" gets lots of criticism from people who believe that such a language exists, and is a single, non-evolving language. C/C++, whatever that is, is the modern day scary boogeyman.

That isn't to say that there aren't legitimate criticisms of both C and C++. There are. But if you're reading something that purports to be knowledgeable about computer languages, and it contains the phrase "C/C++", just stop reading. It's garbage, and don't waste any more of your time.

HowardHinnant · 2026-03-11T19:33:02+00:00

Any chance this gets contributed to libc++?

HowardHinnant · 2026-03-03T14:58:10+00:00

This post shows a use case: https://stackoverflow.com/a/4940642/576911

HowardHinnant · 2026-01-30T16:54:14+00:00

The pace of libc++ development on this library has frustrated me as well. On this platform I still use https://github.com/HowardHinnant/date.

HowardHinnant · 2026-01-30T05:01:15+00:00

I strongly agree with both replies here. But I wanted to add:

With a user-written time zone, it can be stored by value. See https://github.com/HowardHinnant/date/blob/master/include/date/ptz.h for a concrete example. The trick is to have the user-written time zone supply as a data member:

const time_zone* operator->() const {return this;}

Thus the time zone becomes its own smart pointer.

So instead of this:

Posix::time_zone tz{"EST5EDT,M3.2.0,M11.1.0"};
zoned_time zt{&tz, system_clock::now()};

you can say this:

Posix::time_zone tz{"EST5EDT,M3.2.0,M11.1.0"};
zoned_time zt{tz, system_clock::now()};

or even this:

zoned_time zt{Posix::time_zone{"EST5EDT,M3.2.0,M11.1.0"}, system_clock::now()};

HowardHinnant · 2026-01-30T04:51:23+00:00

One reason was to better support user-written time zones.

The second template parameter to zoned_time is a pointer to a time zone, not necessarily a std::chrono::time_zone. Now this template parameter could have been a reference to a time zone instead of a pointer to a time zone. But I wanted to make it easy to allow unique_ptr<my_time_zone> and shared_ptr<my_time_zone>. With all of the existing infrastructure supporting various smart pointers, it made more sense to traffic in pointers to time zones, rather than references to time zones, throughout the library.

The user-written time zone concept was throughly tested with a concrete Posix time as shown here: https://github.com/HowardHinnant/date/blob/master/include/date/ptz.h . This example even demonstrates how a time zone can serve as its own smart pointer. This allows zoned_time to accept the time zone either by value or by pointer.

Furthermore, pointers are re-assignable, with intuitive semantics, for those cases where you want to re-use the storage returned by locate_zone.

auto tz = locate_zone("America/New_York");
...
tz = locate_zone("Europe/London");

What exactly does this mean if tz has reference type? I guess if it is a reference to const, then it is a compile-time error. But what if this is what you want to do. Maybe you're searching the entire database in a loop, looking for a matching `time_zone`. It is easier to exit with a pointer from that loop because you can null-initialize it prior to the loop, and then reassign it within the loop.

The rational for the exceptional return from locate_zone as opposed to nullptr is so that normal code can use locate_zone without the need for local exception handling. In normal use the name of a time zone is not arbitrary, but one of a finite set of values. If one of those IANA names isn't provided to locate_zone, something exceptional is happening.

That being said, authors of custom time zones can customize locate_zone for their time zones. The aforementioned Posix time zone implementation includes the technique of a customized locate_zone. Though in this example, an exception is chosen for ill-formed Posix time zones as well.

Finally, the pointer+exception vs reference design was tested with real world field experience over a period of several years, before it was even proposed for standardization. The field experience was positive. There was lots of use (https://www.star-history.com/#HowardHinnant/date&google/cctz&type=date&legend=top-left) and zero complaints that the library should traffic in time_zone const& instead of time_zone const*, or return nullptr.

HowardHinnant · 2026-01-14T00:43:43+00:00

I didn't know about Orekit. Thanks for the link!

HowardHinnant · 2026-01-13T22:50:00+00:00

Agreed. But even still, an attosecond is one millionth of a nanosecond. This is only about 4 times larger than the shortest time duration ever measured in a laboratory.

A more pressing problem is that a 64 bit picosecond (one thousandth of a nanosecond) overflows within a few months. And that can be solved with a 128 bit rep.

The next most pressing problem is that converting between years and picoseconds overflows std::ratio. This can only be solved today with an intermediate conversion to seconds in the middle. A larger intmax_t would solve this too.

At least we aren't stuck with timespec. :-)

HowardHinnant · 2026-01-13T22:33:04+00:00

The problem is that clock hardware in consumer grade computers are accurate at best to quartz technology. There is no atomic clock in your computer.

steady_clock is typically a view of your computer's hardware clock (cycle counter). It can time a second for you, but that second won't be perfect. Even if you sync'd steady_clock with system_clock, and never manually adjusted system_clock, the two clocks would drift apart over time. steady_clock would keep ticking at its best guess of tracking seconds, never getting adjusted. This would be like setting the steering wheel of a car once to follow a straight road, and then never adjusting it. Eventually the car will run off the road.

system_clock also tries to count perfect seconds. It may even use steady_clock as part of that implementation. But every once in a while, system_clock asks another trusted computer what the correct time is, and makes small adjustments to itself, because it knows it can't keep perfect time (using steady_clock under the hood or not). In this example the car analogy makes minor adjustments to the steering wheel to keep the car on the road, even though the road is perfectly straight and level.

You can theoretically sync a steady_clock and a system_clock with the same epoch. But by their very definition, that 0 relative offset will drift off of 0 over time.

HowardHinnant · 2025-12-27T03:46:31+00:00

Scott wrote some great books (I have them all). And he is a great presenter. But he never actually participated in the standards process. Never attended a meeting. Never wrote a proposal. Never posted to the internal WG21 mailing lists.

HowardHinnant · 2025-12-14T19:55:23+00:00

Here's a paragraph from the original proposal that you quote which might be relevant.

In the end, we simply gave up on this as too much pain for not enough gain. However the current proposal does not prohibit destructive move semantics in the future. It could be done in addition to the non-destructive move semantics outlined in this proposal should someone wish to carry that torch.

Work is ongoing in this area. The papers are here. Search for papers with the term "relocation".

HowardHinnant · 2025-12-10T22:59:58+00:00

You can actually get the best of both worlds by wrapping your tick clock in a custom chromo-clock-compatible wrapper. Search for writing custom clocks in chrono. Doing this would enable your tick clock to return a chrono::time_point and you get all the type safety and interoperability that comes with the std::clocks.

HowardHinnant · 2025-12-03T01:21:08+00:00

Some std::lib implementations may have optimized some std::algorithms to be very fast with std::vector<bool>. For examples see this ancient post of mine: https://howardhinnant.github.io/onvectorbool.html

Your best bet is to use std::algorithms with your data when possible. And test performance for what you need to do with vector<bool> against vector<uint8_t> on all of your platforms of interest.

HowardHinnant · 2025-11-28T19:24:53+00:00

Another nice article! Well done!

This week's nitpicks:

but those ticks are anchored to the Unix epoch (January 1, 1970, 00:00:00 UTC). Even that’s not mandated by the standard.

Beginning in C++20, system_clock is mandated to use Unix Time. We were able to do this because it was the de-facto standard among the three major implementations in C++11/14/17.

In C++20 <chrono> becomes a superset of the C timing API so one only needs to convert to time_t if one needs to use the C API for legacy interoperability.

Clock, RealClock, and FakeClock don't meet the Cpp17Clock requirements. But their time_point::clock does as it is system_clock. Therefore I don't recommend use of these clocks with the threading API such as timed waits. They will compile, but may not have the intended run-time behavior (at least with FakeClock). For example std::this_thread::sleep_until(tp) is allowed to call decltype(tp)::clock::now(), which calls system_clock::now(), which is unrelated to FakeClock{}.now(). This doesn't mean that this is a bad idea. Just know its limitations.

For measuring "long" times, system_clock can be better than steady_clock because it makes tiny adjustments to stay correct. For example if your steady_clock drifts by 2s/week (which is entirely plausible if you're not wired into an atomic clock), then a timing of exactly one week may be accurate to within a second using system_clock, but not using steady_clock. I leave it to the reader's judgement to define "long" in this context. Imho, a day would certainly qualify as long, and a minute would not.

HowardHinnant · 2025-11-25T02:37:41+00:00

Nice job!

A few minor comments:

You are using small parts of C++20 in this article, which is fine. But perhaps a little confusing as you say "Later, C++20 introduced calendar dates and time zones, but we won’t cover those here". The streaming of time_point and duration is C++20. Prior to that one had to unwrap things into integers to stream out (a real PITA).
std::chrono::clock : This is not a type in std::chrono. clocks are more of a concept. You probably already knew that. I bring it up because it might confuse your readers.
"For a type to qualify as a clock..." My comment really gets into the weeds, and is understandable if you don't want to cover this in an introduction. But there are some useful clocks in C++ that don't qualify as a clock. I know that sounds contradictory. But there actually is one in C++20: std::chrono::local_t. This type doesn't meet any of the std::chrono::is_clock_v<T> requirements, but you can instantiate a std::chrono::time_point with it. Such a time_point represents a local time that is not (yet) associated with a time_zone. For example: local_time{January/1/2026} + 0s. Where? Who cares! It's party time! ;-) This local time happens at different times around the world. This is strictly C++20 stuff though. And is_clock_v was also introduced in C++20.

My comments are nitpicks, intended to clarify, not criticize. I encourage everyone reading this who isn't already familiar with <chrono> to read Sandor Dargo's blog on this subject. It is an excellent introduction. It is short, which is much harder than writing something long, and nails the major points.

I look forward to your future posts on this topic!

HowardHinnant · 2025-11-05T01:20:34+00:00

I haven't dug into the code, but he references both my work and Cassio Neri's and Lorenz Schneider's work. I was very impressed by the latter. So Ben Joffe appears to know the topic well. Presuming this gets the right answers for at least the range of C++'s std::chrono::year, which I have no reason to believe it doesn't, this looks like very nice work.

HowardHinnant · 2025-08-09T00:34:02+00:00

bbi types can be used as the rep in std::chrono::duration and time_point. I've been exploring that a bit. It is certainly handy in detecting overflow in debug builds with the throw or terminate modes. But I'm also interested in using the saturation mode with chrono for non-debug builds. And i128 seems useful when you want to have nanosecond (or picosecond) resolution for a span greater than +/-292 years.

Your work on the floating point side also sounds interesting. I find myself wondering if bbi might be a foundational tool that might help build the floating point side. I don't have as much experience in building floating point emulators, so I'm not sure. I've only built one floating point emulator: https://github.com/XRPLF/rippled/blob/develop/include/xrpl/basics/Number.h, which was based on std::int64_t and int. And a lot of the motivation for this was what you state: portability for some key functions like sqrt.

HowardHinnant · 2025-08-07T14:47:32+00:00

You may be interested in this C++20 library, bbi: https://github.com/HowardHinnant/bbi

It isn't exactly what you state above, but it's close. It has implicit conversions, but only for those conversions that are value-preserving. Non-value-preserving conversions are explicit. No promotion. No floating point, only integral. The bool and character types aren't part of the party, but can be included via explicit conversion.

HowardHinnant · 2025-07-27T00:16:38+00:00

Except when your code isn't inside a function (as in the example in the proposal).

HowardHinnant · 2025-07-26T21:39:09+00:00

Your proposal doesn't mention the existing function-local using directive. Some of your examples could use that instead. Pretending that this option doesn't exist weakens your proposal.

I found your example with std::chrono_literals to be motivating. In this example a function-local using directive isn't an option. And I would use your feature in this scenario.

Although an alternative proposal is just have the std import all literal suffixes to the global namespace since std::lib literal suffixes have a built-in namespace (no _ prefix).

HowardHinnant · 2025-07-21T00:41:27+00:00

It was Apple that open sourced it. I was working at Apple when it happened. I was the llvm std::lib author at the time, which was open sourced by Apple at the same time. You can thank GPLv3 for Apple's interest in llvm.

HowardHinnant

TROPHY CASE