Станислав Макаров

Такие дельные советы тут...

А правило проще некуда: если вы без указания типа и так УЖЕ ИМЕЕТЕ достаточно информации, чтобы уверенно работать со значением - тогда можно использовать auto. Если чувствуете, что не имеете, или сомневаетесь, что имеете - лучше тип указать. Пример, где использование auto отлично подходит - итераторы:

std::list<int> items;
auto i = items.cbegin();

Во второй строке четко написано - items.cbegin - константный итератор по items, бегущий с начала списка. Мне этого более чем достаточно. Указание типа std::list<int>::const_iterator мне никакой новой информации не принесет. Тем более, т.к. итераторы от разных контейнеров несовместимы, то мне нужно еще и сразу знать, по какому конкретно списку у меня итератор - я опять-таки посмотрю на items.cbegin, а не на тип.

А вот auto в объявлениях функций/методов и правда ни к чему. Его, кстати, даже не сразу там разрешили использовать (только в C++14). Причина тому вновь читабельность - чтобы понять, что возращает функция, нужно прочесть ее текст как минимум до первого return, а лучше - полностью. Единственный сценарий, где без auto не обойтись при указании возвращаемого типа - это стрелочная нотация с decltype, но я думаю вы не скоро с ней столкнетесь.

Пользоваться NuGet для работы с зависимостями (https://www.nuget.org/packages/CompareNETObjects/ как раз то что вам нужно), а если уже пользуетесь - очевидно, нужно пофиксить список зависимостей в packages.config, или же сделать nuget restore перед вызовом MSBuild.
Раз сборка не находится, то либо: а) путь к ней неверный; б) путь верный, но она не выкачивается nuget-ом при сборке;
Еще может быть в) косяк с версиями/токенами, но это маловероятно.

Ну и само собой, если у вас код компилится и работает без проблем, удалите вообще этот референс из проекта.

Когда Б обрабатывает событие, возникает исключение как будто метод класса Б работает в потоке объекта А, это нормально?

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

Пофиксил через SynchronizationContext, но может быть есть получше варианты?

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

Ваша проблема решается даже не просто, а элементарно.
Для этого нужно запомнить простейший способ передачи групп элементов переменной (т.е. заранее неизвестной) длины: сначала передавать длину, а потом уже сами элементы в нужном количестве.
Этот подход используется повсеместно. Например, когда на диск сохраняют строки переменного размера, и в строке неудобно/невозможно применить символ-терминатор, то сначала записывают длину строки (неотрицательное число нужной разрядности - байт, 2-х байтовое целое, 4-х байтовое целое), а потом уже содержимое строки. Кстати, такие строки называются паскалевскими (в альтернативу нуль-терминированным Cи-строкам).
Разумеется, приемник пакета должнен быть достаточно умным, чтобы сначала принять длину, выделить себе некую стркутуру нужного размера (вектор подходит отлично, т.к. можно попросить его сразу зарезервировать нужное количетсво элементов), а затем записать ожидамое количество элементов.

Вариант кода передачи:

std::vector<PacketMultiPlayer> serverMuPackets;
......
const unsigned int packetsCount = serverMuPackets.size();
send(sock,(char*)(&packetsCount), sizeof(packetsCount), 0);
send(sock,(char*)serverMuPackets.data(), sizeof(PacketMultiPlayer) * packetsCount, 0); // Имеем право так делать, т.к. вектор гарантирует последовательное хранение элементов. Со списком подобное делать нельзя

Секретная техника:
1) гуглим "visual studio community vs enterprise";
2) открываем один из первых результатов - Compare Visual Studio 2015 Offerings;
3) разворачиваем секцию "Architecture and Modeling", видим, что в Community доступен только пункт "Visualize solutions with Dependency Graphs and Code Maps" со сноской "Can open diagrams generated in other Visual Studio editions in read-only mode";
4) делаем соответствующие выводы.

0) закапываем GLUT, берем GLFW (www.glfw.org ); если это неприемлемо, отпишитесь в комментариях, сделаем другую инструкцию;
1) берем пример, делаем окно по примеру: www.glfw.org/documentation.html
2) когда убедились, что окно появляется и все работает, начинаем перетягивать код из урока;
3) вызов кода отрисовки (который DrawGLScene) вставляем вместо /* Render here */;
4) объявления виндовых дескрипторов убираем (HDC, HWND и прочие); windows.h тоже вроде не нужен;
5) для обработки событий клавиатуры читаем вот это: www.glfw.org/docs/latest/input.html#input_keyboard , для мыши вот это: www.glfw.org/docs/latest/input.html#input_mouse . По сути все элементарно: устанавливаются колбэки, в которых уже находится код обработки;
6) для того, чтобы адекватно выйти из главного цикла приложения (это тот, который while (!glfwWindowShouldClose(window))) в нужном месте (например, по нажатию ESC) вызываем glfwSetWindowShouldClose.

Итого WindowProc вам уже не нужна, из WinMain возможно понадобится код инициализации и код обработки клавиатуры нужно будет вынести в колбэк.
Вопросы в комментарии, все сразу не расскажешь.

P.S. Вообще поищите современные туториалы, это OpenGL 2.0, этот API уже никому не нужен, в 3-м OpenGL всю архитектуру перекроили (зачем? Например затем, что вызывать glVertex для каждой вершины - это слишком затратно). Старые уроки вам будут полезны только для общего развития в CG.

limon_spb пожалуй не все так просто с OpenCL.DLL и видимо ее все-таки не нужно распространять со своим приложением. Однако, как и было сказано ранее, ее интерфейс универсален и ваше приложение не придется перекомпилить под каждое устройство. Вопрос только в том, кто ее должен поставлять.

Вот на форуме Кроноса: https://forums.khronos.org/showthread.php/6299-Ope... господин pcchen утверждает, что OpenCL.dll и ICD-либа должны устанавливаться при установке драйверов на видяху. Видимо все-таки не должны вы класть OpenCL.dll со своей программой.

Тогда мы возвращаемся к вопросу, почему программа не запустилась у вас на машине. Случайно наткнулся на ваш вопрос 1-в-1 на SO: stackoverflow.com/questions/22098210/deploying-ope... . Я думаю у вас была та же проблема - DLL в системных папках реализует API версии 1.1, а вы разрабатываете под API версии 1.2 (что определяется теми хедерами, которые вы подключили в проект). Поэтому правильно все-таки сначала решить проблему конкретно на вашей машине. Возможно, стоит обновить драйвера, и они обновят системные библиотеки.

В той теме на форуме так и не пришли к единому мнению относительно того, откуда должна браться OpenCL.dll. Я склоняюсь к тому, что ставить ее должны драйвера. Кстати, Dithermaster в ответах на SO говорит то же самое. Погуглите еще "deploying opencl application".
Вот еще одна тема с обсуждением (также не советуют деплоить OpenCL.dll самому): https://forums.khronos.org/showthread.php/11392-Ye...

При создании PKCS#12-контейнера (он же PFX) укажите настройку, что ключ разрешено использовать только для создания электронной подписи. Например. для openssl pkcs12 это параметр -keysig. Вы какой утилитой создавали ключ? sn?

[DllImport("вашалиба.dll", CharSet = Ansi, CallingConvention = CallingConvention.Cdecl)]
public void LaunchJavaApplet([In] string[] JVMOptions);