оті всякі маніпуляції типу 0/0, ∞-∞ і тд в контексті границь функції (а те про що йшлося вище якраз і є границями ф(+-1/х) при х->∞) дають невизначеність, і щоб її позбутись використовують правило Лопіталя

висновок ваш виглядає правильниним

стосовно синього рівняння, продовжу з моменту коли ми розклали жовте на

зелене - синє

тепер додамо до нашого ріняння таку конструкцію яка ніяким чином його не змінить

зелене - синє + оранжеве - оранжеве

погрупуємо їх

(зелене + оранжеве) - (синє + оранжеве)

і тепер відповідно перша група перетворилась на червоне, а друга - на сіре
можете це перевірити вручну розкривши квадрат сірого рівняння

Звичайно можете, тільки раз ви послуговуєтесь с++ ним бітсетом, то і не вмішуйте сюди сішний стандарт,
а с++11 стандарті масив ініціалізується constant-expression'ом

Я розумію, я хотів донести інше, що як з шаблонами так і з масивами - їх тип\розмір повинен бути відомим на етапі компіляції, тому просту змінну туди і не засунути

ви викликаєте неконстантний гетер у константному методі

вона прийде коли ви будете завалені домашкою

дивіться де вони посилаються на пункт 1.37

Якщо я впевнений в тому що в мому компіляторі цей метод реалізований, то нормально буде на перший час обійтись таким рішенням?

int threadsCount = std::thread::hardware_concurrency() || 1;

Я забув, що я не на форумі телепатів та не уточнив, що [start; end) формують напів-відкритий проміжок

for (i = start; i < end; i++){}

Тобто у випадку коли є 15 об'єктів - end=16

Але ваше зауваження наштовхнуло мене трохи  переобити алгоритм для більш збалансованого розподілу

float part =  (float)(end - start) / (float)threadsCount;
for (int i = 0; i < threadsCount; ++i)
{
    int startInd = part * i;
    int endInd = part * (i + 1);
    threads[i] = std::thread(threadFunc, startInd, endInd, std::ref(vertices));
}

i = 0 => 3
i = 1 => 4
i = 2 => 4
i = 3 => 4

у reference_wrapper реалізований оператор приведення до посилання operator T& ()
і використовувати його потрібно тому, що оскільки аргументи з якими створюється потік копіюються в новий стек, то передавши аргумент який має бути посиланням без std::ref в потоці ми отримаємо посилання на скопійований обк'єкт

По великому рахунку в кінцевому результаті різниці для користувача не буде, але насправді ж ви виконуєте лишнє копіювання об'єктів на які вказують вказівники data0 та data1.

В даному випадку це ускладнює тільки розуміння коду, але уявіть якби ці об'єкти були тяжкими, або їх було багато, тоді б це копіювання зайняло б чимало часу.

bool getData(int *data0, int *data1)
{
    int tmpdata0 = *data0;
    //*data0 - розіменовуєте вказівник, тобто ця операція поверне значення на яке він вказує
    // і воно скопіюється у змінну int tmpdata0

    readUInt(TSL2561_REG_DATA_0, &tmpdata0);
    //передаєте адресу копії у функцію readUInt, де вона присвоїться іншому вказівнику
    
   *data0 = tmpdata0;
   //повертаєтесь до початкового вказівника та замінюєте його попереднє значення
   //на значення цієї копії яка якось опрацювалась у функції readUInt

    return true;
}

Весь цей код скорочується до варіанту описаного у вашій першій функції: коли ви в readUInt передаєте безпосередньо вказівник, і тоді скопіюється лише вказівник, а не сам об'єкт.

bool getData(int *data0, int *data1)
{
    readUInt(TSL2561_REG_DATA_0, data0)
}