Как тогда объяснить то, что префиксный инкремент работает быстрее постфиксного?
Для встроенных типов С++ эти операции одинаково быстрые. Но для пользовательских объектов, постфиксный инкремент будет медленнее, конечно. Просто потому, что он возвращает состояние объекта до инкремента, т.е. фактически конструирует новый объект.
На винде вы не можете создать файл с такими правами, просто потому что на винде работуют ACL, а не права Unix и они не совместимы друг с другом.
Вам, видимо, нужно делать скрипт деплоя, как советовал Иван Шумов и запускать его после разворачивания на сервере.
Sazoks, В этом случае уже можно остановиться. Дальнейшее погружение в глубь принесет мало практической пользы, а времени уйдет много. Разве что немного продвинетесь в ассемблере и компиляторах, но это уже не С++.
Вопрос не про отказоустойчивость.
Если бы был про нее, то звучал бы примерно так: Как сделать балансировку OpenVPN серверов для одной ВПН сети с отказоустойчивостью и что бы клиенты видели друг друга.
Балансировка выполняется указанием нескольких серверов в конфиге клиента. Все остальное - как написал hint000, правда одной сети для клиентов уже не будет.
Sazoks, Вы можете указать в списке инициализации потомка вызов конструктора родителя явно. Тогда он вызовется в указанном порядке. Думаю, что по умолчанию (без явного указания в списке инициализации) конструктор базового класса вызывается перед всеми другими операциями в списке инициализации конструктора потомка.
PS: не ясно зачем вам нужны такие подробности. Т.к. конкретная реализация будет зависеть от компилятора, версии и опций оптимизации. Можете посмотреть в отладчике ассемблерный код.
Павел, 10Мб - это вполне нормальный размер. Большой - это 1 Гб или около того, т.е. когда уже findstr на этом файле начнет тормозить.
Если вы будете удалять лог по расписанию, то вместе с логом нужно удалять и обработанные файлы иначе они начнут повторно заливаться. А если лог не чистить, то рано или поздно процесс начнет тормозить, т.к. размер лога станет слишком большим.
Если файлы в папках больше не нужны после обработки, то лучше их удалять (переносить в другой каталог).
Пока писал, придумал еще вариант. Если при записи файлов в каталог у них дата изменения файла изменяется на текущую, то можно просто брать файлы по дате с помощью обратной сортировки в dir или что-нибудь намутить с forfiles. Тогда надо будет, наверное, сохранять дату/время изменения последнего обработанного файла, чтоб при следующем запуске отсекать по ней уже обработанные файлы.
По моему вариант с dir/forfiles более оптимален, чем с лог файлом.
Но файлы в каталоге все равно нужно чистить время от времени, т.к. если оставить это бесконтрольно, то юзера засрут каталог в конце концов :-)
Еще как вариант, прикрутить какую-нибудь утилиту для синхронизации файлов. Названия не подскажу, но они точно есть.
PS: почему FTP? На мой взгляд FTP сейчас - это уже пережиток прошлого.
На сколько понимаю все происходит в локалке. Почему просто не расшаренная папка на сервере?
Но это не принципиально.
В этом случае ошибки с точки зрения компилятора нет, он не проверяет правильность индексации массивов. Ошибка могла бы быть в рантайме, но массив на стеке, память для стека выделена для процесса при старте программы, вы могли бы хоть по всему стеку пройтись без ошибок. Ошибка была бы только при выходе за границы стека.
SeanCooper, Прозрачный прокси обычно используют, что бы фильтровать зашифрованный трафик в корпоративных сетях, например https. NAT + firewall для этих целей не годятся, т.к. они не делают попыток вмешаться в пользовательский трафик.
Прозрачный прокси выдает себя за конечный узел запроса. Когда браузер по https обращается к любому узлу в интернет через прозрачный прокси, прокси расшифровывает запрос, от себя устанавливает соединение с конечным узлом и отправляет пользовательский запрос конечному узлу, заново его зашифровав. Аналогично с ответом на запрос. При этом в промежутке может происходить фильтрация или логирование по расшифрованному контенту.
Пользователь в таком случае у себя в браузере увидит сертификат прокси, а не конечного узла.
Обычный прокси работает абсолютно открыто, т.е. пользователь должен явно указать в настройках ПО, что нужно ходить через прокси (и обычно указать логин/пароль для прокси). Их обычно используют для авторизации доступа к ресурсу. Учитывая, что сейчас в интернете повсеместно используются защищенные подключения, то возможности фильтрации по контенту у обычных прокси сильно ограничены (фактически они сводятся к аналогичным возможностям фаервола).
Дополню.
NAT прозрачна для пользовательского ПО. Т.е. клиентское ПО не должно как-то специально поддерживать NAT.
Использование прокси в общем случае должно поддерживаться клиентским ПО.
Конечно, есть вариант прозрачного прокси, где не требуется поддержка от ПО клиента, но это уже другая история, применяется для других целей.
Илья Петров, какое конкретно MAX в другой задаче? 10^1000 - это слишком большое число, оно не влезет даже в int64.
Свой вариант я проверил на нескольких разных входных данных, результат пересчитывал вручную.
Дайте конкретные входные данные на которых выдается не верный результат, я проверю.
На сколько я знаю, rarlab никогда своих исходников не открывал (в исходниках у них есть только unrar) и вряд ли вы найдете алгоритм, т.к. он, видимо, закрытый.
Андрей, Получить путь к профилю пользователя можно с помощью функции GetUserProfileDirectory() или можно взять путь из переменной окружения APPDATA или LOCALAPPDATA, путь к корню профиля в USERPROFILE.
Вместо CUDA можно использовать SIMD инструкции ЦП. У Intel это SSE/AVX, у ARM - NEON.
Эти инструкции платформозависимые (зависят от используемого ЦП). Если нужно кросс-платформенно можно погуглить библиотеки. Но тут с кросс-платформенностью достаточно сложно.
В Си компиляторах они завернуты в intrinsic функции: https://software.intel.com/sites/landingpage/Intri...
Но перед этим, конечно, все вышеперечисленное стоит применить.
Денис, в линуксе можно повесить скрипт на события up/down для интерфейса wifi. В скриптах дергать openvpn.
В Винде то же можно нечто подобное сделать - повесить в шедулер задание, срабатывающее по событию из системного лога. Найдите события в логе, которые возникают при up/down wifi соединения и на эти события создайте задания.
Для встроенных типов С++ эти операции одинаково быстрые. Но для пользовательских объектов, постфиксный инкремент будет медленнее, конечно. Просто потому, что он возвращает состояние объекта до инкремента, т.е. фактически конструирует новый объект.