Dmitry

Передавайте в функцию указатель на вектор.

Хотя стоп, зачем вам return в цикле? Уберите и попробуйте без него.

char* inputFileName;

Было бы странно, если бы она не падала, поскольку сейчас inputFileName указывает куда-то в пространство.

Чайники обычно делают так:
char inputFileName[256];
и потом думают - как так, меня сломали?
кто поумнее делают так:

char *inputFileName;
inputFileName = (char *) calloc(256, 1);

(это конечно тоже не звездец - нужно учесть максимально допустимую длину пути и имени файла, но уже куда лучше)

Отдельно проверьте, что точка в первой четверти.

Далее, фигура повторяется блоками 2x2, т.е. вам не важны сами координаты, а только их положение в блоке.

Для высчитывания координаты в блоке можно или вычитать 2, пока координата больше 2, или вычесть из x (floor(x) - floor(x)%2). floor(x) даст целые числа. Потом надо это число сделать четным, возможно вычесть 1. floor(x)%2 - как раз и даст нам, что надо вычесть.

А дальше - набор if-ов. вам надо лишь описать, что точка принадлежит одной из двух четвретринок круга в левом нижнем углу.

Универсальное, но не самое гибкое и быстрое решение: raw socket. Работает во всех популярных ОС.

Вопрос очень на самом деле сложный.

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

Зачастую, если пользуешься какой-нибудь средой разработки (IDE, например Microsoft Visual Studio) то за сборку exe файла и всего проекта будет отвечать она, а пользователю в мышевозекательном интерфейсе дается возможность настроить все необходимое.

Например создавая проект "Консольное приложение c++" (название приблизительное, не помню точно уже) проект будет автоматически настроен на сборку консольного приложения, лишних библиотек не подключено и т.п. Мало того, возможно понадобится собрать приложение сразу для нескольких архитектур (x86 и x86_64 например), т.е. по набору exe/dll на каждую архитектуру, и бывают случаи когда даже файлы баз данных не переносимы и потребуют свои для каждой.

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

В самых простых случаях, когда на целевой машине даже не надо создавать ярлык (просто распаковать и все), можно воспользоваться каким-нибудь self extracted archive (у winrar такая опция есть). Иногда инструменты для создания такого пакета есть в самой IDE (точно помню у visual studio для managed .net кода такое было), а иногда это стороннее приложение, для windows рекомендую попробовать inno setup, позволяет создавать не только exe установщик но и msi (специализированный формат windows для установочных архивов), это приложение позволяет описывать процесс установки в виде некоторого языка, не заморачиваясь с интерфейсом.

p.s. windows нет прямого ограничения по запуску приложений без установки, т.е. просто копируй вручную exe файл и все

upd. для с++ добавляется еще один челедж, решить, каким компилятором собирать, какими стандартами (стандарт реализация эксепшен try/catch/throw, формат имен подключаемых dll и т.п.), какими базовыми библиотеками (например какая будет использоваться libc) и даже для какой версии ОС собираешь (например собрав под последнюю win10 приложение может не запуститься на win7 или winxp, потому что будет требовать несовместимую версию visual studio redistributable (vcredist*.exe этот пакет обновлений таскают с собой все кому не лень, и кстати по лицензии делать это без разрешения майкрософт низязя)

Так уж исторически сложилось, что нормально тулчейн найти под windows можно либо:
* gcc (gnu c compiler) - задает всем остальным, тут полнее реализуют новые стандарты, работает во всех ОС, но при этом есть windows сборка (смотреть у mingw кстати она есть по до все ос, позволяет кросскомпиляцию типа из linux собрать windows exe) а есть cygwin (несовместимая ни с чем, но качественно повторяет linux стандарты)
Поговаривают что mingw все, кончился :(
* microsoft visual c++ compiler (идет с visual studio), пытается задавать свои ни с чем не совместимые стандарты, корежит существующие, с целью создать хаос и привязать разработчиков только к windows
и это у майкрософт получается, к сожалению
* llvm и clang (это отдельные проекты но когда говорят об одном то и о другом), стандарт стоит особняком, так как llvm это некая виртуальная машина, с очень эффективной реализацией, с jit и оптимизациями
настроить на windows это еще надо уметь, но есть возможность прописать для использовании в visual studio!

Я нашол .so файл и мне нужно скомпилировать в .c

Чаво сделать-та? Эт типа "я нашел полкило фарша и мне надо получить обратно мясо, из которого он сделан"? Операция, обратная компиляции (а компиляция, чувак - это получение из исходного кода исполняемого модуля) - называется - внезапно - декомпиляцией. И она для .c файлов возможна в очень примитивной форме только в том случае, если в модуле "забыли" отладочную информацию. Во всех других случаях она попросту невозможна :D

Что у вас за операция пересечения?

Первая проблема - вы берете максимальную длину двух строк в size и потом проходитесь циклом до size по обеим строкам. Но ведь более короткой строки там просто нет - вы обращаетесь к не вашей памяти.

Вам надо проверять, есть ли обе строки по индексу i, прежде чем сравнивать их.

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

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

Раз вам число нужно десятичное, то и задавайте его в десетичной системе, без ведущих нулей.

Чтобы дополнить число нулями до заданной ширины при выводе воспользуйтесь setw и setfill:

std::cout << std::setfill('0') << std::setw(4) << i1 << endl;

Программа должна считывать отдельные нажатия, а не ввод строки целиком.

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

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

Книги по ООП, С++