Все эти трюки отлично работают, пока их применяют три с половиной гика на кастомных прошивках.
Если что-то подобное появится в стоке — немедленно начнётся «гонка вооружений» и фонарик будет отказываться запускаться если у вас адресная книга реально пуста, а карты будут требовать подтверждений о вашем местонахождении от ОПСОСа.
Ничем хорошим это не кончится.
Оставьте эти трюки тем, кому реально больше нечем заняться.
Окупит-окупит. Только сравнивать нужно не с ценой автомобиля, а с годовой (примерно) зарплатой водителя.
Просто пропагандой делается жёсткий упор на то, как автопилот будет возить вашу задницу на работу на вашей же машине… Хотя на самом деле его удел — привести к увольнению профессиональных шофёров… в первую очередь дальнобоев.
а стоматолог на самом деле не желает долгого здоровья вашим зубам.
Хороший как раз желает. Меня лет шесть назад отправили к такому. Да, он взял за пару месяцев у меня больше денег, чем до того я относил к стоматолагам за три года… но за последующие пять лет я был у него на ежегодном обследовании — это уже было бесплатно. Так что я уже в выигрыше.
А вот с операционками у нас нет выбора как между хорошими и плохими стоматолагами, так что приходится вмешиваться государству.
Впрочем и монополия Microsoft существует только за счёт государства, так что у него вдвойне больше прав решать… но у государства, а не у «Фонда СПО»!
Его, в сущности, только легализовать нужно. В компиляторах поддержка уже есть. Да и даже если нет то почти должна быть: ведь как-то же char/unsigned char/std::byte им нужно «особым образом» обрабатывать?
В стандарте и так уже полно опциональных фишек помеченных всякими __cpp_inheriting_constructors или __cpp_decltype_auto.
Просто сейчас стандарт требует определять их все и в строго определённое число… а можно разрешить некоторые из них не определять, если компилятор их не поддерживает.
И говорить «если XXX поддерживается компилятором, тогда YYY».
Тогда и разработчики библиотек смогут использовать эти фичи, если на данном, конкретном, компиляторе, они есть — и требовать их поддержки со сломом всего и вся не требуется.
Вы не видите, а вот маркетинговые отделы видят. И в очень большом количестве компаний деньги на переход на C++23 найдутся, а вот на «экспериментальную поддержку» — нет.
Да, я знаю, что в мире JavaScript — это нормально. В мире C++ — нет. Подавляющее большинство компаний «сидели на жопе ровно» и не трогали ничего из C++11 пока разработчики GCC не объявили «всё, поддержка C++0x более не является экспериментальной… можно пользовать» в GCC 5.
Может быть в каких-то компаниях по каким-то причинам к формальному статусу поддержки стандарта компилятором относятся очень серьёзно, но я не понимаю, какие это могут быть причины.
Причина проста: компилятор может потребоваться заменить (скажем с MSVC на ICC) или просто откатить (по тем или иным причинам — скажем новые версии GCC перестали поддерживать нужную вам фичу или платформу).
Если вы разрешаете только полностью реализованные фичи — то вам достаточно проверить есть ли в списке поддерживаемых нужный вам диалект C++ — и всё. А вот если вы всякую-разную «экспериментальную поддержку» используете… это проблема.
Ладно ещё если нужной вам фичи в разных компиляторах нет — это ещё полбеды. А если есть, но она реализована по разному или с ошибками?
Те же designate initializers возьмите: до clang 10 они банально небезопасны!
Да, в основном это касается крупных проектов и огромных компаний… но поскольку они и являются главными спонсорами развития C++… то они заказывают музыку.
Нужно появление 1 (одного) популярного приложения, разработчиков которого задолбает борьба с IPv4. После чего всё случится очень быстро.
У меня где-то дома валяется стаеренькая книжка Novell, которая описывает как IPX и TCP/IP будут сосуществовать «в ближайшие 10 лет».
Вот только вышла она в 1994м… А до 2004го IPX дожил только в каких-то заповедно-исторических нишах… Ибо появление WWW немедленно сделало IPX устаревшим.
То же самое, скорее всего, случится и с IPv4… после пересечения уровня 50%, скорее всего.
Ведь это реально серьёзнейший косяк, потому что это безумие — хранить язык для каждого слова отдельно.
Тем не менее это необходимо, если вы хотите делать какие-то нетривиальные преобразования.
Либо у пользователя можно спросить (Windows, скажем, использует один метод для всех имён файлов на диске, хотя для разных дисков могут быть выбраны разные варианты).
То есть так как оно сделано в в юникоде и в С++ сейчас выходит просто неправильно.
Почему неправильно? Сделано, то, что возможно. Вы же сами нашли ствтью, где написано, что немцы считают, что DUERST и Dürst — это одно слово… а финны так не считают. И при этоми те и другие уверены, что используют латинницу «правильно».
Но всё равно, лучше плохонький стандарт с недостатками, чем вообще ничего.
Как показывает практика — нет.
Стандарт потом допилить можно.
Как только вы что-то добавили в стандарт — на это в очень короткое время оказываются завязаны десятки и сотни тысяч библиотек. Править потом что-либо — очень сложно.
Тем не менее — он нигде не выхван, так что объект никогда не был создан.
Я не к тому, что так надо писать.
Проблема в том, что так, собственно, и пишут — с 70х годов… а стандарт этого не позволяет.
Собственно это просто чёткое описание для разработчиков компилоров того, что в них и так есть (все известные мне компиляторы считает, что malloc создаёт объекты… хотя по стандарту C++17 это не так).
Так что практически, для malloc'а это все не нужно… Нужно для всяких arena-аллокаторов, когда берут кусок памяти, где «жил» объект одного типа, а потом суют туда объект другого типа.
хехе, решение на отвратительно оптимизированных корутинах всё еще заметно быстрее и на порядки выразительнее async/thread и велосипедов на их основе построенных
Ну threads — да, это понятно. Но короутины напрашиваются на ranges и вообще любые циклы for… и вот там то, что творят современные компиляторы — это форменное непосредство…
Нет — я реалист. Сегодня поддержка IPv6 — примерно у 30%. Порог 50% — будет где-то через 3-4 года. После пересечения границы 50% можно спокойно перестать в новых проектах IPv4.
Эта простая эвристика, неплохо работающая: примерно так было и с Windows XP и со многим другим.
Наличие отдельных «отстающих» групп (Китай у Windows XP, Россия у IPv4) ничего не меняет: если большинство уже перешло и поддержки больше нет — то это их проюлемы, не ваши.
Плюс, опять-таки многое зависит от API: если API будет достаточно высокоуровневым, то факт существования и использования IPv4 может оказаться скрфтым от приложения.
Конечно есть — Microsoft C++ предыдущих версий. Каждая со своим рантаймом и своим ABI, вопросами совместимости которого до недавнего времени в MS не заморачивались.
Ну то есть вся проблема существовала только и исключительно благодаря Microsoft'у. Причём что самом смешное, для себя-то, любимых, они всё сделали правильно.
Именно потому и существует опция -Wabi, способная на это отреагировать. И она настроена сегодня, по умолчанию на поддержку совместимости с GCC 5.x не случайно: из-за того, что C++11 поломал поддержку обратной совместимости как раз переход с GCC 3.x/4.x на GCC 5+ несколько затруднён.
Но если вам нужно — то можно установить -Wabi=2.
Что касается выравнивания, то проблемы действительно возможны, но в одном, очень редком случае — при использовании decltype(nullptr) (к std::nullptr_t это не относится) — то только на процессорах, отличных от x86 и arm.
Что скорее говорит о дотошности разработчиков, чем о вероятности реальных проблем: в MSVC я видел куда большие отличия между сервис-паками, чем у GCC между версиями 3.4 и 9.2…
Это было бы действительно принципиальным расширением функциональности языка, как поддержка многопточности в С++11.
Между поддержкой сети есть разница — и она принципиальна: поддержку сети можно добавить сторонней библиотекой, а вот поддержку многопоточности — нет.
Хотя поддержка сети бала бы полезной вещью, спору нет, но мне кажется рановато пока: придётся поддерживать IPv4 и всю связанную с ним муру. Вот в C++23 или C++26 уже можно вносить поддержку, жёстко завязанную на IPv6…
Ближе всего к инновациям, пожалуй, корутины (к которым я субъективно настроен скептически).
Короутины изменят «всё» (в некотором смысле) — так же как метапрограммирование изменило «всё» (в некотором смысле).
Однако произойдёт это скорее ближе к 2030му, чем к 2022му. По одной простой причине: компиляторы пока оптимизируют короутины отвратительно — а раз так, то разработчики будут их избегать. А раз их избегают разработчики — не очень будут напрягаться и компиляторщики…
Тут нужна какая-нибудь популярная библиотека на корутинах (как STL в своё время).
Потому что разборка с тегами прекрасно работает через bit_cast.
Я бы, перед написанием пропозала, об этом вначале подумал.
Все эти трюки отлично работают, пока их применяют три с половиной гика на кастомных прошивках.
Если что-то подобное появится в стоке — немедленно начнётся «гонка вооружений» и фонарик будет отказываться запускаться если у вас адресная книга реально пуста, а карты будут требовать подтверждений о вашем местонахождении от ОПСОСа.
Ничем хорошим это не кончится.
Оставьте эти трюки тем, кому реально больше нечем заняться.
Просто пропагандой делается жёсткий упор на то, как автопилот будет возить вашу задницу на работу на вашей же машине… Хотя на самом деле его удел — привести к увольнению профессиональных шофёров… в первую очередь дальнобоев.
А вот с операционками у нас нет выбора как между хорошими и плохими стоматолагами, так что приходится вмешиваться государству.
Впрочем и монополия Microsoft существует только за счёт государства, так что у него вдвойне больше прав решать… но у государства, а не у «Фонда СПО»!
char/unsigned char/std::byteим нужно «особым образом» обрабатывать?Так что можете писать proposal.
Просто сейчас стандарт требует определять их все и в строго определённое число… а можно разрешить некоторые из них не определять, если компилятор их не поддерживает.
И говорить «если XXX поддерживается компилятором, тогда YYY».
Тогда и разработчики библиотек смогут использовать эти фичи, если на данном, конкретном, компиляторе, они есть — и требовать их поддержки со сломом всего и вся не требуется.
Или вы про то, что хорошо было бы, если бы вектора и матрицы такие штукм поддерживали — это да, возможно.
Да, я знаю, что в мире JavaScript — это нормально. В мире C++ — нет. Подавляющее большинство компаний «сидели на жопе ровно» и не трогали ничего из C++11 пока разработчики GCC не объявили «всё, поддержка C++0x более не является экспериментальной… можно пользовать» в GCC 5.
Причина проста: компилятор может потребоваться заменить (скажем с MSVC на ICC) или просто откатить (по тем или иным причинам — скажем новые версии GCC перестали поддерживать нужную вам фичу или платформу).
Если вы разрешаете только полностью реализованные фичи — то вам достаточно проверить есть ли в списке поддерживаемых нужный вам диалект C++ — и всё. А вот если вы всякую-разную «экспериментальную поддержку» используете… это проблема.
Ладно ещё если нужной вам фичи в разных компиляторах нет — это ещё полбеды. А если есть, но она реализована по разному или с ошибками?
Те же designate initializers возьмите: до clang 10 они банально небезопасны!
Да, в основном это касается крупных проектов и огромных компаний… но поскольку они и являются главными спонсорами развития C++… то они заказывают музыку.
Поздновато, конечно (я бы вот сегодня побоялся выпускать в свет программу, которая Windows 10 1903+ требует), но… лучше поздно, чем никогда!
У меня где-то дома валяется стаеренькая книжка Novell, которая описывает как IPX и TCP/IP будут сосуществовать «в ближайшие 10 лет».
Вот только вышла она в 1994м… А до 2004го IPX дожил только в каких-то заповедно-исторических нишах… Ибо появление WWW немедленно сделало IPX устаревшим.
То же самое, скорее всего, случится и с IPv4… после пересечения уровня 50%, скорее всего.
Либо у пользователя можно спросить (Windows, скажем, использует один метод для всех имён файлов на диске, хотя для разных дисков могут быть выбраны разные варианты).
Почему неправильно? Сделано, то, что возможно. Вы же сами нашли ствтью, где написано, что немцы считают, что DUERST и Dürst — это одно слово… а финны так не считают. И при этоми те и другие уверены, что используют латинницу «правильно».
Как показывает практика — нет.
Как только вы что-то добавили в стандарт — на это в очень короткое время оказываются завязаны десятки и сотни тысяч библиотек. Править потом что-либо — очень сложно.
Тем не менее — он нигде не выхван, так что объект никогда не был создан.
Проблема в том, что так, собственно, и пишут — с 70х годов… а стандарт этого не позволяет.
Собственно это просто чёткое описание для разработчиков компилоров того, что в них и так есть (все известные мне компиляторы считает, что malloc создаёт объекты… хотя по стандарту C++17 это не так).
Так что практически, для malloc'а это все не нужно… Нужно для всяких arena-аллокаторов, когда берут кусок памяти, где «жил» объект одного типа, а потом суют туда объект другого типа.
Вот тут может быть… неприятность…
Эта простая эвристика, неплохо работающая: примерно так было и с Windows XP и со многим другим.
Наличие отдельных «отстающих» групп (Китай у Windows XP, Россия у IPv4) ничего не меняет: если большинство уже перешло и поддержки больше нет — то это их проюлемы, не ваши.
Плюс, опять-таки многое зависит от API: если API будет достаточно высокоуровневым, то факт существования и использования IPv4 может оказаться скрфтым от приложения.
Но если вам нужно — то можно установить -Wabi=2.
Что касается выравнивания, то проблемы действительно возможны, но в одном, очень редком случае — при использовании
decltype(nullptr)(кstd::nullptr_tэто не относится) — то только на процессорах, отличных от x86 и arm.Что скорее говорит о дотошности разработчиков, чем о вероятности реальных проблем: в MSVC я видел куда большие отличия между сервис-паками, чем у GCC между версиями 3.4 и 9.2…
Хотя поддержка сети бала бы полезной вещью, спору нет, но мне кажется рановато пока: придётся поддерживать IPv4 и всю связанную с ним муру. Вот в C++23 или C++26 уже можно вносить поддержку, жёстко завязанную на IPv6…
Короутины изменят «всё» (в некотором смысле) — так же как метапрограммирование изменило «всё» (в некотором смысле).
Однако произойдёт это скорее ближе к 2030му, чем к 2022му. По одной простой причине: компиляторы пока оптимизируют короутины отвратительно — а раз так, то разработчики будут их избегать. А раз их избегают разработчики — не очень будут напрягаться и компиляторщики…
Тут нужна какая-нибудь популярная библиотека на корутинах (как STL в своё время).