Но ведь “объект” в C++, согласно стандарту, это лишь экземпляр любого типа, включая фундаментальные, пришедшие из Си, а на первых страницах стандарта написано, что Си является подмножеством C++, со всеми вытекающими (хоть и с некоторыми ограничениями).
Я понимаю, что ООП и перегрузка операторов позволяют изменять поведение объекта, но как это может сказываться на “конвертации” бит в бит? Почему нельзя отдать это на откуп разработчику, по принципу “сам накосячил — сам дурак”? Какой тайный смысл во всех этих искусственных ограничениях?
Меня всегда интересовал вопрос: Чем руководствовались писатели стандарта C++, когда писали про common sequence initialization для union? Кому могла прийти в голову мысль, что другие члены объединения могут быть проинициализированы только в том случае, если их компоновка в точности совпадает с компоновкой самого длинного, инициализируемого напрямую члена? При том, что эти люди прекрасно осведомлены о применении union множеством библиотек в runtime для конвертации представлений чисел бит в бит! Почему нельзя было оговорить тоже самое для constexpr, параллельно устранив сложности реализации того, что понаписано в стандарте?
Ключи ассиметричного алгоритма шифрования, например RSA, являются равноправными (т.е. любой ключ из ключ-пары может расшифровать то, что зашифровано другим ключом из той же ключ-пары), а "закрытый ключ" и "открытый ключ", это лишь условности в рамках инфраструктуры открытых ключей (PKI). В рамках упомянутой инфраструктуры закрытый ключ служит для шифрования дайджеста сообщения (aka hash-value или fingerprint), что и является электронно-цифровой подписью сообщения.
Метод простой подстановки, при шифровании достаточно больших текстов (приблизительно от сотни слов и больше), не является криптостойким и ломается простой статистикой по частоте букв в словах для конкретного языка.
В цифровой подписи открытый ключ из сертификата служит для расшифровки дайджеста сообщения, зашифрованного закрытым ключом, что, собственно и является электронно-цифровой подписью.
Просто на планете арахнидов американцы в большом количестве обнаружили крайне ценные полезные ископаемые, до которых самим арахнидам нет никакого дела, но зато арахнидам есть дело до прилетевшей к ним с другой планеты еды. :)
Конечно GNUC компилятор (g++) знает, что constexpr выражение создаётся из неинициализированного по common sequence initialization члена объединения реализованного как constexpr, а потому выдаёт подобную ошибку: error: accessing ‘<alpha>’ member instead of initialized ‘<omega>’ member in constant expression
Меня всегда интересовала мотивация разработчиков стандарта и компиляторов, по которой принимаются те или иные, весьма сомнительные решения.
Пожалуйста, поясните поподробнее про те бреши в безопасности, которые открывают объединения. До сих пор до конца не понимаю — чем мотивировались разработчики стандарта C++, запрещая доступ через неинициализированный член к данным constexpr объединения, инициализированных через другой член объединения. В чём именно опасность?
В популярных дистрибутивах Linux нет Zygote, а вызов fork() есть! В операционной системе Windows, где каждый процесс изолирован, но процессы разделяют общее ядро, нет ни Zygote, ни вызова fork(), а "клонирование" ядра есть. Хотя, в реальности никакого клонирования там нет, а есть лишь разделение процессами одних и тех же, доступных на чтение страниц памяти, принадлежащих ядру Windows.
Так что, Zygote, не потому, что fork(), а потому что основа для разных процессов с разделяемыми через общие страницы памяти этих процессов библиотеки.
«И говинда ваша ничего. Жидковата, но ничего. Пойдёте в химвойска» © ДМБ
Но ведь “объект” в C++, согласно стандарту, это лишь экземпляр любого типа, включая фундаментальные, пришедшие из Си, а на первых страницах стандарта написано, что Си является подмножеством C++, со всеми вытекающими (хоть и с некоторыми ограничениями).
Я понимаю, что ООП и перегрузка операторов позволяют изменять поведение объекта, но как это может сказываться на “конвертации” бит в бит? Почему нельзя отдать это на откуп разработчику, по принципу “сам накосячил — сам дурак”? Какой тайный смысл во всех этих искусственных ограничениях?
Очень просто выработать! Логарифм, это функция показателя степени по основанию от результата. Коротко и просто!
Меня всегда интересовал вопрос: Чем руководствовались писатели стандарта C++, когда писали про common sequence initialization для union? Кому могла прийти в голову мысль, что другие члены объединения могут быть проинициализированы только в том случае, если их компоновка в точности совпадает с компоновкой самого длинного, инициализируемого напрямую члена? При том, что эти люди прекрасно осведомлены о применении union множеством библиотек в runtime для конвертации представлений чисел бит в бит! Почему нельзя было оговорить тоже самое для constexpr, параллельно устранив сложности реализации того, что понаписано в стандарте?
Антон, может вы сможете мне это пояснить?
А теперь взглянем на фрагменты из реализации std::array в STL от GNUC:
О боже, нет! Внутри это всё тот же ненавистный сишный массив!!! Какой кошмар… :)))
Не возбраняю!
Домашний АФАР :)
Ключи ассиметричного алгоритма шифрования, например RSA, являются равноправными (т.е. любой ключ из ключ-пары может расшифровать то, что зашифровано другим ключом из той же ключ-пары), а "закрытый ключ" и "открытый ключ", это лишь условности в рамках инфраструктуры открытых ключей (PKI). В рамках упомянутой инфраструктуры закрытый ключ служит для шифрования дайджеста сообщения (aka hash-value или fingerprint), что и является электронно-цифровой подписью сообщения.
Метод простой подстановки, при шифровании достаточно больших текстов (приблизительно от сотни слов и больше), не является криптостойким и ломается простой статистикой по частоте букв в словах для конкретного языка.
В цифровой подписи открытый ключ из сертификата служит для расшифровки дайджеста сообщения, зашифрованного закрытым ключом, что, собственно и является электронно-цифровой подписью.
Эволюция и естественный отбор так не работают! Нужны десятки, а то и сотни "испытуемых".
Почему нельзя было посмотреть в исходниках Easy-RSA на предмет "как правильно"?
https://community.openvpn.net/Pages/EasyRSA
Какой-то тупой подпендосник ущемился за вечно истекающих слюной по чужим ресурсам пендосов и минусанул комментарий выше... ☝️
Фу таким быть! 🤣
P.S. Жаль, что на Хабре нельзя смотреть кто именно минусанул... Страна должна знать "своих хероев"!
Просто на планете арахнидов американцы в большом количестве обнаружили крайне ценные полезные ископаемые, до которых самим арахнидам нет никакого дела, но зато арахнидам есть дело до прилетевшей к ним с другой планеты еды. :)
Здесь что-то на хипстеро-хостерском...
Ответил верно на 8 из 10, при том, что не знал ответа ни на один вопрос. Х)))
А можно просто потянуть за правый нижний уголок выделения ячейки.
Конечно GNUC компилятор (g++) знает, что constexpr выражение создаётся из неинициализированного по common sequence initialization члена объединения реализованного как constexpr, а потому выдаёт подобную ошибку:
error: accessing ‘<alpha>’ member instead of initialized ‘<omega>’ member in constant expression
Меня всегда интересовала мотивация разработчиков стандарта и компиляторов, по которой принимаются те или иные, весьма сомнительные решения.
Пожалуйста, поясните поподробнее про те бреши в безопасности, которые открывают объединения. До сих пор до конца не понимаю — чем мотивировались разработчики стандарта C++, запрещая доступ через неинициализированный член к данным constexpr объединения, инициализированных через другой член объединения. В чём именно опасность?
Даёшь зелёный свет новым backdoor, тоянам и майнерам!
Скажем "Нет!" бесполезному простою железа в idle !!! :)
Тоже хочу подушнить!
В популярных дистрибутивах Linux нет Zygote, а вызов fork() есть! В операционной системе Windows, где каждый процесс изолирован, но процессы разделяют общее ядро, нет ни Zygote, ни вызова fork(), а "клонирование" ядра есть. Хотя, в реальности никакого клонирования там нет, а есть лишь разделение процессами одних и тех же, доступных на чтение страниц памяти, принадлежащих ядру Windows.
Так что, Zygote, не потому, что fork(), а потому что основа для разных процессов с разделяемыми через общие страницы памяти этих процессов библиотеки.