но получается что, почему-то ваше фи должны все поддержать
нет
и ставить только плюсики
нет
а оказалось что с вами просто не согласны
это более чем ожидаемо, особенно на таком ресурсе, как Хабр
или вы хотите запретить ставить минусы?
Мне не нравится цветовая дифференциация штанов, реализованная на Хабре, когда набирающие минусы комментарии специально пессимизируются визуальными эффектами.
Простите не вижу смысла отвечать на очередной набор нерелевантных банальностей, ибо если вы декларируете "не ошибается тот, кто ничего не делает", то это автоматически должно подразумевать и то, что в делаемом сейчас (в рефлексии в частности) могут быть ошибки. Но указывать на них, судя по количеству собранных мной здесь минусов нельзя.
Так что я понял: если ты обычный пользователь языка, то не смей говорить "фи" если тебе вдруг что-то не понравилось. По крайней мере на Хабре, с его системой минусования кармы.
Я вижу проблему в том, что никто не знает чьего именно вкуса. Сделали бы авторы пропозала глобальный опрос -- было бы лучше понятно, большинству это нравится или меньшинству.
Ну и [@ @] тоже не идеал. Просто пример того, что заменив всего один символ можно сделать связанный с рефлексией фрагмент кода гораздо заметнее.
В идеале подобные "операторные скобки" должны быть еще больше, типа <<[[ и ]]>>. Чтобы даже мимолетный взгляд указывал, что здесь у нас не обычный код, а связанный с рефлексией.
Вообще, это прямо эталонная позиция профессионального owed to: я не хочу и не буду вкладывать силы
Простите за грубость. Но у меня есть такое специфическое мнение, что я достаточно поработал в этих наших интернетиках адвокатом С++ защищая этот язык от глупых нападок и, хочется верить, немного поспособствовал упрощению труда некоторых С++ников за счет выложенных в OpenSource разработок. Сверх этого да, не хочу и не буду.
А если мою жизнь, как C++ разработчика, уложняют деятели из комитета, то оставляю за собой право высказывать "фи" там и где мне лично удобно.
Вам нравится @, кому-то не нравится @, почему вы считаете (если считаете, конечно), что ваши вкусовые предпочтения стоят выше чьих-то?
Потому же, что кто-то посчитал, что [: -- это настолько круто, что достойно войти в стандарт.
Потому же, что кто-то посчитал, что export template -- это настолько круто, что должно войти в стандарт. А потом выйти.
Поэтому повторю то, что писал выше: есть ощущение, что несколько сотен людей, которые взяли на себя труд развивать C++ своей работой в комитете, могли потерять обратную связь и, мягко говоря, подзабыли о миллионах программирующих на C++. По типу: мы взялись, сделали, а вы теперь жрите и не смейте нас ругать.
Я вот, например, не просил ни модулей, ни std::launder. И deducing this, который сделали так, как будто в мире в принципе нет DLL/SO из которых экспортируют С++ные классы.
Повторюсь, если бы люди, которые пилили рефлексию озадачились собрать мнение нескольких десятков тысяч C++ных разработчиков по поводу предлагаемого синтаксиса, принять [: или [@ или какую-то другую комбинацию было бы проще. Сейчас же есть ощущение, что пара-тройка очень и очень умных товарищей сделали то, что было удобно лично им. И им похер на менее умных, которым теперь с этим всем нужно будет жить.
В третьих, мало того что целая прорва постов была во множестве соц сетей
Ну вот мы здесь, по сути именно в этой ситуации. Очередной пост в очередной соцсети, с очередным комментарием о том, что синтаксис у предложенной рефлексии ну такой себе, не сильно эргономичный.
В ответ что?
всё сделано комитетом просто замечательно.
Ну OK, эксперимент с влиянием без плотного погружения в работу комитета дал ожидаемый результат.
У вас есть возможность повлиять на результат.
Повторю еще раз: пока что я вижу это возможность только если решиться начать участвовать в работе комитета "по взрослому": с чтением рассылок, изучением пропозалов, перепиской с членами комитета и вот этим вот всем.
Простите, это не мой путь. У меня нет ни интереса, ни возможностей развивать сам C++. Мне интересно C++ использовать, на что, собственно, силы и время и уходят.
И, похоже, единственное, что мне остается -- это как раз высказывать "фи". Чтобы у людей, которые считают, что "всё сделано комитетом просто замечательно" к розовым очкам хотя бы мелкие соринки прилепали.
PS. На всякий случай, если среди читающих нашу перепалку есть люди, которые веруют в непогрешимость комитета и в то, что если комитет что-то принял в стандарт, то это, безусловно, хорошо. Напомню, в качестве яркого примера, случай с export template из C++98.
Есть ли средини них хоть пара, с которыми можно работать?
А какой смысл, если статья описывает то, что уже отлито в граните?
И по поводу того, как работать. Вот тот же синтаксис для рефлексии. Вы говорите, что большинству в комитете нравится. Здесь вам пишут, что синтаксис мягко говоря, странный, вы упираете на то, что это вопрос вкуса и, может быть, вы правы. Возникает вопрос: а что с этим можно поделать?
ИМХО, более правильно было бы, если бы авторы пропозала создали бы какой-то опросник и выложили бы ссылку на этот опросник на тот же reddit. Чтобы за пару месяцев там смогло проголосовать тысяч 20-30 человек.
Тогда хотя бы стало понятно, действительно ли выбранный синтаксис нравится большому количеству будущих пользователей или нет.
Но по факту решение принято за почти закрытыми дверьми, повлиять на него, кроме как участвуюя в работе комитета, у таких как я, нет возможности. Остается разве что здесь высказать свое "фи".
Вот взять и сделать так, чтобы все сказали "вах" и никто не поливал дерьмом - это гораздо сложнее.
Это невозможно, да. Но у меня есть сомнения в том, что у комитета сейчас есть нормальная обратная связь с пользователями. Получается, что некоторая ограниченная группа людей творит то, что считает нужным, результатами их жизнедеятельности приходится пользоваться миллионам. Даже если этим миллионам не нравится то, что получается у самоизбравшихся в комитет.
Чтобы как-то повилять на принимаемые комитетом решения нужно самому вписаться в его работу. Т.е. отслеживать пропозалы, давать какую-то обратную связь, пытаться делать какие-то встречные предложения и т.д., и т.п.
У меня, например, на такое нет ни времени, ни сил, ни возможностей.
Все, что остается -- это иногда выплеснуть своё опупение от какой-то новой фичи. Типа модулей, которые кое-как собрали, впихнули в стандарт, отправили на мороз все доморощенные системы сборки и вынудили идти в обнимку к всратому CMake. При этом, по слухам от тех, кто решил попробовать это щасте, не такой уж и большой выигрыш от модулей в итоге получается.
Или вот тот же deducing this.
Можно, конечно, тихо жрать кактус молча сидя в уголке. Только это поведение тоже особо конструктивным не кажется.
Я правильно понимаю, что все, что придумывается в комитете и внедряется в C++ априори волшебно и божественно?
Может это где-то прямо в стандарте написано. Ну типа как в уставах про то, что коммандир всегда прав.
Просто часто читаю недовольство о том, во что превращается современный C++. И сам местами офигеваю от внедряемого. Если по поводу всего этого в принципе нельзя говорить ничего плохого (ну типа люди собирались, думали, тратили время и силы, спорили, дороваривались, а мы тут их известной субстанцией поливаем, твари неблагодарные), то ладно. Таковы правила игры. Дам дают бесплатно, мы жрем.
То, что deducing this послал вдоль DLL/SO -- это так, мелочь. А вот то, что CRTP, который и так не то, чтобы на каждом шагу применялся, стал чуточку лаконичнее, вот это да, достижение. Огромное спасибо с поклоном в пояс.
Заодно теперь непонятно почему нужно писать методы классов по старинке:
struct S {
void f(int a) const {...}
...
};
Если можно и молодежно:
struct S {
void f(this auto const & self, int a) {...}
};
И как объяснять новичкам почему и зачем в очередной раз в C++ одно и тоже можно сделать сильно по разному.
ИМХО, можно было бы достичь такого же эффекта не превращая C++ в Python с явной передачей self-а. Не буду повторяться, просто дам ссылку тыц (там же ссылки и на другое связанное).
К объективным претензиям по поводу deducing this добавлю то, что deducing this из C++23 на синтаксе шаблонов тупо послал в пешее эротическое DLL/so-ки. Типа у вас классы экспортируются из DLL/SO и в них есть так же самая проблема, которую решает deducing this? Это ваши проблемы, а не комитета, для C++ как для языка из стандарта, самого понятия "экспорта из DLL/SO" нет.
Проблему с рекурсивными лямбдами, которую так же затыкали все тем же deducing this, ИМХО, можно было решать как в OCaml-е с let rec.
То, что [: плохо читается, не дело вкуса. Это уже из области эргономики.
Выбор альтернативы -- это да, во многом дело вкуса.
и устраивает большинство людей в комитете
Тогда этому большинству нужно привыкать, что известной субстанции на их головы будет выливаться все больше и больше. Если бы они делали говно для себя, это были бы их личные проблемы, сами насрали, сами пусть с этим и живут.
Но вопрос в том, что они делают язык не только для себя. Результатом их труда и обычные люди будут пользоваться.
Приведу аналогию: в математике любят использовать односимвольные обозначения, зачастую с одним-двумя штрихами и верхним или нижним индексом. В формулах это OK.
А вот когда в программе имена переменных из одного-двух символов, то читабельность такого кода будет ну такое себе. Даже если этот код касается математических расчетов. Многим из нас доводилось сталкиваться с говнокодом в котором кроме i, j, ii, jj, k, kk и т.п. ничего не используется. Причем, если такой код был написан математиками или физиками, то их это вполне может устраивать.
Ну как и большинство людей в комитете.
Я это все к тому, что в C++ начиная с 20-го стандарта (если не с С++17) появляются фичи, про которые остается сказать разве что "здорово, что эту проблему пофиксили, но почему же так всрато-то?" Начиная от std::launder в C++17, заканчивая deducing this в C++23, проходя через co_return в C++20.
Если самая серьёзная проблема это синтаксис, то проблем, можно сказать, нет
Тут вспоминается ситуация, когда в C++98 нельзя было писать вот так: A<B<C>>, нужно было обязательно делать так: A<B<C> >. И это сочли настолько важным, что в C++11 внесли изменения в язык.
Казалось бы, всего лишь синтаксис, да и проблема не сказать, что прям уж смертельная... Однако ж пришлось стандарт править.
Синтаксис получился, мягко говоря, всратый. Двойная крышка, т.е. ^^, для получения метаинформации -- в чем логика? Когда есть обычный минус - и двойной в виде декремента -- -- то понятно почему знак минуса переиспользуется и удваивается. Когда тильда ~ задействована для объявления деструктора (как "дополнение" к конструктору) -- это тоже понятно. Откуда и зачем возникло сочетание из двух крышек -- ХЗ.
Но самая жесть -- это читать код с оператором "баян", т.е. [: ||| :]. Двоеточие рядом с открывающей/закрывающей квадратной скобкой очень плохо распознается, взгляд за такие новые "скобки" не цепляется. И, если уж для рефлексии стали использовать крышки, то почему бы не быть последовательным и не сделать [^ ||| ^] или даже [^^ ||| ^^]...
В итоге вроде как и сделали крутую штуку, но с таким спорным синтаксисом, что просто атас. Как будто у людей ни чувства стиля, ни чувства меры.
Например, почему бы не использовать для рефлексии символ @?
Для человека, который решил вынести свои идеи и свое творение на публику вы что-то слишком уж загадочны. Если это были внутренние закрытые разработки, то можно же так и сказать -- внутренние, закрытые. В общем, странное поведение.
Из описанного вами более-менее понятно чем не устраивает подход из Qt. Но чем, например, не подошли Boost.Signals2?
Могу я предположить, что из известных был Qt, а остальное было что-то доморощенное, сделанное под конкретный проект (а не что-то из Boost-а или еще чего-то OpenSource-ного)?
Вы привели свою классификацию но не названия конкретных инструментов. Можно предположить, что среди них был Qt, но по остальным остается только гадать.
нет
нет
это более чем ожидаемо, особенно на таком ресурсе, как Хабр
Мне не нравится цветовая дифференциация штанов, реализованная на Хабре, когда набирающие минусы комментарии специально пессимизируются визуальными эффектами.
Простите не вижу смысла отвечать на очередной набор нерелевантных банальностей, ибо если вы декларируете "не ошибается тот, кто ничего не делает", то это автоматически должно подразумевать и то, что в делаемом сейчас (в рефлексии в частности) могут быть ошибки. Но указывать на них, судя по количеству собранных мной здесь минусов нельзя.
Так что я понял: если ты обычный пользователь языка, то не смей говорить "фи" если тебе вдруг что-то не понравилось. По крайней мере на Хабре, с его системой минусования кармы.
Я вижу проблему в том, что никто не знает чьего именно вкуса. Сделали бы авторы пропозала глобальный опрос -- было бы лучше понятно, большинству это нравится или меньшинству.
Ну и
[@ @]тоже не идеал. Просто пример того, что заменив всего один символ можно сделать связанный с рефлексией фрагмент кода гораздо заметнее.В идеале подобные "операторные скобки" должны быть еще больше, типа
<<[[и]]>>. Чтобы даже мимолетный взгляд указывал, что здесь у нас не обычный код, а связанный с рефлексией.Простите за грубость. Но у меня есть такое специфическое мнение, что я достаточно поработал в этих наших интернетиках адвокатом С++ защищая этот язык от глупых нападок и, хочется верить, немного поспособствовал упрощению труда некоторых С++ников за счет выложенных в OpenSource разработок. Сверх этого да, не хочу и не буду.
А если мою жизнь, как C++ разработчика, уложняют деятели из комитета, то оставляю за собой право высказывать "фи" там и где мне лично удобно.
Потому же, что кто-то посчитал, что
[:-- это настолько круто, что достойно войти в стандарт.Потому же, что кто-то посчитал, что export template -- это настолько круто, что должно войти в стандарт. А потом выйти.
Поэтому повторю то, что писал выше: есть ощущение, что несколько сотен людей, которые взяли на себя труд развивать C++ своей работой в комитете, могли потерять обратную связь и, мягко говоря, подзабыли о миллионах программирующих на C++. По типу: мы взялись, сделали, а вы теперь жрите и не смейте нас ругать.
Я вот, например, не просил ни модулей, ни std::launder.
И deducing this, который сделали так, как будто в мире в принципе нет DLL/SO из которых экспортируют С++ные классы.
Повторюсь, если бы люди, которые пилили рефлексию озадачились собрать мнение нескольких десятков тысяч C++ных разработчиков по поводу предлагаемого синтаксиса, принять
[:или[@или какую-то другую комбинацию было бы проще. Сейчас же есть ощущение, что пара-тройка очень и очень умных товарищей сделали то, что было удобно лично им. И им похер на менее умных, которым теперь с этим всем нужно будет жить.Ну вот мы здесь, по сути именно в этой ситуации. Очередной пост в очередной соцсети, с очередным комментарием о том, что синтаксис у предложенной рефлексии ну такой себе, не сильно эргономичный.
В ответ что?
Ну OK, эксперимент с влиянием без плотного погружения в работу комитета дал ожидаемый результат.
Повторю еще раз: пока что я вижу это возможность только если решиться начать участвовать в работе комитета "по взрослому": с чтением рассылок, изучением пропозалов, перепиской с членами комитета и вот этим вот всем.
Простите, это не мой путь. У меня нет ни интереса, ни возможностей развивать сам C++. Мне интересно C++ использовать, на что, собственно, силы и время и уходят.
И, похоже, единственное, что мне остается -- это как раз высказывать "фи". Чтобы у людей, которые считают, что "всё сделано комитетом просто замечательно" к розовым очкам хотя бы мелкие соринки прилепали.
PS. На всякий случай, если среди читающих нашу перепалку есть люди, которые веруют в непогрешимость комитета и в то, что если комитет что-то принял в стандарт, то это, безусловно, хорошо. Напомню, в качестве яркого примера, случай с export template из C++98.
А какой смысл, если статья описывает то, что уже отлито в граните?
И по поводу того, как работать. Вот тот же синтаксис для рефлексии. Вы говорите, что большинству в комитете нравится. Здесь вам пишут, что синтаксис мягко говоря, странный, вы упираете на то, что это вопрос вкуса и, может быть, вы правы. Возникает вопрос: а что с этим можно поделать?
ИМХО, более правильно было бы, если бы авторы пропозала создали бы какой-то опросник и выложили бы ссылку на этот опросник на тот же reddit. Чтобы за пару месяцев там смогло проголосовать тысяч 20-30 человек.
Тогда хотя бы стало понятно, действительно ли выбранный синтаксис нравится большому количеству будущих пользователей или нет.
Но по факту решение принято за почти закрытыми дверьми, повлиять на него, кроме как участвуюя в работе комитета, у таких как я, нет возможности. Остается разве что здесь высказать свое "фи".
Это невозможно, да. Но у меня есть сомнения в том, что у комитета сейчас есть нормальная обратная связь с пользователями. Получается, что некоторая ограниченная группа людей творит то, что считает нужным, результатами их жизнедеятельности приходится пользоваться миллионам. Даже если этим миллионам не нравится то, что получается у самоизбравшихся в комитет.
Чтобы как-то повилять на принимаемые комитетом решения нужно самому вписаться в его работу. Т.е. отслеживать пропозалы, давать какую-то обратную связь, пытаться делать какие-то встречные предложения и т.д., и т.п.
У меня, например, на такое нет ни времени, ни сил, ни возможностей.
Все, что остается -- это иногда выплеснуть своё опупение от какой-то новой фичи. Типа модулей, которые кое-как собрали, впихнули в стандарт, отправили на мороз все доморощенные системы сборки и вынудили идти в обнимку к всратому CMake. При этом, по слухам от тех, кто решил попробовать это щасте, не такой уж и большой выигрыш от модулей в итоге получается.
Или вот тот же deducing this.
Можно, конечно, тихо жрать кактус молча сидя в уголке. Только это поведение тоже особо конструктивным не кажется.
Я правильно понимаю, что все, что придумывается в комитете и внедряется в C++ априори волшебно и божественно?
Может это где-то прямо в стандарте написано. Ну типа как в уставах про то, что коммандир всегда прав.
Просто часто читаю недовольство о том, во что превращается современный C++. И сам местами офигеваю от внедряемого. Если по поводу всего этого в принципе нельзя говорить ничего плохого (ну типа люди собирались, думали, тратили время и силы, спорили, дороваривались, а мы тут их известной субстанцией поливаем, твари неблагодарные), то ладно. Таковы правила игры. Дам дают бесплатно, мы жрем.
Мой метод еще и кофе не варит.
То, что deducing this послал вдоль DLL/SO -- это так, мелочь. А вот то, что CRTP, который и так не то, чтобы на каждом шагу применялся, стал чуточку лаконичнее, вот это да, достижение. Огромное спасибо с поклоном в пояс.
Заодно теперь непонятно почему нужно писать методы классов по старинке:
Если можно и молодежно:
И как объяснять новичкам почему и зачем в очередной раз в C++ одно и тоже можно сделать сильно по разному.
У меня в примере не зря стоит
decltype(*this). Так что не думаю, что что-то бы сильно потеряли бы.ИМХО, можно было бы достичь такого же эффекта не превращая C++ в Python с явной передачей self-а. Не буду повторяться, просто дам ссылку тыц (там же ссылки и на другое связанное).
К объективным претензиям по поводу deducing this добавлю то, что deducing this из C++23 на синтаксе шаблонов тупо послал в пешее эротическое DLL/so-ки. Типа у вас классы экспортируются из DLL/SO и в них есть так же самая проблема, которую решает deducing this? Это ваши проблемы, а не комитета, для C++ как для языка из стандарта, самого понятия "экспорта из DLL/SO" нет.
Проблему с рекурсивными лямбдами, которую так же затыкали все тем же deducing this, ИМХО, можно было решать как в OCaml-е с let rec.
То, что
[:плохо читается, не дело вкуса. Это уже из области эргономики.Выбор альтернативы -- это да, во многом дело вкуса.
Тогда этому большинству нужно привыкать, что известной субстанции на их головы будет выливаться все больше и больше. Если бы они делали говно для себя, это были бы их личные проблемы, сами насрали, сами пусть с этим и живут.
Но вопрос в том, что они делают язык не только для себя. Результатом их труда и обычные люди будут пользоваться.
Приведу аналогию: в математике любят использовать односимвольные обозначения, зачастую с одним-двумя штрихами и верхним или нижним индексом. В формулах это OK.
А вот когда в программе имена переменных из одного-двух символов, то читабельность такого кода будет ну такое себе. Даже если этот код касается математических расчетов. Многим из нас доводилось сталкиваться с говнокодом в котором кроме i, j, ii, jj, k, kk и т.п. ничего не используется. Причем, если такой код был написан математиками или физиками, то их это вполне может устраивать.
Ну как и большинство людей в комитете.
Я это все к тому, что в C++ начиная с 20-го стандарта (если не с С++17) появляются фичи, про которые остается сказать разве что "здорово, что эту проблему пофиксили, но почему же так всрато-то?" Начиная от std::launder в C++17, заканчивая deducing this в C++23, проходя через co_return в C++20.
Тут вспоминается ситуация, когда в C++98 нельзя было писать вот так:
A<B<C>>, нужно было обязательно делать так:A<B<C> >.И это сочли настолько важным, что в C++11 внесли изменения в язык.
Казалось бы, всего лишь синтаксис, да и проблема не сказать, что прям уж смертельная... Однако ж пришлось стандарт править.
Синтаксис получился, мягко говоря, всратый. Двойная крышка, т.е.
^^, для получения метаинформации -- в чем логика? Когда есть обычный минус-и двойной в виде декремента---- то понятно почему знак минуса переиспользуется и удваивается. Когда тильда~задействована для объявления деструктора (как "дополнение" к конструктору) -- это тоже понятно. Откуда и зачем возникло сочетание из двух крышек -- ХЗ.Но самая жесть -- это читать код с оператором "баян", т.е.
[: ||| :]. Двоеточие рядом с открывающей/закрывающей квадратной скобкой очень плохо распознается, взгляд за такие новые "скобки" не цепляется. И, если уж для рефлексии стали использовать крышки, то почему бы не быть последовательным и не сделать[^ ||| ^]или даже[^^ ||| ^^]...В итоге вроде как и сделали крутую штуку, но с таким спорным синтаксисом, что просто атас. Как будто у людей ни чувства стиля, ни чувства меры.
Например, почему бы не использовать для рефлексии символ
@?@Tвместо^^T[@ ||| @]вместо[: ||| :]Или
@уже для каких-то целей в C++ занят?Спасибо, понятно.
Для человека, который решил вынести свои идеи и свое творение на публику вы что-то слишком уж загадочны. Если это были внутренние закрытые разработки, то можно же так и сказать -- внутренние, закрытые. В общем, странное поведение.
Из описанного вами более-менее понятно чем не устраивает подход из Qt. Но чем, например, не подошли Boost.Signals2?
Могу я предположить, что из известных был Qt, а остальное было что-то доморощенное, сделанное под конкретный проект (а не что-то из Boost-а или еще чего-то OpenSource-ного)?
Вы привели свою классификацию но не названия конкретных инструментов. Можно предположить, что среди них был Qt, но по остальным остается только гадать.
Огласите весь список, пожалуйста.