res2001

Как устранить ошибку конверсии при использовании битовых полей?

Не использовать битовые поля. Серьёзно. Удобств на копейку а мороки на рубль.

Репозиторий проекта - это не что-то стандартное. Авторы вольны применять любые процессы и скрипты для сборки. Может когда-то какой-нибудь ЧатЖПТ и сможет "прочитать" ридми ЛЮБОГО проекта и проделать всё необходимое для его сборки, но пока что такой инструмент мало реалистичен. Если разработчик сам не настроил CI/CD в проекте, то никак без него это сейчас не сделать.

Кластерный индекс... это на самом деле понятие крайне виртуальное.

Что такое обычный некластерный индекс? берём выражение индекса, считаем его значение для каждой записи, сортируем и пишем на диск. Получаем отдельную структуру, в которой выражение индекса сортировано. Когда потребуется искать заданное значение этого выражения, мы вместо просмотра от записи к записи сразу половинным делением быстренько найдём нужное значение, возьмём из него уникальный идентификатор записи, и обратимся за записью. Если в таблице 1000 записей, то для поиска заданного значения без индекса нам в среднем пришлось бы просмотреть 500 записей, а с индексом - всего 10.

Теперь что такое кластерный индекс... сначала почти то же. Берём выражение индекса, считаем его значение для каждой записи, сортируем и... а вот теперь не записываем по порядку эти значения с номерами соответствующих записей в отдельную структуру, а сами записи располагаем в этом порядке. Теперь, когда потребуется искать заданное значение этого выражения, мы вместо просмотра от записи к записи, как это было, когда записи не сортированы, сразу половинным делением быстренько найдём нужное значение. Но нам уже не надо получать номер записи и обращаться за ней - мы нашли саму нужную запись.

В MySQL (точнее, в используемом по умолчанию движке InnoDB) первичный индекс, во-первых, существует ВСЕГДА, во-вторых, определяется так (в статье, на которую дали ссылку, имеются неточности в пункте 2):

1. Если первичный ключ задан явно, то его выражение является также и выражением кластерного индекса. Или иначе - первичный ключ и есть кластерный индекс.
   
2. Если первичный ключ явно не задан, но в таблице имеется индекс, отвечающий всем следующим требованиям:
   
   • является уникальным
     
   • не является функциональным, в т.ч. не использует в выражении вычисляемые поля
     
   • не использует в выражении поля, которые определены как допускающие значение NULL
     
   
   то именно такой индекс используется в качестве первичного. А если таких индексов несколько, то используется первый по тексту запроса на создание таблицы
   
3. Если не имеется ни того, ни другого - генерируется синтетический скрытый 6-байтовый номер записи, который и используется как первичный ключ. Следует отметить, что штатных способов доступа к этому значению не существует.
   

Выглядит так, как будто это просто физическая сортировка данных по индексируемому полю.

Фактически - именно так.

Создаётся ли отдельная таблица или просто упорядочивается хранение существующих данных?

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

Если данные упорядочиваются этим индексом, допустим по ID, то почему при select без сортировки данные могут возвращаться в произвольном порядке, а не отсортированные по ID по-умолчанию?

Если не задан явно ORDER BY, сервер имеет право вернуть записи в любом порядке, как ему удобнее. В большинстве случаев, но не всегда, он будет возвращать записи в порядке чтения с диска...

Представь такой (на самом деле невозможный, но не суть) случай - ты запросил таблицу. Вторая половина её ещё лежит в кэше, а первая уже выдавлена оттуда данными другой таблицы, нужными для выполнения запроса. Конечно, наиболее оптимальным будет начать передачу данных клиенту с этих записей, а пока они передаются, подчитать остальные, и передать их позже. Вот тебе порядок-то и поломался...

===

PS. Кстати, правило выбора индекса, который будет использоваться в качестве кластерного, имеет неприятный побочный эффект. Если у некоторых полей, входящих в какие-то индексы, изменяется свойство NULLability, то это может привести к изменению того, какой из имеющихся индексов станет использоваться в качестве первичного по пункту 2. В результате мы получим невозможность использования INSTANT / INPLACE методов, и будет использован длинный COPY. Впрочем, ситуация такая крайне редка.

Похоже на какие-нибудь циклические инклуды.
У вас в data_process.h случайно не включается data_process.c?
Так делать не надо.

В C параметр функции не может быть массивом, только указателем. Синтаксис "имя с квадратными скобками" несёт тот же смысл, что и "имя со звёздочкой" когда речь идёт о параметрах функции. Если внутри функции взять sizeof от такого параметра результат будет равен sizeof от указателя. Это очень распространённая ошибка и компилятор говорит тебе об этом. Если тебе нужен размер массива переданного в функцию -- передавай его отдельно, например отдельным параметром.

sizeof(dict)/sizeof(const char)

Здесь ещё одна ошибка: dict -- это массив указателей (на самом деле указатель на такой массив, но по крайней мере, ты ожидал массив указателей), но ты делишь размер массива на размер const char а не на размер const char *. Во избежание таких ошибок для вычисления размера массива обычно пишут sizeof(dict)/sizeof(dict[0]).

Два серверных файла конфигурации с разными портами и настройками пулов адресов и два соответствующих им клиентских файла конфигурации

можно подумать, что при объявлении указателя, символ * относится к имени(не как часть, а как что-то зависящее от него), а не к типу.

Если взять стандарт языка (например C99) и почитать главы Declarations, Type Specifiers и Declarators, то можно увидеть, что он разделяет declaration-specifiers, в который входят только слова и declarators, в который входят скобочки и звёздочки. Т.е. твой вывод по сути верный.

Там же можно увидеть, что часть называемую declarator всегда можно обернуть в скобки, из чего можно извлечь следующий вывод: часть объявления вокруг которой можно поставить скобки самым широким образом относится к конкретному идентификатору, оставшаяся часть -- ко всему списку. Т.е. const char *a, b; можно превратить в const char (*a), b, но нельзя превратить в const (char *a), b или в char (const *a), b.

Ну и напоследок стоит добавить, что такая интерпретация объявления не следует ни из чего с необходимостью, это просто решение которое было принято разработчиками языка. Они могли принять это решение по-другому и тогда уже другие конструкции вызывали бы наше удивление.

Потому что 0.1 в двоичном коде не представимо конечным числом.
0.1₁₀ = 0.0(0011)₂
Записывая это число в 32-битовый float вы получаете 1.10011001100110011001101₂ * 2^-4 или 0.100000001490116119384765625₁₀
Соответственно, когда вы 20 раз прибавляете 0.1 к -1, вы не получаете 1. Вы получаете 1.000000298023223876953125₁₀.
Это число, очевидно, больше единицы, поэтому условие цикла не срабатывает и 21я строка не выводится.

Поискав в интернете

обычно там же рядом пишут причину, "дорогая" это операций на больших объемах данных, так что в процессе контакта, создают сессионный симметричный ключ (который в этом процессе сложно как-то перехватить) и дальше уже им с меньшими затратами можно шифровать
https://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D0%B0%D...

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

Практический совет - лучше писать через индексы, ибо так понятнее и больше шансов что компилятор там все наоптимизирует (например, он сможет векторизовать работу через какие-нибудь SSE инструкции процессора).

Совет по бенчмарку - если памяти не хватает, стоит по одному достаточно большому массиву пройтись 10000 раз. А лучше использовать готовые фреймворки для измерения скорости, вроде того де gbenchmark.

Еще, иногда полезно посмотреть на ассемблерный выхлоп. Вот, например, что происходит при -O3 опции компилятора. Он генерирует вообще идентичный код для обеих функций (развернув циклы)! И даже при -O2 оно одинаковый код выдает.

Без оптимизаций код разный, но там все не так как вы думаете. Вместо инструкции mov eax, dword ptr [rax + 4*rcx] в варианте с индексами используется инструкция mov eax, dword ptr [rax] для указателей. Это самое "складывание с указателем массива" вообще не отдельная операция - а вариант адрессации в инструкции mov. Они могут вообще одинаковое количество тактов занимать, это надо мануал по конкретной архитектуре процессоров читать.

С какой ветки обновляет git pull?

С той удаленной ветки, которой соответствует ваша текущая локальная ветка

Когда в своей ветке я нажимаю git pull, то каким образом происходит обновление моей ветке?

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

Например я создал текстовый файл в master и хочу, чтобы он появился в моей ветке, как это сделать?

Слить мастер в вашу текущую ветку

git pull не добавляет его?

Если вы находитесь в другой ветке, отличной от мастера, то нет - не добавляет

Добавлю к вышесказанному.

Пинг меряет вовсе не время передачи между исходным и конечным узлами. Показываемое время в основном уходит на обработку пинга как промежуточными узлами (после приёма надо решить, куда отправлять, а это время), так и конечным узлом (получив пинг, надо сформировать и отправить понг). А если какой-то из этих узлов сильно загружен, то и пинг получится немаленьким (но больше всего может отличиться конечный узел - ответ на пинги имеет крайне низкий приоритет, и узел будет формировать ответ в самую последнюю очередь, лишь переделав всё остальное).

Так что маршрут в 20 хопов имеет более высокий шанс показать большее время пинга по сравнению с маршрутом в 10 хопов, даже если он физически и короче.

Для подобных целей уже давно заведены intptr_t и uintptr_t [?], а еще ptrdiff_t [?].
Именно эти типы и стоит использовать для прямой работы с адресами.

Теги C и C++ смешивать не совсем уместно. Это мешает выбору более подходящего варианта ответа.
В C++, например, если нужно только хранить адрес и позволять с ним только определенные операции, лучше мог бы подойти enum class MemoryAddress : uintptr_t;. Пустое перечисление с достаточной шириной и выравниванием избавит от возможности случайно что-то куда-то прибавить или умножить, да и от неявных преобразований убережет. А перегрузка операторов поможет разрешить только определенные операции.
Но в C так не получится.