{"id":112703,"date":"2026-09-16T07:00:00","date_gmt":"2026-09-16T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=112703"},"modified":"2026-09-17T07:21:41","modified_gmt":"2026-09-17T14:21:41","slug":"20260916-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20260916-00\/?p=112703","title":{"rendered":"Magic statics vs. std::call_once<\/CODE>"},"content":{"rendered":"

Suppose you have some function like<\/p>\n

bool should_use_widgets()\r\n{\r\n    bool supported = \u27e6 complex code to check OS features \u27e7;\r\n    return supported && is_configuration_enabled(\"widgets\");\r\n}\r\n<\/pre>\n
Since OS Widget support is not something that changes during the lifetime of the program, you want to calculate it once and cache the result.<\/p>\n
One way is to use a so-called “magic static”:<\/p>\n
bool should_use_widgets()\r\n{\r\n    static const bool supported = [] {\r\n        return \u27e6 complex code to check OS features \u27e7;\r\n    }();\r\n    return supported && is_configuration_enabled(\"widgets\");\r\n}\r\n<\/pre>\n
Function-local statics are initialized the first time execution reaches the variable. On subsequent executions, nothing happens.<\/p>\n
Another way is to use std::call_once<\/code>.<\/p>\n
bool is_supported_cached;\r\nstd::once_flag is_supported_once;\r\n\r\nbool are_widgets_supported()\r\n{\r\n    std::call_once(is_supported_once, [] {\r\n        is_supported_cached = \u27e6 complex code to check OS features \u27e7;\r\n    });\r\n    return is_supported_cached && is_configuration_enabled(\"widgets\");\r\n}\r\n<\/pre>\n
Why would you choose one over the other?<\/p>\n
Magic statics are certainly more convenient. You don’t have to juggle two variables. You just declare a function-local static<\/code> and initialize it. One problem is that they have to be a function-local static. Multiple functions can’t access that same cached variable. But that’s easy to work around: Have a function whose sole job is to manage that one static.<\/p>\n
bool are_widgets_supported_in_os()\r\n{\r\n    static const bool supported = [] {\r\n        return \u27e6 complex code to check OS features \u27e7;\r\n    }();\r\n    return supported;\r\n}\r\n\r\nbool are_widgets_supported()\r\n{\r\n    return are_widgets_supported_in_os() &&\r\n        is_configuration_enabled(\"widgets\");\r\n}\r\n\r\nbool are_widget_carriers_supported()\r\n{\r\n    return are_widgets_supported_in_os() &&\r\n        is_configuration_enabled(\"widget_carriers\");\r\n}\r\n<\/pre>\n
This trick is often used for singleton patterns.<\/p>\n
class Singleton\r\n{\r\npublic:\r\n    static Singleton& GetInstance()\r\n    {\r\n        static Singleton instance;\r\n        return instance;\r\n    }\r\n\r\n    \u27e6 various methods go here \u27e7;\r\n\r\nprivate:\r\n    Singleton() = default;\r\n    Singleton(Singleton const&) = delete;\r\n    Singleton& operator=(Singleton const&) = delete;\r\n    ~Singleton() = default;\r\n}\r\n<\/pre>\n
So when would you use call_once<\/code>?<\/p>\n
Magic statics work only for statics. Maybe you want to lazy-initialize a non-static data member.<\/p>\n
Suppose we have a Gadget<\/code> that is constructed with an associated Widget<\/code>. And suppose that the Gadget<\/code> support for polarity reversal is dependent on whether the Widget<\/code> supports polarity reversal. Furthermore, polarity reversibility is expensive to calculate, but since it is an immutable property, we can calculate it only once and cache the result.<\/p>\n
class Gadget\r\n{\r\npublic:\r\n    Gadget(std::shared_ptr<Widget> const& widget) : widget(widget) {}\r\n\r\n    bool can_reverse_polarity()\r\n    {\r\n        return can_reverse_polarity_cached;\r\n    }\r\n\r\nprivate:\r\n    std::shared_ptr<Widget> const widget;\r\n    bool can_reverse_polarity_cached =\r\n        is_configuration_enabled(\"polarity_reversal\") &&\r\n        is_widget_polarity_reversible(*widget);\r\n};\r\n<\/pre>\n
The can_reverse_polarity_cached<\/code> is a non-static data member with an explicit initializer, so it initializes at the construction of the Gadget<\/code> class, rather than initializing on demand the first time somebody calls can_reverse_polarity<\/code>.<\/p>\n
“No problem,” you say. “I can use a magic static.”<\/p>\n
    bool can_reverse_polarity()\r\n    {\r\n        static bool can_reverse_polarity_cached =           <\/span>\r\n            is_configuration_enabled(\"polarity_reversal\") &&<\/span>\r\n            is_widget_polarity_reversible(*widget);         <\/span>\r\n\r\n        return can_reverse_polarity_cached;\r\n    }\r\n<\/pre>\n
Function-static variables in a member function are static with respect to the member function. All instances of Gadget<\/code> share the same member function, and therefore they all share the same can_reverse_polarity_cached<\/code> variable. The time you call Gadget::can_reverse_polarity()<\/code>, it calculates the reversibility of the Widget<\/code> that is associated with the Gadget<\/code> you called it from, and that value is then locked in for all future calls to Gadget::can_reverse_polarity()<\/code>, even though the future calls may be on unrelated Gadget<\/code>s.<\/p>\n
What we want is a variant of magic statics that initialize for each instance<\/i> of the class, rather than once for all instances.<\/p>\n
That’s the case for std::call_once<\/code>.<\/p>\n
class Gadget\r\n{\r\npublic:\r\n    Gadget(std::shared_ptr<Widget> const& widget) : widget(widget) {}\r\n\r\n    bool can_reverse_polarity()\r\n    {\r\n        std::call_once(can_reverse_polarity_once, [] {          <\/span>\r\n            can_reverse_polarity_cached =                       <\/span>\r\n                is_configuration_enabled(\"polarity_reversal\") &&<\/span>\r\n                is_widget_polarity_reversible(*widget);         <\/span>\r\n        });                                                     <\/span>\r\n        return can_reverse_polarity_cached;\r\n    }\r\n\r\nprivate:\r\n    std::shared_ptr<Widget> const widget;\r\n    bool can_reverse_polarity_cached; \/\/ initializes on demand<\/span>\r\n    std::once_flag can_reverse_polarity_once;                 <\/span>\r\n};\r\n<\/pre>\n
I guess you could encapsulate this in a lazy<T><\/code> type.\u00b9<\/p>\n
template<typename T, typename L>\r\nstruct lazy\r\n{\r\n    lazy(L&& l) : init(std::forward<L>(l)) {}\r\n\r\n    T& get() {\r\n        std::call_once(once, [&] {\r\n            value.emplace(init());\r\n        });\r\n        return *value;\r\n    }\r\nprivate:\r\n    std::optional<T> value;\r\n    std::once_flag once;\r\n    std::decay_t<L> init;\r\n};\r\n\r\ntemplate<typename T, typename L>\r\nlazy<T, L> make_lazy(L&& l)\r\n{\r\n    return { std::forward<L>(l) };\r\n}\r\n\r\nvoid test()\r\n{\r\n    auto v = make_lazy<int>([] {\r\n        printf(\"Slow calculation\\n\");\r\n        return 42;\r\n    });\r\n\r\n    printf(\"Value is %d\\n\", v.get());\r\n    printf(\"Value is still %d\\n\", v.get());\r\n}\r\n<\/pre>\n
But wait, we also have std::async<\/code> with deferred execution. Should we use that? We’ll look at this question next time.<\/p>\n
\u00b9 Note that this is not the same as  the std::lazy<\/code> proposal<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"
They sort of do the same thing, but differently.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-112703","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
They sort of do the same thing, but differently.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/112703","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=112703"}],"version-history":[{"count":1,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/112703\/revisions"}],"predecessor-version":[{"id":112704,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/112703\/revisions\/112704"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=112703"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=112703"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=112703"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}