Melkij, Если речь идет об итерациях по памяти (в массиве данных), то на 32 битных платформах не зачем иметь 64 битный счетчик, т.к. памяти физически не хватит для адресации второй половины индексов в 64 битном счетчике.
Поэтому в x32 платформах size_t 32 битный, а в x64 - 64-битный, т.е. выбраны оптимальные размеры счетчика для каждой платформы. size_t позволяет адресовать максимально возможное количество данных для конкретной платформы, об этом сказано в стандарте.
Кроме того, использовать знаковый тип для индексации элементов массива - ну это так себе идея - индексы обычно положительные, поэтому используя int мы теряем 1 бит в счетчике (а это половина всех возможных значений счетчика).
Счетчик в цикле не обязательно используется как индекс в массиве, так что всегда надо смотреть на ситуацию. Иногда действительно необходимо использовать uint64_t под счетчик, а иногда и uint8_t достаточно.
Игорь Митраков, Берите исходники kame/swan и прикручивайте к своему приложению.
Или же реализуйте в приложении настройку и запуск того же kame/swan - это будет гораздо проще сделать.
Не знаю зачем вам это нужно. Вы бы еще драйвер сетевой карты реализовали в приложении.
Если вам нужен защищенный обмен - используйте OpenSSL.
aphazel, Да, судя по всему там NAT.
Но реально NAT не нужен, он только мешает. Можете выключить NAT и разрешить хождение пакетов из ВПН во внутреннюю сеть в фаерволе. Более конкретно не скажу, т.к. не силен в линуксовых фаерволах.
В целом мануал выглядит довольно толково, но не понятно зачем они туда воткнули NAT.
, значит он получает ответы из сети, значит этот маршрут уже должен быть задан иначе бы спокойно не ходил. А значит и компы в сети должны видеть клиента ВПН. Возможно блокирует фаервол.
Нужно настроить маршруты на компах сети до ВПН сети через ВПН сервер.
Имеются в виду компы из сети 192.168.24.0/23.
Они же тупо не знают где находится сеть 10.8.0.0 и шлют пакеты для нее на шлюз по умолчанию.
Задайте им маршрут до сети 10.8.0.0 через ВПН сервер и все будет в ажуре.
Герман, Можно и не использовать суффиксы (компилятор преобразует во float сам), но тогда при компиляции можете получить предупреждение о потере значимости (при определенных опциях компиляции).
В переменной типа float не может храниться double. В случае подобной операции double преобразуется во float с потерей значимости. Преобразовать можно явно или не явно. Указывая суффикс вы явно говорите компилятору, что это константа типа float. Кроме того, что суффиксы избавляют от лишних предупреждений, это еще и хороший тон.
Указывать то можно, просто большая часть команд командной строки, работающих с файлами, их не понимает. Для остальных команд UNC-путь - это просто строка.
Но вам и не нужно, чтоб они понимали UNC - главное, чтоб ваша софтина понимала.
Программу и скрипт положите в каталог доступный для чтения всем пользователям
Возможно это косяк именно варианта от vultr. Да и с версиями у них что-то напутано, т.к. на текущий момент актуальная версия OpenVPN 2.4.7.
Поищите другого поставщика услуг ВПН или настройте OpenVPN самостоятельно.
Скорее всего имеется ввиду C++? Поменяйте тег.
В Си нет STL (в т.ч. std::vector) у него своя собственная стандартная библиотека: https://en.cppreference.com/w/c
Почему у вас SYM->freq типа float? Разве частота встречаемости данного символа (количество вхождений данного символа в заданный текст) - это вещественное число?
Зачем вам для code массив char? Хватит и обычного int или uint. Вообще code можно генерировать в процессе обхода дерева на лету.
Избавьтесь от рекурсии.
Где определение struct alphabet и как формируется alphabetLetter.
Метод научного тыка замените на отладчик.
KTG, если оформить как процедуру и в цикле вызывать ее через call, то при возврате из процедуры внешний цикл продолжится нормально.
Не всегда можно экранировать, например, вы получаете строку через параметры ком.строки (тогда пользователь сам должен экранировать) или вы читаете строку из файла. Но судя по вашему ответу с крышкой как раз экранирование в самой строке не требуется, но с другими спец.символами это не прокатит.
Сомнительное решение какое-то, но работает :-)
В первом цикле строка пишется в файл с именем "$":
echo $ - просто возвращает имя файла внутрь цикла. %%~zN-2 - возвращает размер файла, -2 - вычитает 2 байта занятых символами CRLF, которые добавляет echo при выводе.
Сомнительное, потому что, по идее при любой подстановке символа ^ он должен был бы восприняться cmd как спец.символ. Но почему то этого не происходит. Возможно виновато отложенное расширение или cmd с крышкой работает как-то по другому, чем с прочими спец.символами. Скорее всего, если заменить "крышку" на другой спец.символ (&|>< и проч.) то код развалится.
Поэтому в x32 платформах size_t 32 битный, а в x64 - 64-битный, т.е. выбраны оптимальные размеры счетчика для каждой платформы. size_t позволяет адресовать максимально возможное количество данных для конкретной платформы, об этом сказано в стандарте.
Кроме того, использовать знаковый тип для индексации элементов массива - ну это так себе идея - индексы обычно положительные, поэтому используя int мы теряем 1 бит в счетчике (а это половина всех возможных значений счетчика).
Счетчик в цикле не обязательно используется как индекс в массиве, так что всегда надо смотреть на ситуацию. Иногда действительно необходимо использовать uint64_t под счетчик, а иногда и uint8_t достаточно.