Просто на планете арахнидов американцы в большом количестве обнаружили крайне ценные полезные ископаемые, до которых самим арахнидам нет никакого дела, но зато арахнидам есть дело до прилетевшей к ним с другой планеты еды. :)
Конечно 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(), а потому что основа для разных процессов с разделяемыми через общие страницы памяти этих процессов библиотеки.
Ядро Linux написано на Си, а в Си нет никакого синтаксического сахара для поддержки ООП. По мнению этих говорящих голов выходит, что вся команда Торвальдса — лохи? :)
Хорошо освоить Linux за 64 часа можно путём установки ArchLinux в собственноручно развёрнутый fake-root, в соответствии с бесплатной прекрасной справочной документацией на ArchLinux. По правде сказать, лучшей документации я нигде не встречал.
Не всё использовали. И даже сейчас не всё используют.
а затем сами же уверяете, что для сделанного ранее утверждения недостаточно информации? Заметьте — мой комментарий является лишь логическим выводом, сделанным из вашего утверждения. ;)
То есть вы продолжаете полагать, что классификация решений, которые до того программисты использовали годами, придумывание к элементам этой классификации названий и издание (за деньги), были сделаны лишь для того, чтобы вам было удобнее рассказывать коллегам в баре за кружкой пива, как и через какой design pattern вы реализовали тот или иной пункт ТЗ? Серьёзно? Х)
Какие ещё варианты, кроме, как не срубить бабло на ровном месте?
Любое придуманное решение даже без знания "Design Patterns", так или иначе, можно будет натянуть на один из известных паттернов. Как я уже писал, книга про паттерны проектирования была написана об уже известных решениях лишь с целью их классифицировать.
В STL нет контейнера std::visitor, ни в стандарте C++23, ни в стандарте C++26. Всё что есть, это прикрученный к std::variant вызов функция/метода visit() для вызова некоего функтора с произвольным числом параметров, заданных с помощью параметров из шаблона union-контейнера std::variant. Иными словами, в STL к C++ нет шаблона с одноимённым названием, который хотя бы приблизительно реализовывал функционал "Visitor pattern". С другими названиям из "Design Patterns", полагаю, история схожая...
Что же касается std::forward_iterator, то он относится к семейству итераторов, существующих в STL с момента её появления и использующихся для обхода коллекции элементов внутри контейнеров, которые такую возможность предоставляют, а совсем не то, что вы, опять же, себе нафантазировали.
This concept refines std::input_iterator by requiring that I also model std::incrementable (thereby making it suitable for multi-pass algorithms), and guaranteeing that two iterators to the same range can be compared against each other.
std::lock является шаблонной функцией, позволяющей разрешать "мёртвые блокировки" при работе алгоритмов, использующих блокировку множества мьютексов и также не имеет никакого отношения к вашим фантазиям про "Design Patterns" в STL.
Ваша беда в том, что вы пытаетесь проецировать свои знания Java или C#, код которых работает под программных управлением специальной исполняющей программной машины, на C++, компилятор которого выдаёт машинный код. Крайне не советую вам делать так и впредь!
Я бы ещё понял, если бы "ассемлерщик" пытался проецировать свои знания на Си или C++, а "сишник" или "плюсовик" пытался проецировать свои знания на Java или C#... Это, хотя бы, имеет логику причинно-следственных связей в разрезе "кто на ком стоял".
P.S. Рекомендую вам забыть о википедии, как о источнике достоверной информации, а тем более приводить в качестве обоснований при обсуждении C++ информацию, которая к C++ не относится. Вы прекрасно знали, что по приведённой вами ссылке на "Visitor pattern" в качестве доказательства существования в STL контейнера std::visitor, нет примера на C++, но упорно продолжали "натягивать сову на глобус". С какой целью? В чём ваш профит?
А параметры монитора разве нельзя в его свойствах поменять? Оно на EDID плюет обычно, если разрешение и частоту синхронизации вручную задать. У Вас - не так?
Все мониторы, определяющиеся в системе, как plug-n-play, передают системе свой E-EDID, чтобы система имела полный набор параметров подключённого монитора и могла использовать субпиксельный рендеринг шрифтов, а также правильно отображать элементы, размеры которых заданы в типографских пунктах, но если у вас каким-то образом эта информация в EEPROM монитора повредилась и/или система не может установить корректность переданного ей блока по контрольному байту, система ничего не будет знать о параметрах монитора — о доступных разрешениях и размерах видимого поля.
странно что у вас в коде есть только case "ACR" и BNQ, хотя таких сокращений около 60-70шт (сейчас наверняка больше). Или тут какие-то особенности есть для этих производителей?
Что под рукой было, то и смог реализовать. Вообще, производители не придерживаются какого-то общего соглашения и комбинируют это два поля с информацией о серийном номере по своему усмотрению.
Потому, что это legacy ещё со времён операционной системы DOS и мониторов CGA с разрешением 640x200, которые в стандартном текстовом режиме имели размер символов знакогенератора 8x8, а также соответствующей ширины печатного поля принтера при отправке текстового файла на печать через "copy file :prn".
Какой-то тупой подпендосник ущемился за вечно истекающих слюной по чужим ресурсам пендосов и минусанул комментарий выше... ☝️
Фу таким быть! 🤣
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(), а потому что основа для разных процессов с разделяемыми через общие страницы памяти этих процессов библиотеки.
Ядро Linux написано на Си, а в Си нет никакого синтаксического сахара для поддержки ООП. По мнению этих говорящих голов выходит, что вся команда Торвальдса — лохи? :)
Хорошо освоить Linux за 64 часа можно путём установки ArchLinux в собственноручно развёрнутый fake-root, в соответствии с бесплатной прекрасной справочной документацией на ArchLinux. По правде сказать, лучшей документации я нигде не встречал.
То есть вы сами делаете утверждение:
а затем сами же уверяете, что для сделанного ранее утверждения недостаточно информации? Заметьте — мой комментарий является лишь логическим выводом, сделанным из вашего утверждения. ;)
То есть вы продолжаете полагать, что классификация решений, которые до того программисты использовали годами, придумывание к элементам этой классификации названий и издание (за деньги), были сделаны лишь для того, чтобы вам было удобнее рассказывать коллегам в баре за кружкой пива, как и через какой design pattern вы реализовали тот или иной пункт ТЗ? Серьёзно? Х)
Какие ещё варианты, кроме, как не срубить бабло на ровном месте?
Иными словами, теперь вы согласны с моим первым комментарием, начавшим этот холивар? :)
Любое придуманное решение даже без знания "Design Patterns", так или иначе, можно будет натянуть на один из известных паттернов. Как я уже писал, книга про паттерны проектирования была написана об уже известных решениях лишь с целью их классифицировать.
Не надо фантазировать!
В STL нет контейнера
std::visitor,ни в стандарте C++23, ни в стандарте C++26. Всё что есть, это прикрученный кstd::variantвызов функция/метода visit() для вызова некоего функтора с произвольным числом параметров, заданных с помощью параметров из шаблона union-контейнераstd::variant. Иными словами, в STL к C++ нет шаблона с одноимённым названием, который хотя бы приблизительно реализовывал функционал "Visitor pattern". С другими названиям из "Design Patterns", полагаю, история схожая...Что же касается std::forward_iterator, то он относится к семейству итераторов, существующих в STL с момента её появления и использующихся для обхода коллекции элементов внутри контейнеров, которые такую возможность предоставляют, а совсем не то, что вы, опять же, себе нафантазировали.
std::lock является шаблонной функцией, позволяющей разрешать "мёртвые блокировки" при работе алгоритмов, использующих блокировку множества мьютексов и также не имеет никакого отношения к вашим фантазиям про "Design Patterns" в STL.
Ваша беда в том, что вы пытаетесь проецировать свои знания Java или C#, код которых работает под программных управлением специальной исполняющей программной машины, на C++, компилятор которого выдаёт машинный код. Крайне не советую вам делать так и впредь!
Я бы ещё понял, если бы "ассемлерщик" пытался проецировать свои знания на Си или C++, а "сишник" или "плюсовик" пытался проецировать свои знания на Java или C#... Это, хотя бы, имеет логику причинно-следственных связей в разрезе "кто на ком стоял".
P.S. Рекомендую вам забыть о википедии, как о источнике достоверной информации, а тем более приводить в качестве обоснований при обсуждении C++ информацию, которая к C++ не относится. Вы прекрасно знали, что по приведённой вами ссылке на "Visitor pattern" в качестве доказательства существования в STL контейнера std::visitor, нет примера на C++, но упорно продолжали "натягивать сову на глобус". С какой целью? В чём ваш профит?
"Настройки по умолчанию" для монитора в венде, это стандартные VESA-режимы и максимально доступным будет 1024x768@60.
Все мониторы, определяющиеся в системе, как plug-n-play, передают системе свой E-EDID, чтобы система имела полный набор параметров подключённого монитора и могла использовать субпиксельный рендеринг шрифтов, а также правильно отображать элементы, размеры которых заданы в типографских пунктах, но если у вас каким-то образом эта информация в EEPROM монитора повредилась и/или система не может установить корректность переданного ей блока по контрольному байту, система ничего не будет знать о параметрах монитора — о доступных разрешениях и размерах видимого поля.
Моник покупался новым и до того момента отработал около 6 лет без нареканий.
Не проверял, но на Win7 должно работать.
Что под рукой было, то и смог реализовать. Вообще, производители не придерживаются какого-то общего соглашения и комбинируют это два поля с информацией о серийном номере по своему усмотрению.
Потому, что это legacy ещё со времён операционной системы DOS и мониторов CGA с разрешением 640x200, которые в стандартном текстовом режиме имели размер символов знакогенератора 8x8, а также соответствующей ширины печатного поля принтера при отправке текстового файла на печать через "copy file :prn".