Евгений Шатунов

Хочу порекомендовать тебе материал от разработчиков PVS-Studio относительно моделей данных в C++. Там хорошо и коротко объясняется суть твоего вопроса.
Так же тебе будет полезно изучить документацию C++, где можно изучить подробности.

Модель данных выбирается при трансляции и не может быть изменена в уже собранном бинарном коде. Абсолютно весь бинарный код опирается на значения модели данных буквально в каждый момент времени исполнения. Изменение модели данных бинарного кода потребует детального анализа как исполняемого кода, так и всех структур памяти, которыми бинарный код оперирует. Это будет эквивалентно повторной трансляции исходного кода в бинарный с иной моделью данных.

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

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

Для лучшего понимания материала тебе стоит изучить, как минимум, эту статью.


Отображение между пространствами выполняется через операцию перемножения позиции в исходном пространстве на матрицу преобразования пространства. Если подходить к этой задаче в лоб, то отображение каждой позиции потребует 16 операций перемножения над вещественными числами.
Всего для заполнения области презентации кадра требуется выполнить, как минимум, три последовательных отображения геометрии, что будет означать по 48 операций умножения на каждую позицию отображаемой геометрии.

Учитывая что Projectionmatrix и ViewMatrix в процессе презентации кадра являются неизменными, затраты в 48 операций на каждую позицию выглядят как расточительство. Если до презентации выполнить отображение самого пространства вида в пространство проекции, т.е. перемножить ViewMatrix и Projectionmatrix в правильном порядке, то с помощью результирующей матрицы viewProjectionMatrix число операций на одну позицию можно снизить до 32.
Если же произвести отображение самого локального пространства модели в пространство презентации через перемножение матриц viewProjectionMatrix и ModelMatrix в правильном порядке, то благодаря полученной таким образом MVPMatrix число операций на одну позицию снизится до изначальных 16.

Таким образом, матрицы viewProjectionMatrix и MVPMatrix просто позволяют снизить трудоемкость презентации кадра. Однако, во время презентации может потребоваться определение положения геометрии в каком-либо промежуточном пространстве, поэтому вдобавок к MVPMatrix в шейдер принято отдавать и ModelMatrix, и матрицы камеры.
У каждой из матриц свой смысл. И если MVPMatrix бесспорно нужна всегда, то любую другую матрицу в шейдер добавлять стоит только исходя из осмысленной необходимости. Регистры GPU для шейдера не резиновые и могут очень быстро забиться избыточными данными. К тому же, чем меньше на каждом кадре в шейдер передается данных, тем быстрее выполняется презентация кадра.

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

Дело в том, что OpenGL является т.н. GAPI, т.е. интерфейсом прикладного программирования графики.
На базе такого GAPI строятся движки, фреймворки и простые проекты. SFML, будучи фреймворком, точно так же базируется на OpenGL для работы с графикой.

В связи с этим, если ты не планируешь работать с графикой, то можешь просто не использовать модули Window и Graphics. Как следствие, у тебя не будет возникать зависимости от OpenGL.
Но если для тебя важно пользоваться графикой SFML, то в его стандартной поставке без OpenGL твой проект не соберется.

Для начала стоит обратиться к какому-нибудь источнику информации об этом шаблоне. Например, к этому.

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

Иными словами, под монструозным конструктором понимается намеренное создание монолита. Монолит создается, как правило, один раз и потом тухнет до полного разложения его кода, когда пользоваться им уже невозможно в следствии объема его ошибок, но и отрефакторить тоже невозможно в следствии его монолитной организации.

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

Давай представим что нам надо выполнить рейс на МИ-8. Но чтобы автоматизированная система современного аэродрома дала нам разрешение на взлет, нам надо передать ей специальный хеш.


Иммутабильный объект можно получить через идиому RAII или фабричного метода. Но что если для создания иммутабильного объекта требуется очень много параметров? Например - 16 параметров. Или 23, как в одном случае. Или - 42 параметра.
Что если часть этих 42 параметров можно вычислить из остальных, но вот иногда их нужно указывать явно?
Что если всего параметров 42, но для конструирования требуется использовать лишь произвольное подмножество этих параметров? Припоминаются SQL-запросы, правда ведь?
RAII в этом случае захлебывается и становится непонятным, а фабричных методов требуется столько, что ими становится тяжело управлять. Идиома фабричного метода в этом случае начинает проявлять свои негативные качества и тормозить разработку.
А билдер со всеми такими случаями легко справляется. Напомню, что Immutable в принципе невозможно снабдить сеттерами, т.к. это нарушит иммутабильность. А если выйти из ситуации через преобразование одного Immutable в другой, то достичь таким способом получится лишь комбинаторного взрыва иммутабильных типов, похоронив тем самым дальнейшую разработку.

Но давай представим другой пример. Допустим, система диспетчеризации аэродрома принимает сигнал о готовности взлета со стороны борта. Разрешать взлет или нет? Кажется, сперва надо то-то проверить перед резолюцией.


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

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

При этом, объявление внутри статической библиотеки некоторых функций экспортными никак функциональную зависимость не проявляет.
В качестве эксперимента, сделай в коде основного модуля сборки волатильный указатель, скажем, на __getCount и после сборки проекта ты, внезапно, увидишь функцию в таблице экспорта.

Все дело в том, что полная компоновка (linkage) кода производится только для базового модуля сборки, т.е. для самого плагина. Все статические библиотеки, от которых зависит твой базовый модуль, проходят сортировку по зависимостям и компонуются со строгой фильтрацией.
Это значит, что если уже скомпонованный код не ссылается на какую-то функцию из статической библиотеки, эта функция не будет скомпонована. Сортировка библиотек по зависимостям требуется для того, чтобы как раз позволить за один проход по очереди библиотек скомпоновать весь необходимый код.

Есть несколько способов обойти правило компоновки библиотек.
Первый и самый простой: вынудить компоновщик обработать всю библиотеку целиком. Это делается через представление библиотеки как Whole Archive[?].
Однако, в этом случае вся статическая библиотека будет скомпонована в исполняемый код. Это не всегда бывает удобно. Особенно если в библиотеке находится много отладочного кода.

Второй вариант - это использовать __attribute__((used))[?] или [[gnu::used]] на новый лад.
В коде для Visual C++ можно использовать #pragma comment(linker: "/include:")[?].
Данные конструкции помечают функцию как важную для компоновки, в результате чего функция всегда будет компоноваться из статической библиотеки в бинарный код.

Вариант третий - это использовать опцию -u[?] компоновщика.
Для Visual C++ такой опцией будет /INCLUDE[?].
Указание важных функций для принудительной компоновки прямо в сценарии сборки является наиболее прозрачным и удобным методом с точки зрения дальнейшей поддержки кода.

template <typename T>
T maxn(T arr[], int arrSize);

Это - общая форма шаблона функции. Если тебе нужно сделать явную специализацию шаблона, твоя явная специализация должна соответствовать этому общему шаблону.

template <>
const char* maxn(const char* arr[], int arrSize);

Сырые однобайтовые строки в C++ (при соблюдении правила нуль-терминации) определяются типом char* или const char* если строку не планируется модифицировать. Наша функция не планирует модифицировать строки, следовательно явная специализация шаблона должна работать с типом const char*.
Тип const char* должен быть подставлен везде вместо параметра шаблона T.

Таким образом явная специализация шаблона для сырых строк будет полностью соответствовать общему шаблону функции.

А теперь немного о твоей ошибке.

template <> char* maxn(const char *arr[], int arrSize);

Это объявление не является явной специализацией приведенного выше шаблона. Это - определение перегрузки функции через явную специализацию какого-то иного неописанного шаблона. Это потому что результат функции char* отличен от параметра функции const char*.
В целом, эта запись является плохо сформулированной (ill-formed) по целому ряду причин, включая и то, что перегрузка не может осуществляться через изменение типа результата функции.

В целях обучения я советую не опускать перечисление аргументов явной специализации шаблона:

template <>
const char* maxn<const char*>(const char* arr[], int arrSize);

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

Для начала стоит учесть общую систему опознания осей в 3D-пространстве. Оси X, Y, Z помечаются каналами цветов R, G, B в однозначном соответствии. Ось X всегда и везде красная. Ось Y - зеленая. А ось Z - синяя.

glVertex3f(0, 0,znear);
glVertex3f(0, 0,zfar);

Этот код говорит рисовать коллинеарную со взглядом линию. GPU не станет тратить ресурсы на всю линию и нарисует только одну точку, которая с высокой долей вероятности будет затерта при растеризации других примитивов. Ведь все три линии у тебя рисуются из нулевых координат.

Сдвинь начальные координаты осей X и Y от нуля (хоть на 1pt), измени цвет оси Z, тогда ее станет немного лучше видно.

Это простой способ поделить строку на подстроки.

inline std::vector<std::string_view> SplitString( std::string_view input_string, const char separator )
{
	std::vector<std::string_view> parts;

	size_t part_length = 0;
	while( ( part_length = input_string.find( separator ) ) != input_string.npos )
	{
		parts.emplace_back( input_string.data(), part_length );
		input_string.remove_prefix( part_length + 1 );
	}

	if( !input_string.empty() )
	{
		parts.push_back( std::move( input_string ) );
	}

	return parts;
}

Судя по комментариям к ответам, у тебя формулировка вопроса не соответствует твоим ожиданиям.
Совместимость языков - это тонкий маршалинг типов и совместная линковка в один бинарный файл.
Этим условиям, в разной степени, удовлетворяют: C, asm, D, C#, Java. Может быть еще какие-то языки. При этом, у каждого языка верхнего уровня будут свои требования к маршалингу типов и передаче управления.

Тебя же интересуют встраиваемые языки.

Взять, например, D. Он полностью совместим с C++. Однако, его требования не позволяют простую линковку объектных файлов C++ и D в один бинарный файл. На C++ или должен быть создан D Runtime (что не так просто сделать), или C++ код должен линковаться в бинарник на D, в качестве Better C++. Т.е. получается наоборот, в базе будет D, а C++ его только расширяет.
С питоном и Java все точно так же. C# вообще работает с библиотеками классов, написанными на C++/Cx, т.е. на модифицированном C++.
Эти языки не являются встраиваемыми. Их возможности расширяются за счет использования C++.

Хорошим ответом на твой вопрос будет вот такой список встраиваемых языков. Из этого списка можно брать любой язык, ядро которого написано на C или C++.
Мой личный выбор - это AngelScript и Lua/Terra.

class rck{
public:
    unsigned short x,y;
    void show();
    int tm=0;
    uint8_t type=0;
};

У тебя объявлен, вроде бы, агрегатный тип с неявным конструктором по умолчанию, в котором выполняется инициализация только полей tm и type.

rock.push_back({(uint16_t)(x*64),(uint16_t)(y*64),0,0});

Тут перед обращением к push_back формируется фиктивный std::initializer_list<uint16_t> с двумя элементами внутри.
В общем смысле, до полного списка аргументов нужно указать еще два аргумента. Тогда эту запись можно будет считать агрегатной инициализацией временного объекта типа rck.

Такая форма агрегатной инициализации стандартизирована в C++11. До C++14 агрегатная инициализация отключается для типов, в которых присутствует инициализация полей по месту объявления (в коде это поля tm и type). Каждый следующий стандарт требования к агрегатной инициализации только ужесточает.

GCC давно славится своей слабой поддержкой стандарта языка. Это означает что если код проходит трансляцию g++, это далеко не факт что он соответствует стандарту.
NDK сегодня для сборки использует clang, который на данный момент считается максимально приближенным к стандарту транслятором.

Все это должно дать понять что данный код не соответствует стандарту языка и не должен компилироваться. Подходящего конструктора от двух аргументов для типа rck не определено и тип не является агрегатным.
То, что g++ смог собрать этот код, останется на совести g++.
Еще одним важным моментом будет точное понимание, какой именно стандарт языка выбран для трансляции твоего кода.

Вопрос, на самом деле, заключается не в выборе межу LoadLibrary и #include, а в выборе между явным и неявным связыванием.

При неявном связывании компоновщик добавляет в PE-секцию импорта дополнительный блок импорта конкретно указанной библиотеки. Этот блок обрабатывается загрузчиком PE в момент подготовки к запуску процесса. Эта информация тебе уже должна быть знакома. К моменту передачи управления в точку входа процесса все неявно связанные библиотеки уже загружены и готовы к работе. Код процесса не нуждается в явном управлении загрузкой таких библиотек.

Явное связывание выполняется полностью кодом процесса, для чего и применяется набор функций для работы с библиотеками. Явное связывание - это большая рутина. Но иногда без этой рутины никак.
Поиск динамических библиотек при работе LoadLibrary[?] осуществляется в соответствии с определенным порядком. При этом, путями для поиска динамических библиотек можно управлять в ручном режиме, добавляя новые или замещая имеющиеся пути поиска.

Директива препроцессора #include[?] лишь косвенно относится к вопросу. На самом деле к вопросу относится директива #pragma comment( lib )[?].
Прагма работает только для cl - компилятора от Microsoft. Подключаемая таким образом статическая библиотека должна находиться в перечисленных Library Path, в настройках сборки проекта. Эта прагма является альтернативой прямого указания статической библиотеки в настройках сборки проекта.
Эту директиву любят использовать в сторонних заголовках, код для которых поставляется только в бинарном виде, в статических или динамических библиотеках. Вместе с динамической библиотекой такого решения поставляется и библиотека статическая, в которой находятся инструкции для неявного связывания с динамической библиотекой. Результатом работы #pragma comment( lib ) с такой статической библиотекой будет неявное связывание твоего кода с указанной динамической библиотекой.

Размер PE ощутимо растет при компоновке из статических библиотек.
Явное и неявное связывание слабо влияют на размер PE, но явное связывание усложняет жизнь разработчика, т.к. поддерживать загрузку интерфейса библиотеки разработчику придется самому.

Drottarutarnum, p = { s }; - это Copy Initialization.
В буквальном смысле, что тут происходит. Сперва ты создаешь temporary local через конструктор Protocol::Protocol(Serial &s). Следом, через operator =, который сводится к конструктору копирования/перемещения, ты делаешь Copy Construction объекта p. Делается это через конструктор копирования/перемещения по умолчанию, который просто копирует/перемещает поля используя их конструкторы копирования/перемещения.

Лямбда создается внутри temporary local значения, т.к. именно для него вызывается соответствующий конструктор. Далее эта лямбда остается жить в объекте Serial, а сам temporary local уничтожается сразу же после конструирования p.

После этого в замыкании лямбды остается dangling pointer на уже уничтоженный this.

Одним из возможных решений данной проблемы может быть не p = { s };, а p{ s }; или, как ты уже описал, p = s;. Такой тип инициализации уже называется Value Initialization. Но по своей сути это только отсрочка проблемы. Тебе придется очень пристально следить за жизнью такого объекта, т.к. вероятность обрести все тот же висячий указатель в замыкании в следствии неявного копирования крайне высока.

Другим из возможных решений такой проблемы может быть использование std::enable_shared_from_this[?], std::shared_ptr[?] для хранения протокола и std::weak_ptr[?] в замыкании твоей лямбды. Этот метод гарантированно решит твою проблему, но может привести к ряду других проблем с возможной утечкой ресурсов.

В качестве еще одного способа - научить Serial отцеплять лямбду уничтожаемого Protocol и написать правильный конструктор копирования Protocol, соблюдая правило 3/5/0.

В общем смысле, тебе стоит внимательнее смотреть за тем, какие операции ты выполняешь над объектами, сырой указатель на которые ты хочешь где-то сохранить.

Если почитать твой код внимательно, то становится видно немало проблем.

[&p, &all_files_and_sums]
Если с захватом all_files_and_sums по ссылке я не спорю, то точно ли p продолжит существовать после выхода из итерации? Давай подумаем. А после выхода из цикла продолжит?
У меня вообще нет уверенности в том, что после смещения bfs::directory_iterator адрес возвращаемого им bfs::directory_entry изменится. Я бы предпочел захватывать копию bfs::directory_entry в лямбде.

У тебя нет ожидания окончания работы от пула потоков - нет синхронизации с завершением запланированных задач. Точнее... ну как нет... У тебя жесткая синхронизация через std::future::get[?]. По факту в этот момент у тебя блокируется главный поток до момента обработки запланированной задачи. У тебя всегда планируется только одна задача. А видимость конкурентной работы создается лишь потому что какой поток ее схватил, тот и работает. Видимо задачи у тебя быстро обрабатываются, раз ты глазами этого не увидел.

Тебе стоит сохранять сами std::future от задач. В момент планирования их результат еще не определен и get вызывать не надо. Надо дождаться завершения работы всех потоков в пуле и исчерпания всех задач. Для этого у тебя в пуле должны быть продуманы механизмы оповещения.
После обработки всех задач ты можешь вызывать std::future::get, получать результаты и производить свои операции над ними.
Альтернативно, ты можешь более тонко реагировать на завершение каждой задачи и появление в ее std::future результата. Это тоже можно сделать. Просто сделать это надо своими руками и продумав масштабируемость такого механизма.

И в дополнение. Зачем тебе boost? Ты пользуешься std::future и лямбдами, ты пишешь в рамках стандарта C++11. Тебе доступны и std::thread, и все примитивы барьерирования из std.
В твоем распоряжении вся Thread Support Library. А boost тут явно лишний.
Если переключишься на C++17, то тебе и boost::filesystem не будет нужна, т.к. станет доступна std::filesystem - Filesystem Library.

Начнем с простого.
sizeof( expresion ) позволяет узнать минимально допустимый размер памяти, требуемый для того чтобы память могла вместить объект с типом результата утверждения expresion.
sizeof( value ) вернет размер LPCWSTR, т.е. размер типа const wchar_t*.

wcslen не допускает передачу нуля в качестве своего параметра. Забота об этом лежит полностью на тебе.

RegSetValueExW может принимать нуль в параметре lpData, но тогда cbData обязан содержать 0. Но в целом, это очень плохая практика. Если тебе нужно записать пустую строку, пиши пустую. строку. Т.е. "", но не нуль.

cbData должен быть задан размером буфера строки в байтах, включая терминальный символ, или оба терминальных символа в случае многострочного аргумента в lpData. Важным замечанием будет именно то, что в cbData указывается размер в байтах, а не в символах. У тебя в lpData передается строка из wchar_t, размер которого больше одного байта.

Далее, по самому коду. Его тяжело читать.

Для современных версий ОС Windows в наборе WinAPI присутствует функция SHGetKnownFolderPath[?].
Она позволяет получить путь к некоторым предварительно определенным папкам, набор которых описан абстракцией KNOWNFOLDERID[?].

Тебе подойдет FOLDERID_Desktop для получения папки рабочего стола пользователя.
При работе с этой функцией очень важно не забывать пользоваться функцией CoTaskMemFree[?] для освобождения памяти, переданной из функции через указатель ppszPath.

Через NDK доступна функция mkdir[?].
Ее поведение для Android ни чем не отличается от изложенного в официальной документации.

Для проверки существования папки можно использовать функцию stat[?], а можно опереться на код ошибки EEXIST из mkdir.

Абсолютно точным ответом на твой вопрос является: смотря как настроишь контекст.

Здесь стоит припомнить некоторые базовые этапы графического конвейера.

Первым этапом является обработка вершинных данных. Она выполняется для каждой вершины в примитиве. Отказаться от обработки какой-либо вершины пользователь не в праве. С другой стороны, обработка вершинных данных, обычно, выполняется быстро и вершин, обычно, куда меньше чем фрагментов.
Поэтому, чтобы загружать GPU только правильными вершинам, эти вершины стоит правильно выбрать для передачи ему. За это должна отвечать стадия отсечения примитивов при подготовке кадра к презентации.

Вторым важным сейчас этапом является обработка фрагментных данных. Растеризация, если проще.
Для растеризации каждый примитив бьется на фрагменты, обработка которых происходит в индивидуальном порядке. На этапе растеризации от обработки фрагмента уже можно отказаться прямо в шейдере. Это может немного ускорить презентацию кадра.
Обработка фрагментов разной геометрии никак не регламентирована и может происходить в произвольном порядке.
При этом, если один фрагмент имеет отношение к нескольким участкам геометрии, он будет вычислен из каждого такого участка. Это называется Overdraw (Перекрытие).
Перекрытие не только ведет к обработке ненужных, часто не видимых, фрагментов, но и приводит к графическим артефактам, вроде z-fighting. Разработчики стараются не допускать перекрытия геометрии через более агрессивное отсечение полигонов в модели и сортировку геометрии, а не моделей, в пространстве. Так же есть ряд эффективных техник работы с буфером глубины (например), которые позволяют практически полностью справиться перекрытием.

Поэтому, при правильной настройке контекста, при выборе только важной для кадра геометрии, при работе с буфером глубины, при использовании Adaptive Shading и вовремя отбрасывая фрагменты из стадии растеризации скорость презентации будет выше чем без всех этих настроек.
Если ты сделаешь у себя z-prepass, то сортировка геометрии по расстоянию до камеры для тебя станет избыточной.