Летопись багов (49 стр)

Aroch
я о компайл-таймовой проверке, о том что 115200 не влезает в int.

kipar
> я о компайл-таймовой проверке, о том что 115200 не влезает в int
это уже на совести компилятора что использовал alx, но даже у сишечки (у него вроде си а не плюсы) есть размерные типы и мог бы сразу воспользоваться int32_t.

Aroch
можно, но моего аргумента это не отменяет.

kipar
> можно, но моего аргумента это не отменяет.
как видим это не помогло. Но ок, пусть будет. В случае с константами для вычисляемых значений умный компилятор также способен дать предупреждение во время компиляции.

=A=L=X=
> А ларчик, кстати, просто открывался

А эти бодрейты в массиве для какой цели используются? Для вывода на экран/консоль (если в AT-команду идет не бодрейт, а лишь индекс)?. Или через них в коде высчитываются тайминги/делители для UART?

Dmitry_Milk
> А эти бодрейты в массиве для какой цели используются?

Даёшь блютуф-свистку команду AT+BAUD8, а когда он даст отклик OK переключаешься на скорость под индексом 8 для общения с ним дальше.
Т.е. примерно так (сейчас по памяти):

=A=L=X=
странно что по умолчанию предупреждение отключены. Типа предупреждение в первую очередь и нужны тем, кто только начал писать

Решил сделать тайплист покрасивее и убрал ::type, в результате компилятор отожрал 32Гб и попросил еще, пришлось перезагружаться.

template <typename ...Types>
struct TypeList
{
  using PopBack = ...;

  // было
  struct PopBack { using type = ...; };
};

Откатил все и сделал внешние геттеры

template <typename TL>
using PopBack = TL::PopBack::type;

Оказывается в std::to_string есть баг:

double ip;
double fp = modf(123456789.123456789, &ip);
std::string sip = std::to_string(ip);
std::string sfp = std::to_string(fp);

на выходе:

короче, длинную дробную часть он не умеет конвертить и судя по количеству разрядов, там тупо идёт расчёт на float.

Если что, нормально перевести можно вот так:

std::string sip = std::format("{}", ip);
std::string sfp = std::format("{}", fp);

заодно там будет точка вместо запятой по дефолту.

Багу могут исправить в С++26, про это что-то тут написано, но мне лень читать:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2587r3.html

THE_MASTER
> на выходе:
>
> sip = "123456789,000000"
> sfp = "0,123457"
А что должно быть?

UPD

#include <cstdio>

int main() {
    printf("%e\n", double(123456789.123456789) - double(123456789.123457));
    return 0;
}

ASM generation compiler returned: 0
Execution build compiler returned: 0
Program returned: 0
-2.086163e-07

Ладно, вижу косяк, баг засчитан.

*p_counter++;

Не люблю в принципе конструкции с такими разыменовываниями, редко ими пользуюсь, но сейчас вносил правки в чужой код и нарвался.

Компилятор пишет "implicit declaration of function tralala".
Добавляю #include "ululu.h"
все равно пишет "implicit declaration of function tralala"
что за бред, clean & build, отключил синхронизацию nextcloud, все равно тоже самое.
Копирую из h файла объявления функций, вставляю прямо перед вызовом - работает.
Смотрю на один файл, смотрю на второй файл, ничего не увидел пошел домой. Сегодня открываю

Наверное не баг, но знатно позлило.

Хотел подебажить ironwail (quake порт) в студии, и вообще невозможно из-за тормозов. После остановки на брекпоинте любое нажатие на клаве обрабатывается несколько секунд. Десять секунд уходит на то, чтобы просто вбить переменную из трёх букв в watсh окно. В любом другом приложении тоже ничего нельзя сделать, пока отладчик на паузе. Всё перепробовал - проклинал студию, даунгрейдил, снимал всякие галочки в настройках отладки, а дело оказалось в хуке:

key_hook = SetWindowsHookExW (WH_KEYBOARD_LL, KeyFilter, GetModuleHandleW (NULL), 0);

После этого вызова всё "ломается".