KIberKOtlEtf, Есть смысл делать сборку для винды на винде :-) Поставьте виртуалку с виндой и собирайте там: msys2+mingw или MSVS/MS build вам в помощь.
Это избавит вас от малопонятных на данном этапе ошибок, связанных с разными платформами и компиляторами.
Писать кросс-платформенное ПО на С/С++ - это отдельный скил у программиста.
На других языках, в большинстве случаев, не существует особой проблемы. Потому что об этом уже подумали создатели языка и его стандартной библиотеки. Но это не значит, что эти языки лучше, скорее наоборот, они принуждают программиста использовать именно предлагаемые инструменты для реализации его целей. Но может быть инструменты эти не так хороши или нужно что-то несколько большее, чем реализовано в библиотеке. Но, справедливости ради, в подовляющем большинстве случаев обычно достаточно возможностей.
Это не значит, что на С/С++ нельзя писать кросс-платформенно. Можно и многие так и делают, только кросс-платформенность должен в этом случае обеспечить сам программист, а не ЯП.
Хотя сам по себе С++ вполне себе кросс-платформенный и его стандартная библиотека то же (правда могут быть нюансы даже на одной платформе, но на разных компиляторах), но стандартная библиотека С++ не включает в себя интерфейс для сетевого взаимодействия. Даже более-менее сложная работа с файловой системой появилась там не так давно.
Если вы используете в кросс-платформенном ПО какую-то библиотеку, то библиотека то же должна быть кросс-платформенной и поддерживать те платформы, для которых вы планируете собирать свое ПО.
На сколько я знаю boost.asio прекрасно работает под виндой, так что в этом плане не вижу проблем.
На счет WinSock - по большому счету на винде других альтернатив нет для работы с сетью, тот же boost.asio внутри должен использовать WinSock в каком-то виде, чтоб выполнять свой функционал на винде. Точно так же, как и любые другие ЯПы, где есть поддержка сети, на винде используют WinSock.
WinSock это то же, что и сокеты беркли на линуксе. Попробуйте написать что-то под линь с сетью без сокетов.
Akina, В винде есть утилита cmdkey для управления Диспетчером учетных записей из ком.строки.
Можно попробовать с ее помощью в скрипте предварительно нужную запись создавать, потом удалять.
Кстати, можно начать с того, что проверить список сохраненных учетных записей после выполнения net use. Возможно они все таки сохраняются, как временные, даже без /persistent.
Еще есть утилита vaultcmd, то же вроде бы позволяет делать аналогичные действия, но я ее не использовал, так что это не точно. Из power shell то же можно управлять учетными записями.
AslHack, Немного добавил вывода в ваш тест
Посмотрите результат на годболте.
Полезно будет сравнить ошибки gcc и clang. Поведение clang по умолчанию более адекватное - он предупреждает про усечение размера результата в операции sizeof где в операнде была адресная арифметика.
Если со статическим массивом используется адресная арифметика, то происходит не явное преобразование имени массива в указатель на его первый элемент. Соответственно теряется информация о полном типе массива. Именно об этом предупреждает clang при компиляции (а gcc молчит как пратизан) и это хорошо видно в выводе sizeof.
То же самое происходит при передаче массива в функцию.
Т.е. zippo + 1 имеет тип int[2], а не int[4][2] как можно было бы предположить.
Увлекательная беседа :) AslHack, zippo - адрес всего массива zippo[4][2], тип int[4][2]; zippo[0] - адрес первой строки массива zippo, тип int[2]; *zippo - то же, что и zippo[0]
Учитывая, что значения адреса для zippo, zippo[0], *zippo, zippo[0][0] - одно и то же, то это может вводить в заблуждение. Поэтому вывод вашего последнего теста надо рассматривать совместно с типами, т.е. смотреть пару адрес и тип совместно - только тогда вы поймете, что думает о них компилятор.
Поскольку тип в строковом представлении получить в run-time проблематично, то можно вместо типа использовать результат sizeof и уже по этому значению определять тип элемента.
Проще всего, чтоб не делать ошибок, при работе со статическими массивами всегда работать с ними через индексацию, без адресной арифметики. И относится к имени массива именно как к массиву, а не как к его первому элементу (т.е. не употребляйте *zippo).
Исходный код утилиты ничего не даст - там обращение к драйверу ядра через netlink по умолчанию (или через ioctl если netlink не доступен). Сама утилита лишь отправляет запросы, получает ответы и выводит их на экран.
Так что это вопрос точно к драйверу конкретного адаптера, а не к ethtool.
Имя массива - это адрес начала массива. Тип статического массива - это массив, а не тип его первого элемента, поэтому и имя рассматривается как адрес начала массива.
С двумерным массивом все работает аналогично. Имя двумерного массива - это адрес начала всего двумерного массива.
Напишите тест где выводите sizeof(arrOne) и sizeof(arrTwo) и разные другие варианты, которые придут в голову. Это даст понимание того, как компилятор воспринимает имя массива.
Честно скажу, что я хз какой бест практис для C++ на винде
Я то же не в курсе. Похоже, каждый решает для себя сам этот вопрос.
Писал комментарий, основываясь на собственном опыте использования разнообразных консольных утилит в винде в целях администрирования. Сейчас я с другой стороны баррикад.
Часто, в командных скриптах вывод утилит используется для дальнейшего анализа и выдергивания из него какой-то нужной информации. Если в одном сценарии несколько утилит будут выводить каждая в своей кодировке, то для анализа и применения результата придется вывод каждой утилиты в скрипте преобразовывать в какую-то одну кодировку, это приведет к тому, что код скрипта превратится в сплошную перекодировку, а не в полезную работу.
Как-то так я вижу этот вопрос.
С моей точки зрения, самым правильным вариантом будет последний.
Этот вариант хорош, только если вы пишите "хело ворд" или какую-нибудь лабу в универе, чтоб показать один раз.
С моей точки зрения правильные варианты 2 или 3. Например, посмотрите на большинство консольных утилит, которые поставляются вместе с виндой из коробки - они нормально выводят русские буквы не зависимо от текущей кодировки консоли.
Сам лично, в бытность свою сетевым админом, не однократно вспоминал "добрым" словом создателей консольных утилит, которые принудительно меняли кодировку из программы. Часто консольные утилиты используют из командных сценариев, где обычно кодировку выставляют в самом начале, и если утилита ее сменит, то придется это специально обходить в коде сценария, что не удобно. А представьте, что сценарий большой (это не редкость) и внутри используется несколько разных утилит и каждая из них норовит сменить кодировку на свою - бороться с этим довольно трудно.
Кодировка консоли винды легко меняется на лету командой chcp, и русских кодировок в винде из коробки минимум 3 (866, 1251, UTF8), причем по умолчанию используется 866 (а вовсе не 1251).
К слову, проверять правильность отображения кирилических символов в консоли VSCode (как и в любой другой IDE) не стоит, т.к. сами IDE обычно настраивают кодировку в собственной консоли так как им удобно. В консоли cmd.exe кодировка вероятно будет другой.
Для подключения библиотек обычно пользуюсь pkg_check_modules(). find_package() использую, как правило, только для чего-то типа Threads.
До использования pkg_check_modules() его надо подключить с помощью: find_package(PkgConfig REQUIRED)
pkg_check_modules() для поиска использует утилиту pkg-config, которую можно установить в любой дистрибутив. pkg-config использует для поиска файлы описания библиотеки (*,pc, файлы обычно лежат в /usr/lib/pkgconfig и/или /usr/lib/x86_64-linux-gnu/pkgconfig). Файлы описания обычно готовят сами создатели библиотек и поставляются они вместе с пакетом dev библиотеки, поэтому файлы описания обычно одинаковы для всех дистрибутивов и подобной проблемы тут просто не существует. Имя модуля, указываемое при вызове pkg_check_modules() - это имя *.pc файла.
Саму утилиту можно вызвать из командной строки вручную, посмотреть на параметры, что возвращает и т.п. Еще можно встретить makefile, где внутри используется pkg-config.
Конечно, если в библиотеке нет pc файла, то этот вариант не сработает. Но в вашем случае pc вроде бы должен быть.
Единорог Безрогов, Это все не важно.
Важен результат - у вас на компе что-то происходит и вы об этом не имеете никакого понятия.
Нужно это понятие поиметь, для этого надо произвести некоторые разыскные мероприятия. В конце концов - удалите TAP драйвер, он обычно удаляется стандартными средствами, и то ПО, которому он нужен должно перестать работать и может начнет проявляться какими-нибудь ошибками.
Ютубу и видео плеерам TAP драйвер без надобности.
Обычно TAP драйвер используется каким-то софтом, который хочет перехватывать трафик и что-то с ним делать.
Например - OpenVPN перехватывает трафик предназначенный для передачи по ВПН с помощью TAP драйвера, шифрует его и передает в физический сетевой адаптер. Вместо шифрование другое ПО может делать что-то свое.
Видимо на комп было установлено ранее какое-то ПО, у которого в зависимостях TAP драйвер. Он довольно много где используется. Например в OpenVPN. После перезагрузки компа, возможно, просто продолжается его установка.
Но почему вы об этом не знаете? Вот вопрос.
Если в последние несколько дней вы не устанавливали на комп ничего, то стоит посмотреть, не появились ли какие-то новые процессы в системе, нет ли повышенной активности (загрузки ЦПУ/сети/диска). Возможно подхватили какого-то зверя, ведь защитника у вас нет :) - стоит проверить комп на вирусы.
Сам по себе TAP драйвер не является вирусом или опасным ПО, но тот кому он потребовался вполне может быть им.
Если ваша определенная программа ходит на определенные адреса в интернете (и желательно, чтоб эти адреса не менялись со временем), то можно через таблицу маршрутизации завернуть конкретно эти адреса в ВПН, добавив необходимые маршруты. И все, не надо никаких дополнительных программ вообще.
Тут конечно могут быть нюансы, не позволяющие применить такой подход, но в общем будет работать.
Правда ходить по этим адресам через ВПН будет не только эта программа, но и другие, которым может быть то же понадобятся эти же адреса.
Quqas, 128 маска - это минимально возможная маска для IPv6, это P2P грубо говоря и в этой сети только 1 хост.
Левые (придуманные) адреса не будут правильно маршрутизироваться в интернете, а следовательно не приведут к твоей сети через твоего провайдера.
Соответственно вариантов не много:
1. внутри сети использовать любой диапазон локальных IPv6 адресов и через NAT выводить их наружу. NAT будет заменять локальные адреса, на единственный внешний адрес.
2. договориться с оператором: арендовать IPv6 подсеть и уже в рамках этой подсети назначать адреса хостам в своей локальной сети. Тогда можно обойтись без NAT, но это скорее всего за деньги.
В целом все примерно так же как в IPv4. Видимо оператор тебе выдает только 1 адрес потому что это ВПН и
Василий Банников, Про установленный офис я писал, винда - вытекает из установленного офиса.
На счет медленно - вопрос спорный, я не замерял. Лично я использовал для каких-то мелких задач лет 15 назад и не на С++, вполне хватало скорости. Как оно сейчас работает не в курсе, вряд ли медленнее стало.
mingw в данном случае не помеха, т.к. интерфейс к COM объектам предоставляет ОС и он не зависит от используемого компилятора.
В целом я не настаиваю. Просто предложил альтернативный вариант, доступный из коробки (зависимость от офиса в данном случае не считаю проблемой, т.к. ТСу нужно работать с xls файлами, а значит офис и винда у него точно есть). Все недостатки тут уже хорошо описали. Выбор за ТС.
Adamos, В целом согласен, но если надо быстро закрыть какую-то задачу, то почему бы и нет.
К тому же я не предлагал изучать технологию, пользоваться этим достаточно просто. Писать свои объекты - это совсем другое и сейчас не нужно этого делать.
MS Excel/Word (и наверное и другие продукты из состава MS Office) предоставляют ActiveX объекты, которые могут быть использованы напрямую без всяких библиотек, любыми языками умеющими в ActiveX. А С++ это умеет, потому что собственно винда умеет и предоставляет соответствующие интерфейсы.
Так что можете покопать в этом направлении.
Для затравки можно, например, попробовать написать что-нибудь легкое с использованием Excel ActiceX объектов на скриптовых языках VBS или JS (интерпретатор есть в винде из коробки - cscript/wscript), для понимания как с ним вообще работать, потом это можно будет адаптировать на С++, если останется желание. Просто в VBS/JS работать с ActiveX объектами очень просто, в С++ будет немного сложнее.
Этот подход, естественно, требует установленного Excel на компе.
Технология ActiveX уже старая и подзабытая, нынче не особо модная, но это не значит, что она не работает.
Простейший батник с вызовом robocopy/xcopy внутри.
Чтоб каждый раз не тянуть весь объем, используйте копирование с учетом атрибута "архивный" - когда файл изменяется атрибут автоматически устанавливается и xcopy/robocopy скопируют файл и сбросят атрибут (если используются соответствующие опции).
Так же можно копируемые файлы предварительно архивировать, тот же 7z, по моему, умеет работать с атрибутом "архивный".
1. Какой размер исполняемого файла запускаемого процесса? Если большой, то при загрузке могут быть тормоза. Но по идее повторный запуск уже должен быть быстрее (если файл влазит в кэш ОС)
2. Как замеряли время? Конкретно время выполнения CreateProcess() или всего приложения?
3. Предполагаю, что висит у вас на выполнении WaitForSingleObject() - это единственное место, где в коде происходит ожидание. Попробуйте тут поэкспериментировать, напримре, вместо INFINIT задать какое-то мелкое время или вообще не ждать.
Похоже в коде на go, не происходит ожидание завершения дочернего процесса.
Это избавит вас от малопонятных на данном этапе ошибок, связанных с разными платформами и компиляторами.