Здравствуйте, landerhigh, Вы писали:
L>Задним числом-то все умны.
Встроить в язык бильтин "has_field" и "has_method" — это блин строчек 10 в коде компилятора. Обходные пути через "давай попытаемся вызвать такой-то метод и в случае ошибки компиляции выберем другую перегрузку" — это блин через жопу.
Да, это слишком примитивно, потому что потом захочется узнать номер поля с таким именем, его тип, смещение итд. Но блин, неужели так сложно CTTI вшить? Они не будет жрать в екзешнике НИ-ХРЕ-НА, если не используется. Это просто адский тупняк комитета, потому что эта фича — одна из самых заметных по соотношению полезности к сложности реализации в компиляторе.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>Но блин, неужели так сложно CTTI вшить? Они не будет жрать в екзешнике НИ-ХРЕ-НА, если не используется. Это просто адский тупняк комитета, потому что эта фича — одна из самых заметных по соотношению полезности к сложности реализации в компиляторе.
Судя по всему сложно именно с формальной точки зрения. Никак не могут договориться о том, как это будет выглядеть. Существующие предложения все какие-то однобокие.
Я думаю это давно сделали бы, если бы нашелся человек, который бы разносторонне это все формализовал.
Здравствуйте, T4r4sB, Вы писали:
TB>Встроить в язык бильтин "has_field" и "has_method" — это блин строчек 10 в коде компилятора.
Мне казалось, что потребность в подобных метафункциях отпала с появлением констрейнтов в C++20. Возможно, я что-то упускаю из виду. Можешь привести пример, где востребованы эти утилиты?
Здравствуйте, T4r4sB, Вы писали:
TB>Это просто адский тупняк комитета
Увы, это не просто тупняк. Это прямое следствие эйфории, порожденное открытием возможностей шаблонов. У людей, которые склонны к шаблонной магии, даже ее использование, не говоря уже о развитии, вызывает ощущение причастности к чему-то особенному, "высшему", в противовес скучному программированию на предусмотренных и документированных средствах. Примерно так же, как людям, склонным к хакингу, куда интереснее копаться в потрохах, искать нестандартные пути и побочные эффекты.
Само по себе это неплохо, но лишь когда соблюдается здоровый баланс прагматиков и авантюристов. В комитете, судя по всему, авантюристы давно составляют большинство.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>У людей, которые склонны к шаблонной магии, даже ее использование, не говоря уже о развитии, вызывает ощущение причастности к чему-то особенному, "высшему", в противовес скучному программированию на предусмотренных и документированных средствах.
Да это только с твоей точки зрения это какая-то магия, типа как ружьё для папуаса. Для тех, кто всем этим владеет, это просто техника.
P.S. А еще есть такие папуасы, которые стреляют себе в ноги, пытаясь овладеть этой техникой. Тогда они идут и рассказывают другим папуасам: "вот видите, до чего доводит прогресс". Обильно приправляя это рассказами о том, сколько тигров и медведей он завалил голыми руками.
Здравствуйте, rg45, Вы писали:
R>Мне казалось, что потребность в подобных метафункциях отпала с появлением констрейнтов в C++20.
Constraints позволяют всего лишь сузить диапазон применения одного конкретного шаблона, но не позволяют менять его содержимое в зависимости от переданных параметров.
Ну и C++20 — это буквально "вчера". Многие до сих пор пользуются C++11, да и C++03 тоже хватает. Не все ж бегут обновляться сразу же, как только подгонят реализацию очередного стандарта.
R>Можешь привести пример, где востребованы эти утилиты?
Бывают случаи, когда нужно сделать шаблонный класс или функцию, структура которых различается в зависимости от параметров шаблона (например, наличия/отсутствия того же члена класса). Нередко такие особенности удобнее и логичнее явно указывать в самом шаблоне, нежели городить не совсем очевидную иерархию, вынося зависимые участки наружу.
Организация такого при помощи requires похожа на то, как если бы в теле оператора if был допустим только вызов функции, а само условие требовалось указывать в ее заголовке.
Здравствуйте, Евгений Музыченко, Вы писали:
R>>Можешь привести пример, где востребованы эти утилиты?
ЕМ>Бывают случаи, когда нужно сделать шаблонный класс или функцию, структура которых различается в зависимости от параметров шаблона (например, наличия/отсутствия того же члена класса). Нередко такие особенности удобнее и логичнее явно указывать в самом шаблоне, нежели городить не совсем очевидную иерархию, вынося зависимые участки наружу.
ЕМ>Организация такого при помощи requires похожа на то, как если бы в теле оператора if был допустим только вызов функции, а само условие требовалось указывать в ее заголовке.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Бывают случаи, когда нужно сделать шаблонный класс или функцию, структура которых различается в зависимости от параметров шаблона (например, наличия/отсутствия того же члена класса). Нередко такие особенности удобнее и логичнее явно указывать в самом шаблоне, нежели городить не совсем очевидную иерархию, вынося зависимые участки наружу.
А где и как вы экспериментировали с такими возможностями?
Полагаю, не в C++, т.к. шаблонную магию в C++ вы принципиально не используете.
Может быть в D, где есть static if?
ЗЫ. Спрашиваю потому, что как раз таки делал подобное в C++ (без особых проблем даже в рамках C++11/14) и в D (но на уровне hello world-ов).
Здравствуйте, rg45, Вы писали:
R>Здравствуйте, T4r4sB, Вы писали:
TB>>Встроить в язык бильтин "has_field" и "has_method" — это блин строчек 10 в коде компилятора.
R>Мне казалось, что потребность в подобных метафункциях отпала с появлением констрейнтов в C++20. Возможно, я что-то упускаю из виду. Можешь привести пример, где востребованы эти утилиты?
Для выбора перегрузки они уже делают что нужно, для сериализации — нет. Да, для нее конечно мало has_field, там нужна полноценная метаинфа, но техничаски жто довольно простая фича. Я скорее поверю в сложности с выбором дизайна
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
TB>Для выбора перегрузки они уже делают что нужно, для сериализации — нет. Да, для нее конечно мало has_field, там нужна полноценная метаинфа, но техничаски жто довольно простая фича. Я скорее поверю в сложности с выбором дизайна
Почему только для выбора перегрузки? requires expressions можно использовать везде, где ожидается булево выражение, в т.ч. константное — в определениях концептов, в constexpr if statements, в static_assert-ах, а также для определения метафункций в старом стиле, который использовался до C++20. Кроме того, requires expression можно делать различной степени сложности и подробности, что трудно себе представить в реализации статичных утилит has_field, has_method, etc. Чего не хватает?
Здравствуйте, rg45, Вы писали:
R>это только с твоей точки зрения это какая-то магия, типа как ружьё для папуаса.
Папуас усматривает в ружье магию прежде всего потому, что ему непонятна суть происходящих там процессов. В его понимании это истинная магия — то есть, сверхъестественные процессы, понять и повторить которых он не в состоянии.
Я вполне понимаю суть процессов, происходящих при обработке шаблонов, и при желании могу реализовать все это своими силами. "Магией" я это называю иронично, наравне с "извращением", "костылями", "чрезжопностью" и т.п.
R>Для тех, кто всем этим владеет, это просто техника.
С тем же успехом можно сказать, что искусство хождения по канату — "просто техника", и у тех, кто им владеет, не вызывает большого дискомфорта.
R>А еще есть такие папуасы, которые стреляют себе в ноги, пытаясь овладеть этой техникой.
Тут вопрос прежде всего в том, заслуживает ли эта техника усилий, потребных на овладение ею не только на уровне "скопировать пример, поменяв имена", но и на уровне четкого понимания того, как она работает в каждом конкретном случае. Практика показывает, что это осиливает лишь ничтожная доля всех, кто технику так или иначе применяет. Уже само это должно настораживать и наводить на мысль, что в этом есть что-то неправильное. Но возобладало отношение "ежели кто неспособен оперировать техникой свободно и виртуозно, ему не место среди нас".
Здравствуйте, so5team, Вы писали:
S>А где и как вы экспериментировали с такими возможностями?
Когда-то много экспериментировал в макроассемблерах, имевших такие возможности. Что-то делал на PL/1, но совсем мало.
S>Полагаю, не в C++
В том числе и в C++ — в VC++ есть __if_exists/__if_not_exists. Это, конечно, слабое подобие левой руки, да и реализовано было коряво, отчего им и пришлось неофициально (через Чена) объявить о нежелательности использования. Однако до сколько-нибудь явных ограничений не дошло и до сих пор.
S>т.к. шаблонную магию в C++ вы принципиально не используете.
Не использую — пока у меня, по счастью, не возникало ситуаций, в которых ее использование объективно упростило бы жизнь. Очень надеюсь, что и не возникнет.
S>как раз таки делал подобное в C++ (без особых проблем даже в рамках C++11/14)
Так я не говорил, что это невозможно. Я говорил, что в C++ это делается через задницу, в виде побочного эффекта от конструкций, изначально предназначенных для другого.
Несколько напоминает то, что героин изначально предлагался в качестве средства от кашля.
Ваши мелочные придирки по сути очень напоминают известный анекдот.
R>А у тебя тут подобных "шедевров" на целое собрание сочинений хватит.
Это Вам так кажется. Если возьметесь систематизировать, найдете очень немного, и в основном по мелочам.
R>Что можешь сказать о типе результата функции?
Даже пробовать не буду. Не вижу никакого смысла в подобных задачках, кроме как на экзамене/собеседовании.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Ваши мелочные придирки по сути очень напоминают известный анекдот.
Ваши заявления о "понимании сути" посмешнее любого анекдота будут.
ЕМ>Это Вам так кажется. Если возьметесь систематизировать, найдете очень немного, и в основном по мелочам.
Ну да, "все до чего я не дотянулся — это мелочи и зеленый виноград". Где-то я уже слышал эту басную
ЕМ>Даже пробовать не буду. Не вижу никакого смысла в подобных задачках, кроме как на экзамене/собеседовании.
Не хватает перечисления полей для сериализации. Тут сложности как совместить с инкапсуляцией, но при этом есть библиотеки, которые с этим справляются. Но ценой шаблонного ада.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, T4r4sB, Вы писали:
R>>Чего не хватает?
TB>Не хватает перечисления полей для сериализации. Тут сложности как совместить с инкапсуляцией, но при этом есть библиотеки, которые с этим справляются. Но ценой шаблонного ада.
Для структур со standard layout это делается достаточно просто. Я достаточно давно уже этим пользуюсь — определяешь новую структуру и для нее автоматом сразу есть сериализация и операторы ввода-вывода
Здравствуйте, T4r4sB, Вы писали:
L>>Задним числом-то все умны.
TB>Встроить в язык бильтин "has_field" и "has_method" — это блин строчек 10 в коде компилятора. Обходные пути через "давай попытаемся вызвать такой-то метод и в случае ошибки компиляции выберем другую перегрузку" — это блин через жопу.
Опять же, задним числом все умны и вообще афигеть стратеги.
Путаешь причину и следствие. Пытаешься выкатывать претензии инженерам ранних GMS GSM протоколов, что размер SMS был ограничен 170 символами, если за пределы 7 бит не выходить, и доставка не гарантировалась.
Никто не планировал, что механизм шаблонов со своим sfinae внезапно позволит делать такие адские штуки прямо в compile time.
Но вышло то, что вышло. С точки зрения юзера, которому нужно просто has_field — это пипец как криво.
С точки зрения инженера — используется встроенная в язык фича, посему has_field получается вообще халявным. Короче — работает. Причем, искаропки. Причем, соответствует стандарту.
TB>Да, это слишком примитивно, потому что потом захочется узнать номер поля с таким именем, его тип, смещение итд. Но блин, неужели так сложно CTTI вшить?
А ты попробуй хотя бы черновик такого proposal написать
