Это у вас какая-то "нечеткая логика". Тут батник вам не поможет, нужен инструмент серьезней.
Но если бы вы как-то упростили задачу без этих заворотов, то можно было бы и на батниках реализовать.
Например: все файлы содержащие Сидоров складывать в одноименную папку находящуюся по такому-то пути, перечень фамилий (частей файлов) находится в конфигурационном файле. В конфигурационном файле можно не только список частей файлов положить, но и на каждую часть указать в какую папку складывать файлы.
Но если завершаю работу как обычно через пуск, то светодиоды на сетевой тухнут и естественно WoL уже не работает.
Это странно. В свое время экспериментировал с WoL все работало нормально независимо от того как выключал винду. Возможно это у вас какие-то особоенности поведения материнской платы. Попробуйте посмотреть инструкцию по ней в плане настройки WoL.
Владислав Детров, Я использовал раньше Eclipse - нормальная среда, все что надо есть, есть плагины. Но написана на Java в связи с чем временами начинает тормозить, видимо когда GC в JAVA включается.
Поэтому сейчас пересел на qtcreator - работает стабильно и быстро, радует умение работать с cmake проектами. Написан на С++, поэтому таких болезней как у Eclipse с производительностью нет.
Владислав Детров, Я бы рекомендовал все таки вернуться к qtcreator - это очень хорошая IDE на сегодняшний день. Если вы сидите на винде, то есть смысл использовать MSVS, но qtcreator - "универсальней". Code:blocks не обновлялся с 2017 года, похоже что проект умирает.
На самом деле IDE - вторична, вам все равно потребуется понимать суть происходящего. IDE скрывает какие-то моменты. Если вы уже знаете как внутри все работает, то IDE вам поможет, если только начинаете - IDE в некоторой степени мешает, упрощая процесс. Но вы не всегда сможете использовать любимую IDE и знание процессов, которые скрывает IDE, поможет вам быстро приспосабливаться к новым условиям.
Многие пишут код в обычных текстовых редакторах. Например многие "гуру" используют vim или emacs, с некоторым набором плагинов.
Егор Лепихин, Будут конкретные вопросы, можете задавать тут или оформить отдельным вопросом. Тут есть хорошие спецы по С/С++, которые многое могут сказать.
А вот что получается, когда я пытаюсь изменить опции компилятора:
Что вы хотите этим показать? Опции компилятора нигде не сохраняются. Бесполезно вот так вот запускать компилятор - после завершения работы все ранее указанные опции будут успешно забыты. У каждого вызова компилятора свой собственный набор опций, указанный при текущем запуске компилятора.
После правки pro файла нужно пересобрать проект (очистить и собрать все заново).
Посмотрите окно вывода компилятора, там могут отображаться команды запускаемые qmake для сборки проекта, в т.ч. и запуск gcc (или g++) и там можно увидеть полную командную строку с которой запускается компилятор.
После того как вы добавили CONFIG+=debug в параметрах компилятора должна появиться опция -g и еще видимо что-нибудь.
Все эти параметры в pro файле типа CONFIG и прочего в конце концов преобразуются в разные наборы опций компилятора и линковщика.
pro файл используется в системе сборки qmake, она создавалась для сборки Qt проектов, но может использоваться и без Qt. Подобных систем сборки много. qtcreator поддерживает еще работу с cmake системой сборки, достаточно популярная сейчас. Наиболее часто используемая в разных проектах (а так же древняя, тормознутая и не слишком удобная) это make и ее makefile.
Все системы сборки предназначены только для того что бы в итоге запустить компилятор, а затем линковщик с нужным набором опций. На самом деле они много чего другого могут запускать, но это вам сейчас не важно.
1.Опубликуйте в вопросе код батника в соответствующем теге.
2.Выложите лог ошибок выполнения: закоментируйте первую строку батника и выполните его с перенаправлением вывода в файл таким образом: batch_name.bat 1>file.log 2>&1
где batch_name.bat - имя батника, подставьте свое имя фала, в который вы сохраните код
file.log - имя создаваемого файла, который будет содержать весь вывод батника.
В file.log найдите ошибку и так же опубликуйте ее в вопросе.
Сейчас ваш вопрос похож на задание. А это делают фрилансеры за деньги. Тут люди помогают с решением проблемм бесплатно.
Егор Лепихин, SensorValue newSensorValue;
Вот этот код выделяет на стеке память под структуру. Размер выделенной памяти sizeof(SensorValue). На самом деле вся память в стеке уже выделена и фактически происходит просто увеличение (уменьшение) указателя стека на размер выделяемой памяти.
После выхода из sendValue вся память выделенная в ней под внутренние (локальные) переменные освобождается, т.е. указатель стека изменяется в обратную сторону. Если после этого в вызывающем sendValue коде будут вызываться другие функции или создаваться новые локальные переменные, то они будут тиспользовать уже осовбожденную при выходе из sendValue память. Таким образом память, занимаемая ранее структурой перезапишется другим содержимым.
После уничтожения структуры сохраненные ранее указатель на нее становится не действительным.
По факту он будет указывать на то же место в памяти, где когда-то была структура, но к тому времени когда вы решить воспользоваться этим указателем в этом участке памяти будет лежать уже что-то другое.
Когда вы сохраняете указатель куда-то, вы просто сохраняете целое число (указатель - это просто целое число означающее адрес переменной в памяти). Сами данные при этом никуда не перемещаются. Поэтому если вы попытаетесь разъыменовать указатель (обратится к памяти на которую ссылается указатель) после того как переменная на которую ссылается указатель уничтожена у вас получается UB (undefined behavior).
Если бы вы работали под нормально ОС и таким образом обратились бы к динамической памяти то у вас вылетела бы программа с SEGFAULT. Обращение же к стеку к SEGFAULT не приводит как раз по тому, что реально память под стеком всегда выделена и всегда действительна. Но вот данные по одному адресу в стеке в разные моменты времени могут быть совершенно разными.
В общем, тему указателей и работы с памятью вы не освоили. Почитайте что-нибудь, без понимания этого в микроконтроллерах делать нечего. Да и не только это, усвойте чем отличаются локальные (автоматические) переменны, динамические и статические друг от друга. К этому перечню в С++17 добавились еще inline переменные.
Как павильно заметил WinPooh32 работа с памятью одинакова на любых платформах, указатели работают одинаково. Так что можете тренироваться на винде или линуксе.
Дополню:
После выхода из sendValue все локальные переменные уничтожаются. Тот факт, что вы сохранили адрес локальной переменной никакой роли не играет. Последующие вызовы функций или создание переменных затрут то место на стеке, где когда-то у вас была размещена структура SensorValue, когда работала функция sendValue.
Владислав Детров, Можно в интернете найти, например. Или gcc --help запустить.
Опций у него вагон и маленькая тележка.
По всем подобным вопросам информация прекрасно ищется в интернете, т.к. программисты новички все всегда ходят по одним и тем же граблям.
Погуглил за вас: https://doc.qt.io/archives/qt-4.8/qmake-tutorial.html
Добавьте в pro файл такую строчку:
CONFIG += debug
Если CONFIG уже у вас есть, то просто в конец допишите debug.
Metalhaker97, Не знаю, что вы имеете ввиду под системным журналом. Обычно никто не хранит информацию о проходящем трафике по каждому пакету, т.к. трафика очень много и это даже на взрослом сервере ресурсозатратно, что уж говорить о маленькой железке. Это я к тому, что в системном журнале и не должно быть такой информации в принципе.
Я писал про диагностические инструменты, аналог tcpdump (это линуксовая, которая позволяет смотреть, что проходит у вас на сетевом интерфейсе). Бывает, что какой-то подобный функционал встраивают в роутеры. Что есть в вашем, я не в курсе.
Напишите какая конкретно модель роутера у вас используется, тогда можно будет документацию посмотреть.
Jekson, Не совсем. Вы спокойно делаете новую ветку от предыдущей фичи. После того как предыдущую фичу примут, есть смысл вкачать develop себе и ребазировать новую фичу на актуальный develop.
На самом деле перед пушем фичи всегда есть смысл обновить develop и ребазировать фичу на последний develop и только потом пушить. Тогда вы уменьшите вероятность конфликтов при мерже.
SergeySafaryanc, Посмотрите ответ Сергей Паньков, его вариант более простой, чем то что я предложил.
Впрочем причину того, почему у вас не работает cross join я изложил верно.
Metalhaker97, Посмотрите, что на роутере есть из диагностических инструментов. Если там есть аналог tcpdump попробуйте посмотреть что все таки приходит на роутер.
Metalhaker97, Галочка теоретически может влиять только на LAN порты. Тут надо подробней изучать железку. Я дела с ТР-линками не имел.
И у любого пинга есть минимум 2 стороны, на любой могут работать фаерволы.
То что пинг идет в сеть 192.168.0 не говорит о том, что пинг в сеть 10.100.1 не блокируется. Но это говорит о том, что даже не смотря на то что пинг до роутера не проходит, но сеть все равно работает и связь с роутером есть :-)
Особых проблем со зрением нет. Могу почитать книгу вечером, но редко получается по другим причинам - прогулки и спорт то же отнимают много времени, да и с семьей надо пообщаться :)
Все советы правильные. Спорт, прогулки и т.п. - для поддержания общего тонуса. Если не вылазить из-за компа дальше кровати, то можно свихнуться.
Попробуйте взять другой монитор, настроить яркость и/или контрастность, изменить посадку, увеличить освещение рабочего пространства, перейти на темные цветовые схемы.
Metalhaker97, Были бы открыты - пинговалось.
Т.к. пинги с циски в сеть за роутером идут, значит по настройкам все нормально и сеть функционирует.
Значит где-то блокирует фаервол конкретные пакеты (icmp echo request/response). Возможно блокируется на циске, а не на роутере.
Вообще циска и роутер находятся в одной сети и какой-то специальной настройки для доступа внутри сети 10.100.1.0 не требуется. Что еще раз подтверждает, что где-то пинги блокируются фаерволом, а так как тут нет промежуточных шлюзов, то вариантов всего 2 - блокируется на роутере или на циске.
Если есть возможность, включите на роутере журналирование фаервола, запустите пинг и посмотрите, что он будет блокировать. Если пинги вообще не приходят - блокирует циска.
Temp-User_0000, Мне приходится иметь дело с сильно географически разнесенными ВПН клиентами. Скорости бывает проседают, пинг всегда низкий. В таких условиях ВПН на TCP еле жив, при удаленной работе - заметные не вооруженным взглядом лаги. При этом на UDP все работает вполне сносно. Если же по каким-то причинам качество связи еще больше проседает (что временами случается), то TCP просто умирает, тогда как на UDP появляются терпимые в этом случае лаги. Но приходится держать и TCP, т.к. некоторые клиенты не могут использовать UDP по не зависящим от них причинам.
Это у вас какая-то "нечеткая логика". Тут батник вам не поможет, нужен инструмент серьезней.
Но если бы вы как-то упростили задачу без этих заворотов, то можно было бы и на батниках реализовать.
Например: все файлы содержащие Сидоров складывать в одноименную папку находящуюся по такому-то пути, перечень фамилий (частей файлов) находится в конфигурационном файле. В конфигурационном файле можно не только список частей файлов положить, но и на каждую часть указать в какую папку складывать файлы.