Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 53

Обновлённая версия:
…
Клёво… не так ли? :)

Да не особо. Ошибся в порядке/кол-ве аргументов в constructArgs(...) и втихую получил nullptr, чтобы потом что? В рантайме на него проверять? Уж лучше static_assert втыкать
Всего голосов 5: ↑5 и ↓0+5

Да кто же ограничивает и мешает вставить static_assert в else.

Всего голосов 4: ↑3 и ↓1+2
так это же тавтология:
Пример:
template <typename Concrete, typename... Ts>
std::unique_ptr<Concrete> constructArgs(Ts&&... params) {
    static_assert(std::is_constructible_v<Concrete, Ts...>,
        "constructArgs(...) failed: Type is not constructible from args");
    return make_unique<Concrete>(forward<Ts>(params)...);
}

Комментарий пока не оценивали0
Здорово, целая статья про compile-time if! Ёжики, хватит жрать кактус (c++), переходите на тёмную сторону: в nim для этого есть просто ключевое слово when. Без всяких статей :)
Всего голосов 17: ↑1 и ↓16-15
Лучше переходите на brainfuck, у него одни плюсы (ну, и угловые скобочки с запятыми).
Всего голосов 7: ↑6 и ↓1+5
Спасибо за ультимативный аргумент! Теперь уж точно перейдем и все легаси перетащим! (нет)
Всего голосов 4: ↑4 и ↓0+4
Воу воу воу, полегче! Надеюсь, вы ещё не начали всё переписывать :) Смысл комментария был в другом: имхо невозможно усидеть на двух стульях сразу, что c++ и пытается делать — тут и совместимость сохранить надо, и фичи новые вводить. Получается монстр. Возможно, в один прекрасный момент вы захотите для вашего нового проекта попробовать что-то более продуктивное, с пакетным менеджером, с макросами, которые оперируют над AST (а не тупо подстановка), ну и с возможностью compile-time evaluation из коробки.
Всего голосов 6: ↑2 и ↓4-2
Тёмная — это потому что из-за тормозов приходится до поздна сидеть?
Всего голосов 4: ↑4 и ↓0+4
Я правильно понял, что if constexpr гарантирует что условие развернётся на этапе компиляции? С другой стороны как контролируется «разворачиваемость условия» во время компиляции.
Всего голосов 2: ↑2 и ↓0+2
Так и развернётся. Ложная ветка не будет компилироваться, примерно как #ifdef… #else… #endif.
Комментарий пока не оценивали0
Если не развернётся, будет выброшена ошибка компиляции, что нельзя на этапе компиляции это вычислить.
Если нельзя гарантировать — просто не скомпилируется. А про constexpr выражения в стандарте есть описание того, что им может быть — это и есть гарантия
Всего голосов 2: ↑2 и ↓0+2
Читать чужой плюсовый код станет еще более увлекательно.
Комментарий пока не оценивали0

Вопрос от дремучего непрофессионала. А зачем вообще нужно "шаблонное метопрограммтрование", и как часто всплывают кейсы, где без него никак? Вот именно никак, т.е. не решить задачу по другому. И пример, если можно) для общего образования.

Всего голосов 4: ↑1 и ↓3-2
Ну конечно можно решить, всё можно решить и тупо на асме или брэйнфаке, вообще на любом тьюринг полном языке. Вопрос в удобстве такие фичи как compile time if даёт богатый простор для оптимизации при этом упрощая синтаксис.
Комментарий пока не оценивали0
Я не умоляю устремлений людей придумывающих такие фичи, мне правда интересен кейс) Я смотрел лекции техносферы по С++, там упоминались такие вещи. Личной мой инструментарий С++ заканчивается на, скажем так, совсем базовой инкапсуляции.

мне правда интересен кейс
Всего голосов 2: ↑0 и ↓2-2
Самое простое это патерн матчинг для типов, различные конвертации и серилизации, работа с биндингами по типу буст питона, упрощение работы с контейнерами и ещё куча кейсов но более специфичных тип внедрения зависимостей, автоматов и тд.
Всего голосов 1: ↑1 и ↓0+1

Спасибо. Теперь есть от чего оттолкнуться для подробного гугления.

Комментарий пока не оценивали0
Очень много абстракций на таком уровне программирования, к сожалению нужно вникать, конечно все понятно, но на это уходит время и это печально)
Комментарий пока не оценивали0
Не знаю, но мое мнение человека с гуманитарным образованием, что если для скрипки варианта 17 нужно для одной ноты смычок обычной формы ( обычный if ) а для другой ноты смычок с бетонным подвесом ( if constexpr ), то возникает вопрос, а что на ней собственно такое можно сыграть, чтобы идти на такие жуткие мучения. Я конечно понимаю, что если бы это сделало путешествие на Луну из невозможного простым и обыденным. Тут как говорится будем грызть метал и constexpr. Но вот так, чтобы элементарно проверять тип данных из того же Reflection только под иным синтаксисом…

Я не того уровня специалист, чтобы указывать дорогу мастерам творящим С++. Так что извините, если мои сомнения выглядят как упражнения доморощенного Фомы не верующего, но мне кажется что что — то тут не совсем так.
Всего голосов 2: ↑0 и ↓2-2
Это не две разные ноты. Если в рамках вашей аналогии if — это смычок для ноты, то if constexpr — это ручка для рисования нот.
Всего голосов 1: ↑1 и ↓0+1
Вы хотите сравнить наше умение играть на скрипке или писать музыку?

Если я говорю, что это нота, то это нота. Пишите о том, что Вы знаете.

Вообще, три ответа на мой в общем — то очень скромный вопрос дилетанта наводят на мылси о некоем групповом предприятии. Больно много эмоций и полное отсутствие технических деталей. Я бы даже сказал необычно много эмоций и они, эмоции, какие — то все острые. Не пойму… что так уж защищают, вроде очень уважительно написал все.
Всего голосов 4: ↑0 и ↓4-4
Пишите о том, что Вы знаете.

А вот если бы вы следовали тому, что проповедуете, то вы бы в треде про constexpr не отписывались.
Всего голосов 3: ↑3 и ↓0+3
Я прошу прощения, но фальшивые ноты в музыке программисту не грех заметить.

А повышенные тона программистов по поводу constexpr выдают то, на сколько это ошибочное нововведение. Нормальное «if» с таким огнём защищать не потребовалось бы.

То есть на лицо не только оголтелая лажа, но и не способность людей принадлежащих к роду деятельности адекватно воспринимать доброжелательную критику.
Всего голосов 2: ↑0 и ↓2-2
Проблема всех аналогий — в том, что местами они подобны котенку с дверцей.

Замеченное вами «повышение тона программистов» вызвано исключительно тем, что вы пытаетесь использовать неуместную аналогию. Оператор if constexpr не является смычком с бетонным подвесом, только и всего. И нет ничего удивительного в том, что на эмоциональный аргумент вы получаете эмоциональные ответы.
Всего голосов 1: ↑1 и ↓0+1
if constexpr и if в общем случае не являются взаимозаменяемыми. Это разные инструменты для разных задач. Не надо пожалуйста говорить что пианино — громоздкая гитара
Всего голосов 1: ↑1 и ↓0+1
«Не надо пожалуйста говорить что пианино — громоздкая гитара»
— Не говорил.
«Это разные инструменты для разных задач.»
— Как бы так это, хоть одним глазком в замочную скважину подглядеть, где этот новый инструмент блеснул своим «лаком» :)
Всего голосов 1: ↑0 и ↓1-1
Как бы так это, хоть одним глазком в замочную скважину подглядеть, где этот новый инструмент блеснул своим «лаком» :)

глядите сколько влезет
Комментарий пока не оценивали0
Судя по тому, что Вы предложили, с лаком у constexpr не очень.
Всего голосов 1: ↑0 и ↓1-1
в реализациях STL повсеместно используются всякие is_standard_layout/is_trivially_copyable/is_noexcept_movable/… Они позволяют выбирать наиболее эффективный алгоритм в зависимости от свойств типов шаблонов. Без if constexpr такие ветвления реализовать можно, но многократно большим объемом кода. Другой пример — асинхронный API с выбором реализации для функций, возвращающих T/void.

Для оценки полезности инструмента надо как минимум понимать его назначение. Подозреваю, у вас не было опыта написания более-менее сложного обобщенного кода.
Комментарий пока не оценивали0
«но многократно большим объемом кода»
— посмотрите дальше. Там есть разбор 3х примеров, из которых в 2х случаях сокращение объёма кода имело критически негативные последствия для его выразительности. То есть вместо понимания «языка» надо понимать скрытое понимание некоего секретного слова. Это называется не «опыт» а «цеховщина».

Дело не в том, что у меня мало опыта. Дело в том, что я вижу огромное давление на инженеров воспринять новые в прямом смысле слова выкрутасы, созданные неким заокеанским сообществом, не критично, не задавая вопросов и не осмысливая представленное. А работа их заокеанских коллег вызывает огромное количество более чем адекватных вопросов.
Всего голосов 4: ↑0 и ↓4-4
вы же не можете всерьез думать что диспатч через перегрузку шаблонной функции через enable_if более читаемый и внятный, чем через if constexpr?
Всего голосов 2: ↑2 и ↓0+2
Вот был бы он не const, а context, тогда делайте с ним что хотите. А так как он const, то он должен быть прост и постоянен. Функционал один, а слово другое.
Всего голосов 2: ↑0 и ↓2-2
НЛО прилетело и опубликовало эту надпись здесь
Спасибо, очень дельный пример №1. Не знаю, может я становлюсь старым, но вот левый вариант мне нравится больше, чем правый. Он может и длиннее, но он как — то больше похож на рассказ на С++.
Всего голосов 1: ↑0 и ↓1-1
Пример №2 интересный. Буду учить, спасибо.
Комментарий пока не оценивали0
Пример №3 для меня был очень познавателен. Наверное, если так удобно, то как — то так работает. Но если не знаешь, и просто смотришь со стороны, то левая версия выглядит как будто в ней тоньше ухвачены детали. Нет?
Всего голосов 1: ↑0 и ↓1-1
Если позволите, огромное спасибо. Пример №2 меня заинтриговал.
Комментарий пока не оценивали0
эта и подобные фичи появляются в стандарте потому, что они нужны. И нужны они не вам. Возможно даже, что и не авторам библиотек, которыми вы пользуетесь. Скорее авторам какого-нибудь boost::python. Подумайте об этом в следующий раз когда будете писать что-нибудь типа import pyopencl.
Всего голосов 3: ↑3 и ↓0+3
Тут не только тип данных, метапрограмирование это довольно обширный класс задач, с помощью if constexp вы можете примерно в одном и том же контексте работать с совершенно другим типом при этом имея 0 оверхед (что никак не получится при runtime reflection) т.к все проверки происходят ещё на этапе компиляции.
Комментарий пока не оценивали0
0 оверхед очень дорогая вещь. Это имеет смысл для изменений уровня «полетим / не полетим на Луну». Подобные внедрения в код есть, например, в ядре обработки криптографических примитивов. Обычно их выполняют пользуясь расширением ассемблера asm {}.

Что касается templates и constraints, и далее метаданных и их проверки reflection, то Вы оцениваете оверхед через призму приземленного «а мне так кажется» пользователя, с целью оправдания сырого нововведения. Если это для «можно поспорить» точки зрения, то это конечно приемлемо. Но с точки зрения детального понимания runtime, то reflection так же неизбежен как смерть и налоги, без него просто нельзя. И в этом случае тривиальный запрос по верификации типа, это одна инструкция сравнения метаданных, которая в любом случае должны быть сделана. То есть для достаточно продвинутого компилятора это всего лишь вывод в стэк индикатора, считывающего результат целостности данных. То есть это 0 оверхэд в любом случае. Понимаете. Выигрыша нет. Зато язык стал сложнее. Вот в чем дело.

Может в этом нововведении есть какое — то зерно, которое мне не понятно. Вот об этом и был мой вопрос. Что — то о «полете на Луну». Именно это я и спросил. Если это есть, то пожалуйста, покажите.
Всего голосов 3: ↑0 и ↓3-3
И в этом случае тривиальный запрос по верификации типа, это одна инструкция сравнения метаданных, которая в любом случае должны быть сделана.

Зачем делать это сравнение если его можно сделать на этапе компиляции? К тому же, это не только сравнение типов это и выбор дальнейшего алгоритма, что раньше делалось либо через специализацию либо через SFINAE что выглядит монструозно.
Зато язык стал сложнее. Вот в чем дело.

Вы серьёзно считаете что if constexpr делает код сложнее для чтения чем специализации или SFINAE? Вам наверно и лямбды не нравятся. С++ живой язык он развивается, и появляются конструкции которые сильно облегчают написание кода конечно при этом сам язык становится сложнее, потому что он даёт больше возможностей, но говорить что if constexpr не нужен, это всё равно что признаться что вы никогда не писали ничего сложного на шаблонах.
Комментарий пока не оценивали0
Зачем делать это сравнение если его можно сделать на этапе компиляции?


Дело не в этом, дело в том что Вы не совсем понимаете о чем идет речь. Учите матчасть.

Вы серьёзно считаете что if constexpr делает код сложнее для чтения


Усложнение кода не проблема сама по себе. Перечитайте ещё раз, я написал вполне доходчивую логичную фразу «Выигрыша нет. Зато язык стал сложнее.»

Насчет лямбда выражений, это очень интересная параллель, и я сам не решался её начать, поскольку она может открыть совершенно отдельную дискуссию, суть которой, как сделать расширение языка С++ в шаблоны лучше/правильно, а не сырым constexpr. Если позволите, она заслуживает отдельный ответ.
Всего голосов 3: ↑0 и ↓3-3
Дело не в этом, дело в том что Вы не совсем понимаете о чем идет речь. Учите матчасть.

Ну да, я тут извращаюсь с шаблонами и макросами чтобы впендюрить такую фичу только потому что не могу использовать if constexpr
succes = patern_match val
		with_cast(const std::vector<int>& items)
		{
			for (auto&& val : items)
				std::cout << val << ' ';
		}
		with_type(int x)
		{
			cout << "some int " << std::to_string(x) << '\n';
		}
		with_cast(const std::string& str)
		{
			cout << "some str " << str << '\n';
		}
		at_default
		{
			cout << "oops";
		};

А тут приходите вы и говорите что if constexpr не нужен и что мне вообще нужно учить матчасть. Ну спасибо вы мне прям глаза открыли.
Пока что, судя по диалогу с вами я могу лишь сделать вывод, что вы либо не достаточно компетентны (Эффект Даннинга Крюгера) либо троль, в любом случае общение с вами мне пользы не принесёт.
Всего голосов 2: ↑2 и ↓0+2
НЛО прилетело и опубликовало эту надпись здесь
Прошу прощения, это нельзя объяснить комментарием на форуме. Учите матчасть.
Всего голосов 4: ↑0 и ↓4-4
НЛО прилетело и опубликовало эту надпись здесь
Да бросьте Вы. Пробежался вчера по поисковику, чтобы сбросить что ни — будь похожее на эксплуатационные данные runtime с пояснением, почему там рефлекшн, и ничего не нашел. Нашел докторскую диссертацию 1972-го года американского профессора информатики ( computer science ) и несколько, не очень убедительных постов в различных форумах, типа stackoverflow.com. Никто не хочет связываться с объяснением что за чем и почему. И тем не менее, за исключением старых библиотек, которые никто не хочет трогать по разным причинам, ни одна из которых не является творческой, все современные runtime работает с рефлекшн. Поэтому к сожалению я вынужден последовать тренду всей компьютерной индустрии и утверждать по принципу «потому, что так делают все». Думаете мне это нравится… Интуитивно я могу попробовать собрать вместе аргументы «за». Но матчасть настолько многообразна, что всегда найдется ещё больше против. И тем не менее это факт. Если Вы возьмете индустрию в разрезе, то все операционные системы выпущенные в последние 5 лет имеют runtime, который обязательно выполняет интроспекцию и учет сущностей созданных тем или иным выполнимым. Не смотря на мой уклончивый ответ, он тем не менее, верен.
Всего голосов 3: ↑0 и ↓3-3
НЛО прилетело и опубликовало эту надпись здесь
Рефлекшн сам по себе многолик. Он включает как интроспекцию и аудит, так и возможности манипулирвоания сущностями. Спор по теме ограничен функциями интроспекцией и аудитом. Эти функции обязательны даже для процесса «system» с 2013-го года. Их отключение возможно, но машина не пройдет сервис. И потом даже отключив эти функции, чтобы протестировать тот или иной модуль прошивки, отчет о запущенном выполнимом и сбор информации о сущностях, которые он создал, остановить нельзя. Это неотделимая часть runtime. Я не знаю если эти глубинные функции ОС реализованы на уровне аппаратной поддержки. Но если отталкиваться от тренда, то это похоже так.
Всего голосов 3: ↑0 и ↓3-3
НЛО прилетело и опубликовало эту надпись здесь
Откройте регистр процессов и посмотрите, там процесс «system» хорошо видно. Прошивка это то, что по Английски называется firmware. То есть я пытаюсь пояснить, что если раньше инспекция сущностей были частью выбора пользователя, выбирающего тот или иной язык и, как Вы заметили, дезайн, ситуация изменилась и теперь рефлекшн, функции инспекции сущностей, это часть машины. То есть в нем нет оверхед. Есть просто языки, в которых исторически так сложилось, что к её возможностям нет доступа. В С++ они есть.
Всего голосов 3: ↑0 и ↓3-3
НЛО прилетело и опубликовало эту надпись здесь
Вот процесс в управляющем процессами.

К прошивке и корневому процессу отношение очень простое. Если раньше они не участвовали в интроспекции и это было частью выбора архитектуры, то с 2013-го года они сами ей подвергаются, с самого старта, и естественно, обеспечивают то же самое для всего, что только запускается на машине. Неужели не понятно?

Именно, часть машины, неотделимая от неё. Да, эти функции можно ослабить, но не выключить, это первое. И во вторых, машину работающую с такими опциями не возьмут обслуживать в сервис, поскольку эти опции не поддерживаются, ну и в третьих, это бессмысленно, поскольку runtime все одно выполнит интроспекцию. Мало того, видимо есть аппаратная поддержка, поэтому даже если Вы на линуксе, отсутствие интроспекции на машинах пост 2013-го года от импортных вендоров нельзя гарантировать.
Всего голосов 4: ↑0 и ↓4-4
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время
Разблокировать темную тему

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr