brar, Какая разница, дает он ответы от ИИ или из головы, если ответ правильный?
Если не правильный - есть смысл закидать тухлыми яйцами хоть человека хоть ИИ, но аргументируя. Аргумент - "это копипаст ИИ" - не аргумент.
Я плохо разбираюсь в железе. Но ошибка if(type=0) явно присутствует. Об этой ошибке должен и современный компилятор сообщать в предупреждениях (при включенной опции -Wall). По остальным ошибкам в ответе Андрюха Фростморн судить не берусь.
Кирилл Ларченко, Вообще рекомендую как минимум опции -Wall -Wextra всегда использовать при сборке и добиваться сборки без предупреждений. Можно дополнительно использовать -Werror что переведет все предупреждения в разряд ошибок. Коротенько тут описаны основные регулировки предупреждений компилятора: https://habr.com/ru/articles/490850/
Помимо компилятора подобную ошибку заметит любой статический анализатор. Ну и адекватный ИИ то же должен бы ее увидеть - это довольно простая и часто встречающаяся ошибка.
Единорог Безрогов, Работоспособность батарейки проще всего проверить по часам ПК. Когда батарейка села или не работает после каждого выключения ПК из сети часы сбрасываются и начинают показывать дату что-то типа - 01.01.1970 (тут могут быть другие варианты). Если часы не сбрасываются - батарейка норм.
Согласен с Zerg89 - скорее всего после чистки шлейф SATA подключили к другому порту, вероятно из-за этого порядок загрузки и поменялся.
Удалите все не используемые разделы с HDD, чтоб больше не было такой путаницы. Освободившееся пространство диска можно и не объединять с другими разделами, если не охота с этим заморачиваться (это не всегда можно быстро сделать штатными средствами). Обычно раздел UEFI и прочие "служебные" разделы винды не большие.
Включить pagefile идея годная.
Но это лишь даст возможность процессу, отжирающему память, отжирать ее еще больше. Предел может наступить и с включенным файлом подкачки, но позже.
Судя по постоянному увеличению измененной памяти, в каком-то приложении может быть утечка памяти. После включения файла подкачки стоит понаблюдать за его использованием, если оно будет постоянно расти, то это наверняка утечка. И с этим надо будет что-то делать.
Надо выяснить в каком приложении течет память (какое приложение ее потребляет больше всего, а так же какое приложение будет потреблять больше всего файла подкачки). Правда шансов что-то исправить в этом плане без поддержки разработчиков приложения мало, т.к. это их ошибка. По крайней мере можно стукнуть в поддержку этого приложения или обновиться (вдруг поможет).
В стандартном виндовом менеджере задач можно добавить нужные столбцы на вкладке "Details" и по ним сортировать - так можно найти процесс виновник достаточно быстро.
Drovosek01, Скорее всего опции компилятора все таки различаются, cmake может от себя еще что-то добавить, помимо того, что написал ему ты.
У cmake есть опция, с помощью которой можно выводить командную строку компилятора со всеми итоговыми ключами:
set(CMAKE_VERBOSE_MAKEFILE ON)
Добавь ее в cmakelists где-нибудь в начале или передавай через командную строку и после сборки можешь увидеть команды, которые выполняет cmake build.
Кот Абсолютный, В свое время ставил сертификат на Windows Server RDP с собственного ЦС без проблем.
Там были какие-то тонкости (связанные, кажется, с использованием сертификата - надо было правильно выставить в запросе), но все решалось легким гуглежом.
Это было еще во времена WIn Server 2008/20012. Сейчас давно уже не в теме.
На Letsencrypts, скорее всего, за бесплатно подходящий сертификат не дадут, но за деньги, думаю, что можно в любом ЦС выпустить правильный.
Это стандартное сообщение при проверке сертификата RDP сервера. Обычно на RDP сервере используется самоподписанный сертификат, который, конечно никакие проверки не проходит.
Это сообщение было всегда, возможно оно немного видоизменилось в новой версии, не более того.
Раньше внизу была галка, что-то типа "сохранить выбор" или "всегда доверять этому сертификату", формулировку не помню, нажимаете ее в первый раз и далее уже не будет этих вопросов.
На вашем скрине этой галки нет. Вероятно это и есть происки последнего обновления. У себя на винде, каких-то изменений в этом плане не замечал, вроде бы все как обычно. Но возможно, ко мне еще не все обновления прилетели.
Как вариант, при обновлении в винду добавили/изменили значение какой-то групповой политики, влияющей на возможность сохранения сертификатов и галка перестала отображаться в окне. Если политику отменить - то она снова появиться. Не знаю, существует ли такая политика, это в качестве гипотезы для дальнейшего исследования.
Но можно и без галки. Есть несколько вариантов, которые приходят в голову сразу:
1. использовать на сервере официальный сертификат, подписанный широко известным ЦС, например Letsencrypt и т.п.
2. Развернуть собственный корпоративный ЦС, выдать в нем сертификат для RDP сервера, на всех клиентах установить сертификат ЦС в хранилище "доверенные корневые ЦС", тогда сертификат сервера будет проходить проверку успешно.
3. Извлечь самоподписанный сертификат сервера, раздать его клиентам, чтоб они так же установили его в "доверенные сертификаты".
По последнему варианту - стандартный виндовый RDP клиент сохраняет сертификаты серверов в реестре. Но не уверен, что при отсутствии вышеописанной галки он это делает, надо проверять. Из реестра теоретически можно экспортировать сертификат и установить его в хранилище сертификатов. Так же, если есть доступ к RDP серверу, то сертификат можно извлечь на нем и раздать клиентам.
Распространение сертификатов на клиентские устройства - это не дыра в безопасности, этот же сертификат вы в любом случае получаете при установке RDP подключения, а так же в сертификате содержиться открытый ключ, который и так предназначен для распространения между пользователями.
#N1Q0LE, Десктопная винда в принципе не так что бы слишком дорого стоит, любой работающий может себе позволить, если захочет.
К тому же обычно, если покупаешь комп с предустановленной виндой, то она уже активирована по умолчанию, и ты за нее заплатил в чеке за комп, даже если об этом тебе не сказали.
И потом, если форматируешь диск и переустанавливаешь винду, то лицензия подхватывается (если подходит для вновь установленной версии) - ключ сохраняется в постоянной памяти БИОС, поэтому форматирование диска его не удаляет.
Анализ дампа вам вряд ли бы помог, даже если бы вы его сделали во время. В лучшем случае можно было бы вычислить виновника падения и избавиться от этого софта, но это можно сделать и другими способами.
У меня было несколько раз, когда я пытался анализировать дамп винды по горячим следам. Но все разы сам анализ мне довести до конца не удалось (уж больно муторное это занятие и без навыков довольно сложное) и проблемы так или иначе решались другим способом.
Дамп, возможно, пригодился бы для не большой части проблем, которые без разработчиков обычно решить не возможно. Но помог бы он разработчику, а не вам.
На данный момент не работает уже ни один мой впн, я бы может и настроила сама, но нет доступа к тг и ключам.
Что имеете ввиду под "мой впн" - ВПН который вы купили у кого-то? Это не ваш впн, это их впн. Вы же в этом случае почему то не опасались, что у вас кто-то может личные данные перехватить. Если так, то ваш впн и впн вашего друга ничем не отличаются принципиально, разве что контора, которой вы раньше платили за впн, лично к вам никакого интереса, теоретически, не имеет (кроме того, чтоб вы исправно платили за их услуги) и не будет заморачиваться с перехватом.
Если же вы действительно настраивали ваш впн самостоятельно, то вопросов с доступом к "тг и ключам" не должно возникать. Настраиваете впн, ключи, если надо, генерируются новые и далее используются, телеграм начинает работать через настроенный впн, если конечно повезет и ваш новый впн еще не блокируют.
На мой вкус в вузах по проще специальность "прикладная математика и информатика" не дает почти ничего - базовые навыки и в том и в другом.
В вузах по серьезней уже могут быть варианты, надо смотреть программу.
Математика - вполне подходящий вариант для дальнейшего развития в программировании, т.к. настраивает мозги в правильном направлении, правда для этого надо учиться. По крайней мере тут даже в вузах по проще есть надежда, что чему то научат.
Или выбирайте ИТ факультет более специализированный, чем "прикладная информатика".
Много чего может пойти не так. Затея достаточно опасная. Особенно, если подобным же образом будете работать и с другими типами или в дальнейшем будете модифицировать тот же Time. Не известно, какие в дальнейшем будут потребности для этих типов, а подобным использованием вы сужаете себе рамки модификации типов.
Обложите эту строчку ассертами с проверкой размера и выравнивания типа, это по крайней мере вызовет явную ошибку, когда будет потенциальная ситуация чему-то пойти не так.
Я бы в Time определил конструктор и оператор присваивания, принимающие double.
Dyikot, Тем хуже.
Предположение с выходом за границу буфера в силе.
Вероятен еще вариант не порчи соседних переменных, а чтения чужих или мусорных данных за границей буфера и использования их в расчете. Это могло бы объяснить разные результаты по одним входным данным, т.к. "мусор" - может быть все время разный.
Например стековая переменная вы выходите за границу переменной и читаете какую-то область на стеке - т.к. стек выделен весь, то SIGFAULT не будет - можно и читать и писать. Только что в итоге получится - не предсказуемо. Ну вот и у вас как-то так получается. Такая же ситуация может быть и с динамической памятью и со статической.
По непонятным причинам результаты могут быть другими.
Если имеются ввиду разные результаты по одним и тем же входным данным, то да, есть проблема.
Если же входные данные разные, то вполне вероятно ожидать и разных результатов. По моему так? Не дурно было бы просчитать результаты другим способом, чтоб знать результат наверняка и уже сравнивать с ним, как с эталоном.
То что программа в Debug и Release сборке ведет себя по разному - свидетельствует об ошибках. Скорее всего где-то выход за границу буфера с порчей соседних переменных. Довольно часто встречающаяся ошибка.
Часто компиляторы в Debug сборках добавляют паддинги вокруг переменных для собственных целей, они могут предотвращать порчу соседних переменных.
Погоняйте под valgrindом или другим анализатором. Но это может и не дать результата, тогда только анализ кода поможет.
Dyikot, Что да? При чем тут постоянная задержка?
Я просто описываю механизм с помощью которого мне удавалось делать в потоке достаточно точные не большие паузы.
У меня там не было фиксированной задержки. Задача была добиться пробуждение потока каждую 1мс с желательно равными промежутками времени, при этом еще учитывалось время работы самого потока (он же не моментально отрабатывает) и таймаут следующего пробуждения рассчитывался каждую итерацию с учетом затраченного на работу потока времени. Поэтому реальный таймаут, передаваемый в кондвар был меньше 1 мс.
Dyikot, Никаких особых чудодейственных средств в библиотеках нет, SDL_DelayNS использует что-то, предоставляемое системой.
На линуксе, мне доводилось укладываться по задержкам в 1 мс (+-несколько сот мкс), на высокоприоритетном потоке с RT планированием. Поток должен был просыпаться каждую 1 мс и делать свое черное дело. Ждал на кондваре, т.к. там по мимо пробуждения по таймауту могли быть и другие асинхронные события, которые будили поток.
На десктопных операционках квант времени, выдаваемый потоку (процессу) на работу до его вытеснения 1-10 мс. После истечения кванта поток вытесняется с выполнения ядром ОС. В линуксе, вроде бы, квант времени может быть плавающий, начинает с 10 мс и, если нужно, может уменьшаться вплоть до 1 мс.
Ваши 8 мс вполне укладываются в это ограничение. Если в данный момент времени в системе есть другие потоки, готовые работать, то такие задержки это нормально и я бы вообще не ожидал лучшего результата с применением таймеров (или sleepа того же) и загруженной системе.
Как-то поправить положение, можно, например выделив для этой задачи отдельный высокоприоритетный поток. В линуксе этому потоку так же можно задать Realt-Time планирование с повышенным приоритетом - в этом случае все типичные потоки с "общим" планированием будут менее приоритетны. В винде не знаю, есть ли подобные фишки, но приоритет то поднять точно можно. Еще как вариант привязать поток к одному ядру процессора - теоретически это может улучшить работу с кешем процессора. Обычно, так делают, при интенсивном обмене сетевым трафиком. В линуксе можно указать affinity для конкретного сетевого адаптера и если процесс в user space, который работает с этим адаптером, будет так же работать на этом же ядре, то будет неплохой буст в производительности. Поможет ли это вам, сказать трудно, надо проверять.
В целом идея Mercury13 с засечкой времени и проверкой в нужных местах мне нравится. Сам так иногда делаю в подходящих ситуациях. Но в этом случае ваш поток должен что-то делать во время активного ожидания. Если ему заняться не чем, то можно повисеть на condvarе с таймером. Читал, что в кондваре несколько другой механизм используется, чем в таймерах и тех же sleepах, правда это относилось к линуксу. И кондвар может быть более отзывчивым из-за этого. Так же видел проекты с применением этой идеи, где были реализованы собственные таймера с ожиданием на кондваре.
Но это я все про вариант без корутин, с обычной асинхронщиной. Как это все ложиться на корутины сказать не могу.
Миллисекундные задержки - это все таки мягкое реальное время, в жестком в микросекундах считают задержки и там уже совсем другие ОС. Что касается стандартных десктопных ОС (линукс и винда), то они ни разу не Real-Time и ожидать от них RT поведения не стоит. В Линуксе еще можно использовать ядро с RT_PREEMPT патчем, который делает линукс немного более Real-Time, но это уже не обычное ядро, этим надо специально заморачиваться.
RT ОСь отличается от не RT тем, что в RT четко определенные задержки для всех операций. В винде и линуксе, если ядро, например, начнет что-то подкачивать из файла подкачки, то задержки легко могут увеличиться в несколько раз. Файл подкачки в этом случае - это просто как пример того чем может быть занята ОСь, когда не дает работать вашей задаче.
Если не правильный - есть смысл закидать тухлыми яйцами хоть человека хоть ИИ, но аргументируя. Аргумент - "это копипаст ИИ" - не аргумент.
Я плохо разбираюсь в железе. Но ошибка if(type=0) явно присутствует. Об этой ошибке должен и современный компилятор сообщать в предупреждениях (при включенной опции -Wall). По остальным ошибкам в ответе Андрюха Фростморн судить не берусь.
Кирилл Ларченко, Вообще рекомендую как минимум опции -Wall -Wextra всегда использовать при сборке и добиваться сборки без предупреждений. Можно дополнительно использовать -Werror что переведет все предупреждения в разряд ошибок. Коротенько тут описаны основные регулировки предупреждений компилятора: https://habr.com/ru/articles/490850/
Помимо компилятора подобную ошибку заметит любой статический анализатор. Ну и адекватный ИИ то же должен бы ее увидеть - это довольно простая и часто встречающаяся ошибка.