Egorithm, Для таких целей пользовался несколькими коммерческими, но там подписка на сервис и довольно крупные суммы и требуется интеграция с кодом... даже советовать их не буду :)
Из не дорогих понравилась Enigma (https://enigmaprotector.com/ru/downloads.html), но ничего не могу сказать про степень защищённости. Пользовался ихней же Enigma Virtual Box, чтобы объединить несколько сотен файлов в один исполняемый, тоже весьма удобно.
В идеале, как выше уже написано, под каждый проект создаётся индивидуальная виртуальная машина и защищаемый код исполняется в коде этой виртуальной машины. Их сложнее взламывать, потому что каждое отдельное приложение приходится взламывать по новой - проще весь защищённый код переписать, если известно, что он делает. Поэтому защищается не только код проверки лицензии, но и какой-то относительно сложный код приложения... В особо продвинутых случаях защита происходит на сервере организации, у которой вы арендуете защиту, так что у взломщика даже бинарников генератора виртуальных машин нет.
Очень сомневаюсь, что бесплатно и опенсорсно есть хоть что-то относительно взломостойкое. С другой стороны, это С++ и оптимизирвоанный х64 дизассемблированный код сам по себе не очень приятен для чтения человеком :)
Egorithm, защита кода и лицензирование - это разное. Есть бесплатные утилиты для обфускации и защиты (например, Enogma Protector на базе VirtualBox), но это не имеет отношения к лицензированию. Вам же нужно продать лицензию, т.е. чтобы пользователь её оплатил и получил ключ, дающий доступ к полной функциональности. Желательно, чтобы это всё происходило быстро и без вашего участия, т.е. нужна инфраструктура: сервер и ПО с подключенными платёжными системами и генерацией лицензионного ключа.
Если же вся регистрация будет сводиться к оплате через условный paypal и вы вручную будете отсылать лицензионный ключ на почту покупателя, то можно всять любую бесплатную программу защиты кода. И уже в коде программы делат ьпроверку типа: string regCode="REGISTERED!!!!"; .... if( refCode == licenceKey )"
Если программа станет настолько популярной, что хакеры начнут её взламывать, то у вас уже будут средства для покупки нормальной системы защиты и лицензирования.
CaskaProVid, Есть бесконечное число вариантов реализаций. Суть в том, что нужно обеспечить взаимодействие разных объектов любым подходящим способом, но сохранение указателей на Car внутри Bomb очевидно не подходящий вариант. А все другие будут приемлемыми.
Для наблюдателя ещё нужно в объекты добавить свойство "explodable", чтобы наблюдать только за теми, кто в принципе может быть взорван.
Вариантов куча, единственного решения нет.
Артем Масиков, svg - векторные картинки. Они в любом размере будут чёткими. Странно, что сделано вперемешку... Раз png выглядят плохо (если просто файл открыть, не в приложении), то это явно художник плохо сохранил.
Артем Масиков, В любом графическом редакторе откройте картинку иконки и, если там виден этот артефакт (на белом/чёрном фоне), то его нужно стереть. А если не виден, то проблема уже на тапе отображения в программе.
Артем Масиков, По разном уделают. От "плевать, всё равно купят", до создания отдельных наборов картинок для разных разрешений.
Элементы интерфейса выравнивают относительно краёв и друг друга, при этом позволяя им в некоторой степени раздвигаться, если соотношение сторон изменяется. Как бы единого решения нет, кому что нужно, те так и делают. Это я гвоорю исключительно про программы с интерфейсом в виде растеризованных картинок. Если векторная графика используется, то там никаких проблем с размерами нет. Но в реализации обойдётся дороже, скорее всего.
Артем Масиков, Андроид смартфонов слишком много, опэтмоу под конкретное разрешение делать нельзя. Причём, ещё и соотношение сторон бывает разное.
Не знаком с figma, конкретно ничего не подскажу. Можно попробовать отключить фильтрацию текстур (bilinear filtering или как-то так называться будет). В этом случае не будет цеплять соседние фрагменты картинки, но может появиться заметная пикселизация. Учитывая исходное разрешение, может даже лучше будет без фильтрации.
Хотя, есть ещё вариант, что когда дизайнер делал картинки кнопок, то это у него лишние пиксели в картинку попали. Напрмиер, если он нарисовал всё в большом разрешении, а потом уменьшил с фильтрацией.
Артем Масиков, Если игра рассчитана на экран разрешением 1280*720 пикселей, а у вас больше или меньше разрешение, то могут появляться такие (и другие) артефакты.
Артем Масиков, спрайтшит большая картинка, в которой расположено куча маленьких картинок. Когда в программе задано, то нужно взять фрагмент с координатой x:0, y:0 и размером 30 на 30 пикселей, то, из-за билинейной фильтрации, может захватиться 31 пиксель. Если 31 пиксель отличается цветом от 30 пиксела, то появляется видимый артефакт.
Если же каждая картинка/иконка в отдельном файле, то непонятно, откуда появляются эти дефекты.
mtrx[str-1][col] != 0
И не сравнивать на равенство нулю, вместо этого брать модуль и сравнивать с маленьким числом, обозначающим погрешность. Например: abs(mtrx[str-1][col] > 0.001), для погрешности в 1/1000.
SkyCrusher, Не нужн оникакое приведение типа, нужно убрать амперстанд из строчки "Base *b = &Root;"
Амперстанд тут был бы нужен если бы требовался указатель на указатель:
Base ** base = &Root;
ned_as, Анонимные пространства имён удобно использовать в cpp файлах, чтобы исключить возможность доступа к типам из других файлов. Например в любом файле можно сделать предварительное объявление вида "namespace a{ class F; }" и создавать указатель на F. При этом невозможно сделать объявление типа "struct ex" или foo. Т.е. эту функцию foo может вызвать ТОЛЬКО код, реализованный в ЭТОМ файле и невозможно вызвать откуда-то ещё, потмоу что невозможно написать прототип этой функции в других файлах.
res2001, В данный помент соединение 1 к 1, но потом будет ещё одно приложение, посылающее единичные собщения, но там соединение будет разрываться сразу после подключения и пересылки данных, поэтому будет в синхронном режиме работать и select не понадобится.
Сперва сделал чтение-запись через один порт, но сейчас сделано через два порта, в один порт сервер пишет из второго читает, а клиент наоборот. Это для простоты отладки, чтобы случайно данные не портить, потом хочу на один порт поменять.
Спасибо, кое что прояснилось!
И ещё вопрос вдогонку: при использовании неблокирующего сокета, будет ли функция accept ждать подключения или тоже сразу вернёт управление и её над в цикле крутить? И connect тоже в цикле крутить?
Я уже передаю сотни мегабайт, полёт нормальный. С сокетами работаю через Poco и напрямую с буферами не общаюсь, а использую классы-обёртки, реализующие интерфейс std::stream. Просто по Poco никаких сложных примеров не нашёл и обратно читаю по С сокетам, чтобы разобраться.
Чтение-запись выполняется в отдельном потоке, поэтому настоящий асинхронный код мне не особо нужен, т.е. я могу ждать в recv хоть сколько, если это в принципе допустимо сокетами.
Т.е. при испоьзовании блокирующих сокетов можно вообще без poll/select обойтись и сразу вызывать recv и в ней сидеть и ждать?
Из не дорогих понравилась Enigma (https://enigmaprotector.com/ru/downloads.html), но ничего не могу сказать про степень защищённости. Пользовался ихней же Enigma Virtual Box, чтобы объединить несколько сотен файлов в один исполняемый, тоже весьма удобно.
В идеале, как выше уже написано, под каждый проект создаётся индивидуальная виртуальная машина и защищаемый код исполняется в коде этой виртуальной машины. Их сложнее взламывать, потому что каждое отдельное приложение приходится взламывать по новой - проще весь защищённый код переписать, если известно, что он делает. Поэтому защищается не только код проверки лицензии, но и какой-то относительно сложный код приложения... В особо продвинутых случаях защита происходит на сервере организации, у которой вы арендуете защиту, так что у взломщика даже бинарников генератора виртуальных машин нет.
Очень сомневаюсь, что бесплатно и опенсорсно есть хоть что-то относительно взломостойкое. С другой стороны, это С++ и оптимизирвоанный х64 дизассемблированный код сам по себе не очень приятен для чтения человеком :)