А макрос типа container_of из Си, он не стандартный, но часто используется в разных проектах.
Container_of использовать для преобразования T* в RefMemoryBlock*, а затем от него уже в RefMemoryBlockBase* стандартным кастом. На плюсах containter_of будет выглядеть как-то так:
У вас его использовать так: container_of(data, RefMemoryBlock , Value);
На выходе будет RefMemoryBlock*.
При желании его можно переписать на шаблонах, чтоб избавиться от макросов.
Использовать container_of будет безопаснее, т.к. в этом случае компилятор сам учтет нужное смещение от Value для вычисления RefMemoryBlock*, а затем и RefMemoryBlockBase*.
Может стоит использовать shared_ptr для счетчиков ссылок?
Кажется strict aliasing тут не при делах. Какая у вас ошибка при сборке возникает?
В вашем коде я вижу другие проблемы. Я бы не стал тут использовать наследование, т.к. начинаются зависимости от компилятора - как он расположет данные базового класса относительно данных потомка? Плюс появляется таблица виртуальных методов - где указатель на нее лежит до или после базового класса? В итоге арифметика преобразования указателя может быть не такой простой, как у вас. А какой она должна быть мы не знаем.
Если хотите идти по этому пути, то делайте RefMemoryBlockBase и RefMemoryBlock максимально простыми, вместо наследования используйте агрегирование, избавьтесь от виртуальных методов.
В целом идея вполне рабочая. Тот же подход используют для реализации интрузивных контейнеров, можете поискать что-нибудь подходящее и посмотреть как там это реализуют. Например что-нибудь из boost.intrusive.
Любой файл имеет какой-то формат. Для работы с файлом нужно иметь описание формата.
Дальше уже дело техники, используя стандартные функции Си (или ОС) для работы с файлами, открыть файл и изменить то что нужно изменить в соответствии с форматом.
Для обычных структур не нужно играть с выравниванием, т.к. "упаковка" структуры сделает доступ к ее полям более медленным.
Кстати, далеко не во всех процессорах поддерживается доступ к не выровненным данным. Но самые популярные это, конечно, уже освоили. Например некоторые микроконтроллеры будут вываливаться в ошибку при невыровненном доступе.
Чаще всего будешь сталкиваться с невыровненным доступом при чтении/записи файлов или приеме/передачи данных по сети. Поэтому обычно в этих случаях требуется процедура сериализации/десериализации.
Сама структура так же имеет свое выравнивание - обычно оно равно самому большому выравниванию её членов. Но могут быть нюансы, как обычно, но это, скорее всего, уже довольно специфические случаи.
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, Десктопная винда в принципе не так что бы слишком дорого стоит, любой работающий может себе позволить, если захочет.
К тому же обычно, если покупаешь комп с предустановленной виндой, то она уже активирована по умолчанию, и ты за нее заплатил в чеке за комп, даже если об этом тебе не сказали.
И потом, если форматируешь диск и переустанавливаешь винду, то лицензия подхватывается (если подходит для вновь установленной версии) - ключ сохраняется в постоянной памяти БИОС, поэтому форматирование диска его не удаляет.
Анализ дампа вам вряд ли бы помог, даже если бы вы его сделали во время. В лучшем случае можно было бы вычислить виновника падения и избавиться от этого софта, но это можно сделать и другими способами.
У меня было несколько раз, когда я пытался анализировать дамп винды по горячим следам. Но все разы сам анализ мне довести до конца не удалось (уж больно муторное это занятие и без навыков довольно сложное) и проблемы так или иначе решались другим способом.
Дамп, возможно, пригодился бы для не большой части проблем, которые без разработчиков обычно решить не возможно. Но помог бы он разработчику, а не вам.
На данный момент не работает уже ни один мой впн, я бы может и настроила сама, но нет доступа к тг и ключам.
Что имеете ввиду под "мой впн" - ВПН который вы купили у кого-то? Это не ваш впн, это их впн. Вы же в этом случае почему то не опасались, что у вас кто-то может личные данные перехватить. Если так, то ваш впн и впн вашего друга ничем не отличаются принципиально, разве что контора, которой вы раньше платили за впн, лично к вам никакого интереса, теоретически, не имеет (кроме того, чтоб вы исправно платили за их услуги) и не будет заморачиваться с перехватом.
Если же вы действительно настраивали ваш впн самостоятельно, то вопросов с доступом к "тг и ключам" не должно возникать. Настраиваете впн, ключи, если надо, генерируются новые и далее используются, телеграм начинает работать через настроенный впн, если конечно повезет и ваш новый впн еще не блокируют.
На мой вкус в вузах по проще специальность "прикладная математика и информатика" не дает почти ничего - базовые навыки и в том и в другом.
В вузах по серьезней уже могут быть варианты, надо смотреть программу.
Математика - вполне подходящий вариант для дальнейшего развития в программировании, т.к. настраивает мозги в правильном направлении, правда для этого надо учиться. По крайней мере тут даже в вузах по проще есть надежда, что чему то научат.
Или выбирайте ИТ факультет более специализированный, чем "прикладная информатика".
А макрос типа container_of из Си, он не стандартный, но часто используется в разных проектах.
Container_of использовать для преобразования T* в RefMemoryBlock*, а затем от него уже в RefMemoryBlockBase* стандартным кастом. На плюсах containter_of будет выглядеть как-то так:
У вас его использовать так:
container_of(data, RefMemoryBlock , Value);На выходе будет RefMemoryBlock*.
При желании его можно переписать на шаблонах, чтоб избавиться от макросов.
Использовать container_of будет безопаснее, т.к. в этом случае компилятор сам учтет нужное смещение от Value для вычисления RefMemoryBlock*, а затем и RefMemoryBlockBase*.