[wgml.pl]

The other missing pointer type -- `object_ptr`

Mon, 23 Sep 2019 00:00:00 +0000

There are three smart pointers in std already: unique_ptr, shared_ptr and weak_ptr. A couple of years ago article was published, presenting value_ptr ¹, aka. the missing smart pointer. Here I would like discuss the other (sort of still) missing (not so) smart pointer – observer_ptr.

What is observer_ptr<T>?
A new hope
When to use it
Limitations
valid_ptr<T>
Postlude

What is `observer_ptr<T>`?

observer_ptr is a recent addition to c++ ecosystem – it was appended into Library Fundamentals TS in its second version. It means that if you would like to use it in your code, you are bound to the std::experimental namespace for some time, until, or if, it is going to be merged into the standard.

The purpose of observer_ptr is to provide:

a near drop-in replacement for raw pointer types, with the advantage that, as a vocabulary type, it indicates its intended use without need for detailed analysis by code readers. ²

Here is the thing – I think it is not really a drop-in replacement for raw pointers; and its vocabulary type is confusing and does not indicate its intend clearly. But we will get back to that.

The idea behind observer_ptr is to provide an interface that indicates the pointer that is being passed is considered read-only (pointer, not the object itself) and there will be no intention of extending the underlying object lifetime or stealing its ownership. If you use std::shared_ptr<Something> const& in the function parameter list, you can use observer_ptr<Something> instead.

Why not simply use Something* then? You could but you probably shouldn’t. Raw pointers inject many quirks into the code – can be incremented and decremented, compared using <, converted into void*, casted. Additionally, those open up new questions, most importantly: “who owns the object?”.

When using observer_ptr, you are safe from the quirks. You get type safety, no silly ptr++ and (void*) ptr. Unless you do ptr.get(), you should be good.

However, observer_ptr have some quirks on its own. Let’s try using it to show them all in context.

#include <experimental/memory>
#include <iostream>
#include <memory>

struct Resource
{
  int value = 42;
};

std::unique_ptr<Resource> create_resource()
{
  return std::make_unique<Resource>();
}

void use_resource(std::unique_ptr<Resource> const& resource)
{
  std::cout << "value=" << resource->value << std::endl;
}

void observe_resource(std::experimental::observer_ptr<Resource> resource)
{
  std::cout << "value=" << resource->value << std::endl;
}

int main()
{
  auto res = create_resource();
  use_resource(res);
  observe_resource(std::experimental::make_observer(res.get()));
}

When I first learned about observer_ptr and tried to use it, I ended up writing similar code and started thinking: but… why would you do that…?.

I really don’t like std::experimental::make_observer(resource.get()) to create the wrapper for the pointer. It should be as easy as make_observer(resource), at worst. At best it should have implicit conversions from all smart pointers (I would consider a smart pointer as some type that provides operator->, operator*, and possibly get().) and raw pointer of given type. It shouldn’t have release() member method, which, in smart pointer context, is related to releasing the ownership of the object. observer_ptr does not own anything.

On top of that, it requires a better name. observer implies relation to the Observer pattern, while, in fact, has nothing to do with it. I’m somewhere between ptr_view<T> (Just like the string_view.) and ptr<T> (It’s just a pointer, man.) myself. But there are more ideas. A lot more.

Different people have different concerns regarding the design of the type. For example, there is that one paper named Abandon observer_ptr.

A new hope

All in all, we can do better than that. Actually, we already do. There are 3rd-party implementations available, like this one from Anthony Williams:

named it object_ptr instead of observer_ptr
dropped the release() member method
made it construct implicitly from other pointer types

I like those changes in design; and it is just one header file so you can copy it into your code base and start using it now. However, even though object_ptr is a better name already, I still prefer to do:

#include <object_ptr.hpp>

namespace project::primary::ns {
template<typename T>
using ptr_view = jss::object_ptr<T>;
}

I’ll stick to the ptr_view for the rest of the post for clarity sake. With that, our example can become as simple as:

void use_resource(ptr_view<Resource> resource)
{
  std::cout << "value=" << resource->value << std::endl;
}

int main()
{
  auto shared_res = std::make_shared<Resource>();

  use_resource(shared_res);
}

Constructs implicitly from the smart pointer, can be passed by value – just like the string_view. You can play with the example here.

I just complained about using get() so let us dive into some use cases.

When to use it

ptr_view enables developers to build more readable and generic interfaces, no longer bound to specific pointer type. Most of the time, it does not matter whether the std::shared_ptr<T> or T*, or boost::shared_ptr<T>, or my::better_ptr<T> is being provided by the caller. If all you require is access to the underlying object, dependency on the specific type can be removed. Not only the function is going to end up being more generic but also a lot more readable.

For something(std::shared_ptr<T> const&, ...) –> something(ptr_view<T>, ...) gets rid of the question who owns the object now?.

For something_else(T* const, T* const, ...) –> something_else(ptr_view<T>, ptr_view<T>, ...) you need not to worry if it is range or two objects.

Same applies for std::unique_ptr with custom deleter defined. By default, it is defined as std::default_delete<T> and can be left out of type declarations. However, sometimes it might be necessary to provide dedicated deleter, e.g. for resources that does not follow RAII technique. However, ptr_view does not care about how the object have to be disposed on destruction, thus the deleter info is redundant, simplifying the code even more. Let’s consider following snippet:

struct LoggingDeleter
{
  template<typename T>
  void operator()(T* p) const
  {
    std::clog << "freeing p=" << p << std::endl;
    delete p;
  }
};

void use_resource(std::unique_ptr<Resource> const& resource)
{
  std::cout << "value=" << resource->value << std::endl;
}

void use_resource(std::unique_ptr<Resource, LoggingDeleter> const& resource)
{
  std::cout << "value=" << resource->value << std::endl;
}

int main()
{
  auto res = std::make_unique<Resource>();
  std::unique_ptr<Resource, LoggingDeleter> debug_resource{new Resource{}, LoggingDeleter{}};

  use_resource(res);
  use_resource(debug_resource);
}

As already mentioned, ptr_view does not care about object destruction, so void use_resource(ptr_view<Resource>) can handle all invocations, like so.

ptr_view behaves also a bit like std::weak_ptr’s dumber friend - but in a good way. Often you can be bound to use std::weak_ptr<T> as a mitigation for possible ownership cycles. However, assuming one of the objects is guaranteed to outlive the other one, it would be sufficient to store non-owning pointer to the longer-living one, like T*. Or, you guessed it, ptr_view<T>.

struct Task;
struct Executor
{
  void work_until_done();
  void notify_done(ptr_view<Task>);
  void queue(std::shared_ptr<Task>);

private:
  std::vector<std::shared_ptr<Task>> _tasks;
};

struct Task
{
  explicit Task(ptr_view<Executor> e) : _executor(e) {}

  void notify_done()
  {
    _executor->notify_done(this);
  }

private:
  ptr_view<Executor> _executor;
};

int main()
{
  auto executor = std::make_unique<Executor>();
  for (std::size_t i = 0; i < 5; ++i)
    executor->queue(std::make_shared<Task>(executor));
  executor->work_until_done();
}

There is no point in using std::weak_ptr if you are guaranteed the Executor will outlive all the Task objects – and it is quite possible it will be the case in most of the implementations.

Of course, we can get back to the discussion that we can just use Executor* but it will be as less-safe, less-readable and less-explicit compared to vocabulary type like ptr_view.

Limitations

For ptr_view to be used in as much contexts as possible, the usage itself should be frictionless. Unfortunately, it is not the case yet.

Let us consider some check_resource function that takes pointer to arbitrary resource and verifies if the resource is accessible (!= nullptr, for simplicity).

struct Filesystem
{...};

struct Network
{...};

template<typename Res>
bool check_resource(ptr_view<Res> resource)
{
  return resource != nullptr;
}

int main()
{
  auto fs = std::make_shared<Filesystem>();
  auto net = std::make_unique<Network>();

  check_resource(fs);
  check_resource(net);
}

Compilation attempt results in following error, plainly stating object_ptr cannot be matched against some arbitrary smart pointers.

Output

prog.cc:24:3: error: no matching function for call to 'check_resource'
  check_resource(fs);
  ^~~~~~~~~~~~~~
prog.cc:14:6: note: candidate template ignored: could not match 'object_ptr' against 'shared_ptr'
bool check_resource(ptr_view<Res> resource)
     ^
prog.cc:25:3: error: no matching function for call to 'check_resource'
  check_resource(net);
  ^~~~~~~~~~~~~~
prog.cc:14:6: note: candidate template ignored: could not match 'object_ptr' against 'unique_ptr'
bool check_resource(ptr_view<Res> resource)
     ^
2 errors generated."

CTAD³ and user-defined deduction guides could help there but, well, those are for classes only. There was a paper to allow deduction guides for functions – I don’t know what feedback it received though.

For now, we can avoid such issues with either specifying underlying element_type:

check_resource<Network>(net);

or with intermediate function step, accepting anything and forwarding only those types that are convertible to ptr_view:

template<typename ResPtr>
bool check_resource(ResPtr const& resource)
{
  return impl::check_resource<typename std::pointer_traits<ResPtr>::element_type>(resource);
}

While not perfect, both implementations manage to do the job and result in sort-of-readable compiler errors when misused. Check out the full example there.

`valid_ptr<T>`

One possible extension of the non-owning pointer could be a valid_ptr, that is pointing to some existing object, and never to the nullptr. It is quite simple to implement on top of the jss::object_ptr class, all that is required to add is some initial checks in the constructors.

...
explicit valid_ptr(T* ptr) : _ptr(ptr)
{
  assert_valid();
}
...

That immediately leads to a discussion what should be done in case ptr == nullptr. assert_valid() can throw exception on invalid pointer or truly assert that condition and terminate on fail. That would be a question for a long and, probably, unsettlementable discussion.

However, such design might lead to assumptions that the pointer is always valid, while, in fact, it is just as dumb as ptr_view. It is impossible to guarantee validity without the ownership. And it is the caller role to do so.

With that in mind, valid_ptr becomes more of a implicit null-check of the argument provided. Maybe it is worth it but there might a better ideas how to solve the parameter nullability problem.

Postlude

As of today, I’m sort of in the Almost Always ptr_view team. It’s just more fit for the use case than shared_ptr<T> const& and T*.

I hope we get it merged into the standard someday; however, if I am to use it in most contexts, it really should get a better (pronounced – shorter) name – I feel like 6-8 characters is the most I can invest to use it myself. Any more and the code readability will suffer. CTAD for functions would be fun, too.

I’m sticking to 3rd-party implementation, for now.

Formatting user-defined types with {fmt} library

Fri, 01 Mar 2019 00:00:00 +0000

C++ has two standardized ways of printing formatted text out already: printf-family functions inherited from C and I/O streams abstraction built on operator<<. Streams are considered more modern, providing type-safety and extensibility functionalities. However, printf have some notable advantages, too — at the cost of lost type-safety, user can use an interface that looks familiar to almost all developers, allowing for some ways of localization and more readable syntax. And then, there is {fmt} — yet another text formatting library, inspired by design already available in languages like Python and Rust.

Perhaps it’s just yet another standard to compete but, with an ambition to support most of the advantages of both mentioned methods, and with process of standardization being already in progress, it is worth looking into.

Quick look at {fmt}
Printing out a custom type
Specifying formatting for user-defined types
Postlude

Quick look at `{fmt}`

{fmt} library is available on Github for quite some time already. It provides API similar to str.format() from Python 3, far closer to printf(...) than std::cout << ... at the first glance. However, it also enforces type-safety and allows for extending to non-standard types, what makes it almost a silver bullet for text formatting in C++.

Based on the mandatory Hello world example, use of the library may look like so:

fmt::print("Hello, {}!\n", name);

{fmt} supports positional arguments, allowing user to manipulate the order in which arguments are used in the message:

std::string message = fmt::format("{1} years ago, {0} was born.", name, age);

Formatting is also possible (well, that is the point, after all). If you want to print a number to the screen and align it to the right with the width of 7 characters, that is the syntax:

fmt::print("The number is {:>7}!\n", number);

Of course, this can become far more perl-y in style. This is a valid format:

fmt::print("The number is {0:.>+#{1}.{2}G}\n", 42.123, 20, 10);

Translating it to human — the zeroth argument (0:) will be aligned to the right (>), with dots filling empty space (.), the sign will be printed out (+) no matter plus or minus, the number will be put in general format (G) unless it is too large, then it will be displayed using exponent notation. Trailing zeros will not be removed because of the alternate form (#). Width and precision are configured by first ({1}) and second ({2}) argument. Fortunately, you can look up the syntax in the official docs.

And the result?

Output

The number is ........+42.12300000

All in all, I suggest not to overcomplicate the syntax on your end unless you want your code to become write-only.

Printing out a custom type

One neat feature of {fmt} is the possibility to extend it for user-defined types, similarly to the convention used when overloading operator<< for such types.

For example, given the simple complex type, instead of defining the formatting in every place where the objects are printed out, one can specify formatter for the type and use it without any hassle.

#include <fmt/format.h>

struct complex
{
  double a;
  double b;
};

template<>
struct fmt::formatter<complex>
{
  template<typename ParseContext>
  constexpr auto parse(ParseContext& ctx);

  template<typename FormatContext>
  auto format(complex const& number, FormatContext& ctx);
};
};

int main()
{
  complex number{1, 2};
  fmt::print("The number is {0}+i{1}.\n", number.a, number.b);
  fmt::print("The number is {}.\n", number);
}

User must specialize the formatter<T> struct template in fmt namespace with implementations of parse and format functions. Provided the user wants to match the result of both lines, those two methods can be implemented as follows:

template<typename ParseContext>
constexpr auto fmt::formatter<complex>::parse(ParseContext& ctx)
{
  return ctx.begin();
}

template<typename FormatContext>
auto fmt::formatter<complex>::format(complex const& number, FormatContext& ctx)
{
  return fmt::format_to(ctx.out(), "{0}+i{1}", number.a, number.b);
}

parse assumes no formatting is specified for the type, and format outputs the variable in hard-coded formatting. In case of an error, exception will be thrown, with mostly unhelpful message, like “unknown format specifier”.

Specifying formatting for user-defined types

What if we want to allow the user to specify formatting for printed-out fields?

Let’s look into another example. First of all, let me introduce the type.

struct roman
{
  explicit roman(unsigned v) : value(v)
  {
    if (value == 0)
      throw std::runtime_error("0 cannot be represented");
    if (value > 3999)
      throw std::runtime_error("Roman value cannot exceed 3999");
  }

  unsigned const value;
};

It’s just a simple wrapper claiming to represent some Roman numeral. But how does it fit our use case?

We might assume user would like to print out such numerals both in decimal form and in string-like representation commonly associated with Roman numeric system. Then, we would like to be able to execute following program without errors:

int main()
{
  for (unsigned i = 1; i < 4000; ++i)
    fmt::print("{0:d} = {0:r}\n", roman{i});
}

Moreover, it would be useful to allow specifying underlying formatting for string and decimal representations — then, our testing program can take form as follows.

int main()
{
  for (unsigned i = 1; i < 4000; ++i)
    fmt::print("{0:d>4} = {0:r.>16}\n", roman{i});
}

The first character after the : defines representation that should be used and all that follows should be interpreted as underlying formatting. We will also assume {0} defaults to Roman representation but without the possibility to specify the underlying formatting to make the code simpler.

As previously, we have to specify specialization of fmt::formatter class and implement two methods. This time, we will delegate parse and format calls to formatters of std::string_view or unsigned, depending on the formatting specified. The formatters will be members of the structure, and, because it is either one of them but never both nor none that is being used, we will utilize std::variant for this. Interface of the formatter can be now specified.

template<>
struct fmt::formatter<roman>
{
  using unsigned_fmt = fmt::formatter<unsigned>;
  using string_view_fmt = fmt::formatter<std::string_view>;
  using underlying_formatter_type = std::variant<string_view_fmt, unsigned_fmt>;

  template<typename ParseContext>
  constexpr auto parse(ParseContext& ctx);

  template<typename FormatContext>
  auto format(roman const& number, FormatContext& ctx);

private:
  underlying_formatter_type underlying_formatter;
};

Let’s look more closely at the parse implementation first. All it needs to do is to determine which formatter should be used and forward the call to parse.

template<typename ParseContext>
constexpr auto parse(ParseContext& ctx)
{
  auto fmt_end = std::find(ctx.begin(), ctx.end(), '}');
  if (fmt_end != ctx.begin())
  {
    char representation = *ctx.begin();
    if (representation == 'd')
      underlying_formatter = unsigned_fmt{};
    else if (representation != 'r')
      throw fmt::format_error("invalid roman representation");

    ctx.advance_to(std::next(ctx.begin()));
  }

  return std::visit([&](auto& fmt) { return fmt.parse(ctx); }, underlying_formatter);
}

Let’s analyze the behavior with an example. Given we want to print a Roman number with fmt::print("{0:r>16} is the number {0:d}", roman_number), two formatter<roman> instances will be created and parse function will be called twice. First time, the input to the function will be a context with begin pointing to the string of r>16} is the number {0:d}. The second time — d}. Part specifying the position is being consumed by the fmt library itself. Then, user must parse the rest of the string and make sure the context is left in a valid state for any other formatters to use. In this example, in both cases we must make sure context is advanced to the } character.

However, all the function is doing is to determine if user asked for roman or numeric representation and call ctx.advance_to pointing to the second character. We will consume only the first char, leaving the rest intact. Finally, we forward the context to parse of the underlying formatter, taking care of the rest of format string.

std::variant constructs with the first type specified by default so all the parse is required to do is to overwrite the value in case decimal representation is specified or throw an exception when erroneous formatting is found.

Next, format.

template<typename FormatContext>
auto format(roman const& number, FormatContext& ctx)
{
  return std::visit(formatting_visitor<FormatContext>{number, ctx}, underlying_formatter);
}

We just forward the call to visitor:

namespace romans {
struct numeral
{
  char repr[3];
  unsigned value;
};

constexpr std::array<numeral, 13> numerals = {{
    {"M", 1000}, {"CM", 900}, {"D", 500}, {"CD", 400},
    {"C", 100}, {"XC", 90}, {"L", 50}, {"XL", 40},
    {"X", 10}, {"IX", 9}, {"V", 5}, {"IV", 4}, {"I", 1}
  }};
}  // namespace romans

template<typename FormatContext>
struct formatting_visitor
{
  formatting_visitor(roman const& number, FormatContext& ctx) : number(number), ctx(ctx)
  {}

  void operator()(string_view_fmt& f) const
  {
    unsigned value = number.value;
    std::string buffer;

    buffer.reserve(16);  // romans are no longer that 15 chars
    for (auto const& [repr, v] : romans::numerals)
    {
      while (value >= v)
      {
        buffer.append(repr);
        value -= v;
      }
    }

    ctx.advance_to(f.format(buffer, ctx));
  }

  void operator()(unsigned_fmt& f) const
  {
    ctx.advance_to(f.format(number.value, ctx));
  }

private:
  roman const& number;
  FormatContext& ctx;
};

In both possible cases, the function calls underlying format with value to be printed out and context as arguments. Then, the output iterator must be adjusted, so advance_to is called with the result. Similarly, our format returns ctx.out(). In case of decimal representation, we can simply extract the value from number; for Roman representation, we execute conversion algorithm and that’s why we even need the struct instead of simpler lambda.

Finally, we can check the results.

   1 = ...............I
   2 = ..............II
...
3998 = .....MMMCMXCVIII
3999 = .......MMMCMXCIX

It seems everything worked as expected. If you are interested in the full source code of the example, you can find it and play with it on the Wandbox.

Postlude

{fmt} is a neat library, easy to use from user perspective, and providing syntax that is new for C++ but already established in other programming languages. Perhaps it is a bit more demanding when formatting for custom type is to be specified but it should be a rare case to build complex formatting outside of the standard library.

It has a lot more to offer than was described in this post. It claims to be faster than alternatives both in compile and run times, without bloating application code, too.

It also supports formatting time and date, std::chrono types (it is already proposed for merge into the standard), and more. Check out the official documentation for details. Even though not everything is going to be merged into the standard, I’m still happy to see std::format in the next edition of C++, probably even in c++20.

Getting started with VPS

Fri, 15 Feb 2019 00:00:00 +0000

Recently, I decided to organize how I host and manage this website. Until now, I was using tangled net of services hidden behind the idea of simplicity. I used Github Pages for hosting but wanted to keep my own domain. Easily done, unless you want to also have HTTPS – I had to use Cloudflare for DNS and tunneling traffic via theirs server for SSL. My domain provider didn’t support managing mail communication with custom DNS addresses, so I configured mailgun to do it instead. On top of that, I maintained development box with its own subdomain but without tunneling the traffic via Cloudflare. It was a mess. The time has come to sort things out.

Basics
Blog
Deploying content changes automatically
Let’s Encrypt
Summary

Basics

I am using Jekyll to generate static website from Markdown and HTML snippets. It is really great. Those are still being hosted by Github repository but I no longer care for Github Pages – it’s only reason for existence is to redirect to mine domain. And one more thing but let’s not get ahead of ourselves.

I host the content on Vultr $5/mo VPS. 1 GB of RAM + 25 GB of SSD storage is more than enough to support such endeavour and allow me to play with side projects on the same machine. Theirs $2.5/mo would be probably sufficient, too. Decided to use Ubuntu just for the library of guides already available on Vultr and DigitalOcean for that distribution.

Blog

I installed nginx, configured it, normal stuff. The configuration was dead-simple.

server {
    root /var/www/wgml.pl/html;
    index index.html;
    error_page 404 /404.html;

    server_name wgml.pl www.wgml.pl;

    location / {
        try_files $uri $uri/ =404;
    }

    listen 80;
    listen [::]:80;
}

I also installed a few necessary packages, like git, vim, jekyll. Built blog with jekyll build --destination /var/www/wgml.pl and, voilà, I could see my website under http://wgml.pl.

Yeah, at least two issues with that setup:

I do not want to manually deploy the site every time I commit to repository
Where is that HTTPS lock icon?

Fortunately, we will solve both of them in a minute.

Deploying content changes automatically

I googled a bit for ideas on how to automate website deployment. It seems there are at least two interesting solutions. Jekyll docs describe how to use bare git repository and post-receive hooks to regenerate website on every push. You can also use Github webhooks to notify something like jekyll-hook about changes. Both solutions work fine, I went with the second one because who would like to write two git push commands every time when one is sufficient?

Within a couple of minutes I prepared a bit overly complicated shell script to handle deployments.

#/bin/bash

set -e

REPO_URL="https://github.com/wgml/wgml.github.io.git"
SITE_DIR="/var/www/wgml.pl"
SITE_PUBLIC_DIR="$SITE_DIR/html"

cd $(mktemp -d)
git clone $REPO_URL --depth=1 --branch=master --single-branch .

HEAD=$(git rev-parse HEAD)
SITE_REV_DIR="$SITE_DIR/html-$HEAD"

if [ -d "$SITE_REV_DIR" ];
then
  ln -sfn "$SITE_REV_DIR" "$SITE_PUBLIC_DIR"
  exit 0
else
  mkdir "$SITE_REV_DIR"
fi

jekyll build --destination "$SITE_REV_DIR" && ln -sfn "$SITE_REV_DIR" "$SITE_PUBLIC_DIR" || rm -rf "$SITE_REV_DIR"

I modified nginx configuration to expose /update endpoint and forward all requests to the hook listener.

server {
    ...
    location / {
        try_files $uri $uri/ =404;
    }

    location /update {
        rewrite ^/update(.*) /$1 break;
        proxy_pass http://127.0.0.1:12345;
    }

    listen 80;
    listen [::]:80;
}

Now, when I do git push on my local machine, changes will appear on website in a matter of seconds. Finally, I have dynamic-static website.

Let’s Encrypt

Let’s encrypt is a go-to service for everyone in need of free TLS certificates and I highly recommend it. For configuration, I mostly followed DO How To Secure Nginx with Let’s Encrypt guide.

To sum up, install LE Certbot, configure firewall, obtain your SSL certificate with something similar to:

sudo certbot --nginx -d wgml.pl -d www.wgml.pl

certbot will attempt to renew any near-expiring certificates but make sure it will work by running

sudo certbot renew --dry-run

Make sure you entered your email address while requesting certificate as Let’s Encrypt will mail you if renewal fails. certbot modified nginx configuration on itself, https://wgml.pl was available when I restarted nginx. Yay!

Summary

I managed to migrate from Github Pages into personal VPS in a matter of couple of hours. I didn’t lose ability to dynamically regenerate content on changes and SSL support. And, in addition to DIY factor, hosting your own website means you no longer need to care about limitations of Github Pages.

[wgml.pl]

The other missing pointer type -- `object_ptr`

What is observer_ptr<T>?

A new hope

When to use it

Limitations

valid_ptr<T>

Postlude

Formatting user-defined types with {fmt} library

Quick look at {fmt}

Printing out a custom type

Specifying formatting for user-defined types

Postlude

Getting started with VPS

Basics

Blog

Deploying content changes automatically

Let’s Encrypt

Summary

What is `observer_ptr<T>`?

`valid_ptr<T>`

Quick look at `{fmt}`