Во-первых, непортабельно даже в пределах одной хардовой платформы x86_64. Если уж очень хочется поиграться с ассемблером, рекомендую изучить inline assembler, реализованный в наборе компиляторов GNUC как под LInux/Unix, так и под Windows (MSYS2/MinGW), с его передачей аргументов в ассемблерную вставку, клобберами, хорошими возможностями не убивать оптимизацию кода;
Во-вторых, непонятно зачем тут ассемблер, когда есть std::thread, std::atomic, std::mutex и std::condition_variable? Всё можно было сделать на чистых Плюсах, тем самым обеспечив переносимость;
В-третьих, избавиться от переключения контекста в среде с вытесняющей многозадачностью невозможно — так или иначе поток будет периодически приостанавливаться и ОС будет переключать ядро процессора на выполнение других потоков этого же или других процессов;
В-четвёртых, на данный момент у пользователя galilov на github отсутствуют какие-либо публичные репозитории — “galilov doesn’t have any public repositories yet.”. :)
Но ведь “объект” в 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 объединения, инициализированных через другой член объединения. В чём именно опасность?
Это “модное слово” существует ещё со времён Windows NT.
Во-первых, непортабельно даже в пределах одной хардовой платформы x86_64. Если уж очень хочется поиграться с ассемблером, рекомендую изучить inline assembler, реализованный в наборе компиляторов GNUC как под LInux/Unix, так и под Windows (MSYS2/MinGW), с его передачей аргументов в ассемблерную вставку, клобберами, хорошими возможностями не убивать оптимизацию кода;
Во-вторых, непонятно зачем тут ассемблер, когда есть std::thread, std::atomic, std::mutex и std::condition_variable? Всё можно было сделать на чистых Плюсах, тем самым обеспечив переносимость;
В-третьих, избавиться от переключения контекста в среде с вытесняющей многозадачностью невозможно — так или иначе поток будет периодически приостанавливаться и ОС будет переключать ядро процессора на выполнение других потоков этого же или других процессов;
В-четвёртых, на данный момент у пользователя galilov на github отсутствуют какие-либо публичные репозитории — “galilov doesn’t have any public repositories yet.”. :)
«И говинда ваша ничего. Жидковата, но ничего. Пойдёте в химвойска» © ДМБ
Но ведь “объект” в 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 объединения, инициализированных через другой член объединения. В чём именно опасность?