You can wrap a std::array into a std:unique_ptr, hardly much to write besides a couple of type alias.

I'm sorry to say, TERRIBLE advice!

As many (or most) of C++ features, std::array is a logical idea with terrible ergonomics, bordering to unusable. While they are potentially a little safer to use than plain C arrays (but compilers could easily add runtime checking for plain C arrays too), they are much less ergonomic, both in verbosity of declaration and errors.

They can't replace an init-allocated std::vector either, because they have a size fixed at compile time.

And unique_ptr itself is TERRIBLE to use too. If RAII is your thing, then still very often, it's totally worth the boilerplate to wrap individual objects in type-specific explicit "Holder classes", instead of relying on std::unique_ptr which has terrible ergonomics too, again both for declaration and use.

Oh, and if you're using a free-standing destructor function for the managed object (which is often a very good idea because exposing the class definition in typical C++ style leads to TERRIBLE TERRIBLE compile times), you'll have to bake in a function pointer that is carried by unique_ptr at runtime (I suspect that is because they couldn't make the function a templated parameter because in C++, this leads to ambiguitiy if it is a static inline function declared in a header (terrible!)). So you're paying for all the all the drawbacks of the templated type and get none of the benefits (except for saving a few lines of boilerplate).

TERRIBLE.

And now you propose combining these two terrible things? How would you use this?

    #include <memory>
    #include <array>

    struct Foo
    {
        ~Foo()
        {
            printf("Bye!\n");
        }
    };

    int main()
    {
        // std::unique_ptr<std::array<Foo, 42>> foo = std::make_unique<std::array<Foo, 42>>();  // my fingers hurt and my eyes bleed
        auto foo = std::make_unique<std::array<Foo, 42>>();  // fingers hurt a little less but my brain will melt on next compiler error
        foo->at(0);  // valid
        foo[0];  // error. TERRIBLE!
        return 0;
    }

I wouldn't be so upset about your advice if I didn't know you often don't validate your claims and "references", but keep on suggesting and criticising existing practice that has evolved to certain points (and keeps evolving!) for a reason.

I validate my claims in production code, running in places like CERN and Nokia Networking infrastrure, and not being part of anti-C++ brigade, rather the nuke C one, since 1993.

Nope, I don't buy that this is a tried and tested pattern in your code.

> running in places like CERN and Nokia Networking infrastrure

Is there no bad code in these places? And, as an avid follower of your posts, how long ago has this been? 15 years? And now you're selling people ideas on HN instead?

Whatever, believe whatever makes you feel happy.

You couldn't even be bothered to actually use type alias to make the example simpler, or take into consideration build configurations, only to make the typical C rant.

Type alias doesn't save me from typing that stuff at least once, plus I have to come up with a name which adds indirection (and a dependency that I have to manage!) that I have to recompute in my head everytime I read it. It's also (mostly?) transparent to compiler which will still spew me with the same unreadable errors and types as before.

The C++ modules that you've been advocating for years as a workaround for slow compile times still haven't arrived in my (and most everybody else's) practice, sorry.

I do use precompiled headers in some settings to work around slowness, which does help a lot for build performance but is again terrible (breaks modularity, it's basically a choice: #include everything vs have slow build, with little possibility for making a tradeoff).