Many years ago I created an architecture for managing async tasks in C++ which is far more efficient than the typical tasks/task queue approach. My "work contract" approach involves no locking and can be trivially scaled to work with however many threads are assigned to process asynchronous work.

Paper describing work-contracts
git hub source code

People get thread pools wrong all the time. Every developer seems to believe that a 'thread pool' should involve 'tasks', task objects, task queues, etc. This is just wrong. It's a mistake to couple tasks, and containers for tasks with thread pools. Below is my take on what a thread pool ought to be.
I'll be adding more here to discuss thread pools in issolation from the usage of them but for now you can see my take on how simple thread pools should be and where/how they should be decoupled from tasks, and containers used to manage tasks.

git hub source code as part of my work-contracts library.

If you wanted to encapsulate a reference to a C++ const character array and provide the ability to access that value without it decaying to a char const * you would write something like the following. How's this for crazy-assed C++ syntax?!

template <std::size_t N>
class const_char_array_wrapper
{
public:
   
    const_char_array_wrapper
    (
        char const (&value)[N]
    ):
        value_(value)
    {
    }

    char const
    (
        & get_value() const
    )[N]
    {
        return value_;
    }

    // or, for implicit conversions

    (
        & operator char const () const
    )[N]
    {
        return value_;
    }

private:

  char const (&value_)[N];
};