Почему С++ отстой до 2020 года

Это не холиварная тема, здесь мы не спорим, какой язык лучше!

Ну что, недавно собирался комитет стандартизации, который обсуждал будущее - С++17. И в итоге? Что же будет добавлено в столь долгожданный стандарт после релиза С++14, который был минорым и лишь доводил до ума фичи С++11?

1) Параллелизм (STL)
2) Файловая система
3) ... Вы думали, что будет еще что-то? Да нет, из фич, которые как-то заметно влияют на разработку, это все. Это все, Карл!

Концепты - пфф, нам и так хорошо - родные и уродливые длинные сообщения об ошибках в шаблонах, а также безобразная магия enable_if в SFINAE, - чего еще желать?
Диапазоны? Можно расслабиться, они без концептов не работают. И Слава Богу, а то пришлось бы осиливать столь сложную вещь!
Модули? Ну ребят, у нас и так все быстро компилируется, особенно если буст подключить. Не зажируем ли? И да, cmake куда лучше пакетного менеджера!
Конкурентность? Дык кто не пишет на низкоуровневых примитивах, тот неосилятор!
Сети, корутины? Кого волнует, идите-ка вы на ...буст.
Рефлексия, контракты? Да зачем? Без них куда проще жить, юзать нечитабельные либы и писать велосипеды!

В общем, С++17 я бы точно не назвал мажорной версией стандарта, поскольку НЕ ВИЖУ, КАКИЕ РЕАЛЬНО НАСУЩНЫЕ ПРОБЛЕМЫ ОН РЕШАЕТ. А сколько шуму-то было после С++11/14! И это печально, потому что следующего шага после С++11 приходится ждать 10 лет, а конкуренты не дремлют.

Почему так получилось? Ну потому что С++ слишком сложен, а поэтому добавление или исправление вещей, которые реально нужны и важны занимают слишком много времени и усилий.

На рынке С++ по-прежнему будет скатываться в свои ниши - в ниши, где производительность критична.
А С++ разработчики по-прежнему будут жить с С++ без удовольствия, частенько похаживая на сторону к другим языкам.

У меня все. Если кто-то хочет меня дополнить, исправить, или просто выразить свое мнение и послать в дальние места - велкам!

1

Сообщение от hoggy или что override костыль, потому что можно?

Костыль - то, что override и final не являются ключевыми словами.

Сообщение от hoggy о каких таких неудобствах идет речь?

Особенности вывода типа при использовании auto и фигурных скобок; использование одной и той же по виду конструкции (список значений через запятую, заключённый в фигурные скобки) для двух разных вещей (создание initializer_list и перечисление аргументов конструктора), имеющих к тому же сходное назначение. До C++14 даже размер initializer_list нельзя было узнать в compile-time. Вот если бы фигурные скобки были литералом, создающим tuple, которая являлась бы частью языка, путаницы не было бы, получилась бы единая сущность. Почему так не сделали? Чтобы не нарушать совместимость с существующим кодом. Если кому-то хочется высказаться на тему, что библиотечный tuple ничем не хуже, пусть вспомнят о том, каково этот tuple раскрывать (например, передать содержимое в функцию как список аргументов).

Сообщение от hoggy при чем здесь легаси? в чем костыльность?

Зависимость языковой конструкции от библиотеки или "волшебных" имён - костыли. Легаси при том, что такое поведение, видимо, в первую очередь потребовалось для совместимости range-based for с массивами.

Сообщение от hoggy не привязана.

Ну хорошо, не привязана к библиотеке, но привязана к "волшебным именам". Тоже костыльно, особенно весело получается, если в текущей области видимости определены свои функции begin и/или end.

Сообщение от hoggy я не знаю никаких ни "range же", ни Эриков Нилберов.

В таком случае рекомендую найти и посмотреть выступление Александреску под названием Iterators must go, там коротко и по сути объясняется, почему надо перейти от итераторов в их текущем виде к диапазонам.

Сообщение от hoggy мне не понятно, что такое "вне-языковые конструкции". это какой то бред. любая валидная с точки зрения языка конструкция является "языковой" по отношению к нему.

Постарайтесь поменьше сыпать оскорбительными выражениями о лжи, глупостях и бреде. Препроцессор и его директивы не являются частью языка, ни Си, ни C++, поэтому все макросы, прагмы, директивы включения файлов и прочее - вне-языковые конструкции. Как следствие, они обрабатываются независимо от языковых правил (самый частый пример: макросы плевать хотели на namespace). Когда-то это было технической необходимостью и удобством, но семидесятые уже прошли, а препроцессор остался и от него уже никуда не деться с такой-то кодовой базой.

Сообщение от hoggy он не добавляет никаких новых проблем. мы прекрасно живем с препроцессором сегодня.

Расскажите про это человеку, который программируючи под windows случайно назвал в своём классе метод SendMessage.

Сообщение от hoggy я специально привел виндузятную прагму что бы проиллюстрировать вам: модулям он так же не помеха.

Модули - это одно из средств, которые могли бы в отдалённом светлом будущем позволить уйти от препроцессора (а именно, от директивы #include).
Модуль - это гораздо больше, чем просто подключение статической библиотеки. По замыслу, модули должны содержать предварительно обработанный текст (нечто вроде precompiled headers, но в более удобной форме): готовые к использованию определения типов, шаблоны и всё такое прочее. То, во что компилятор сейчас снова и снова преобразует заголовочные файлы в каждой единице компиляции. Так что не надо тут рассказывать про прагму и выставлять её как какой-то "факт". Она вообще не имеет отношения к вопросу о модулях и препроцессоре.

Сообщение от hoggy и это работает.

Сегодня у кого-то работает, а завтра у компилятора появится новая оптимизация и работать перестанет. Использование UB только для того, чтобы избежать применения шаблонов - опасная практика и бессмысленный риск. Убедительным аргументом в пользу чего бы то ни было этот "фокус" тоже не является.

Сообщение от hoggy и почему это все таки выбирают плюсы?

Уж точно не из-за того, что там можно использовать C-style cast и сырые указатели.

Сообщение от hoggy с++ развивается, и предлагает не менее эффективные, но более развитые решения. что весьма красноречиво опровергает ваш тезис, что якобы мифическое легаси и костыли не дают языку развиваться.

Во-первых, эти "более развитые решения" не приводят к отказу от старых, недоразвитых и опасных. Легаси же рухнет.
Во-вторых, факт того, что у языка есть серьёзные проблемы с развитием, очевиден. Достаточно посмотреть на список всего того, что обещали в C++17 и что туда не вошло.

Сообщение от hoggy я не давал субъективных оценок. мои тезисы справедливы независимо от меня, и моего мнения. я понятия не имею кто такой Брайт. и понятия не имею, на кой черт вы сюда сейчас Александресску припахали.

Утверждение о том, что я глуп и что язык D представляет из себя одну лишь глупость - объективный и справедливый тезис? Ну и самомненьице у вас. Особенно учитывая уровень вашей информированности (JFYI: Уолтер Брайт - изобретатель и ведущий разработчик языка D, Андрей Александреску - ведущий разработчик этого языка).

Сообщение от hoggy мозговзрывающее упражнения случается по причине "функциональной парадигмы", которую исповедуют классические шаблоны.

В первую очередь мозговрзывательность происходит из-за того, что метапрограммирование выполняется на побочных эффектах, а не на явно предназначенных для этого конструкциях. Когда имеются явные конструкции (те же constexpr-функции), всё в порядке.

Сообщение от hoggy здесь можно сколько угодно ругать "громоздкость" дизайна классических шаблонов, однако, ни один из хейтеров пока ещё не смог предложить более годный дизайн,

Проблема не в дизайне шаблонов, а в том, что он замышлялся для других целей, и что вместо введения чётких конструкций языка пользуются побочными эффектами как будто так и надо, и даже в стандартную библиотеку запихивают неудобоваримые в использовании обёртки вроде enable_if и conditional.

Сообщение от hoggy из всего вашего текста я сумел разглядеть только два весьма не конкретных примера:

Это скорее ваши трудности с чтением и восприятием, чем мои. Замечу, что у меня претензии не к шаблонам как таковым, а к метапрограммированию на побочных эффектах (точнее - к отсутствию в языке интенциональных конструкций для выполнения этих задач).

Сообщение от hoggy причем ни то, ни другое никак не мешают развиваться языку.

Ага, то-то концепты уже мимо третьей версии стандарта пролетают как Анри Фурнье над Парижем.

Сообщение от hoggy вот таким мог бы быть грамотный пример костыльного-легаси:

Ну раз вы сами себя способны развлекать грамотными примерами, зачем их от меня требуете? Или свои примеры "несчитово" и не костыльно?

Добавлено через 10 минут

Сообщение от TheCalligrapher Но сейчас это явление достигло такого гигантского размаха

Да, действительно, с new уже особый случай, но с другой стороны - он и сам по себе особый. Но всё же действительно.
Насчёт гигантского размаха не соглашусь, пока что всё ещё достаточно скромно и цивильно, пара-другая случаев. Однако тенденция (и, по-моему, тревожная тенденция) налицо.

3

Сообщение от Nick Alte Если кому-то хочется высказаться на тему, что библиотечный tuple ничем не хуже, пусть вспомнят о том, каково этот tuple раскрывать (например, передать содержимое в функцию как список аргументов).

Кое-что в C++17 для упрощения работы с tuple должны ввести:
http://www.open-std.org/jtc1/s... 0144r0.pdf
хоть таких примеров там не приводится, но надеюсь можно будет и при передачи в функцию подобным образом раскрывать кортежи.

0

Сообщение от S_el при передаче в функцию подобным образом раскрывать кортежи

Без поддержки на уровне языка (если не tuple, о чём и говорить, к сожалению, не приходится, то хотя бы усовершенствованных variadic template) так просто не получится. Либо надо ограничиваться вспомогательными конструкциями для раскрытия, либо вводить ещё больше "волшебства". К тому же, сомневаюсь, что этот proposal утвердят, сырой он какой-то. Но не будем терять оптимизма, может и решат проблему в другом proposal.

0

Сообщение от Nick Alte К тому же, сомневаюсь, что этот proposal утвердят, сырой он какой-то. Но не будем терять оптимизма, может и решат проблему в другом proposal.

Нашел альтернативу:
http://www.open-std.org/jtc1/s... 0151r0.pdf

0

Сообщение от S_el Нашел альтернативу:

Интересное предложение, любопытное нетрадиционное использование угловых скобок. Туда бы ещё раскрытие как-то присобачить, а не только множественное объявление... Например, обратным порядком скобок вроде , и идеал написания кода смайлами станет ближе

0

Сообщение от Nick Alte Костыль - то, что override и final не являются ключевыми словами.

почему?
какое это имеет значение на практике?

Сообщение от Nick Alte Особенности вывода типа при использовании auto и фигурных скобок;

приведите пример.

Сообщение от Nick Alte Зависимость языковой конструкции от библиотеки или "волшебных" имён - костыли.

почему?

Сообщение от Nick Alte Легаси при том, что такое поведение, видимо, в первую очередь потребовалось для совместимости range-based for с массивами.

это не принципиально.

принципиально, что выше вы заявили:

Сообщение от Nick Alte Боюсь, что для этого уже поздно. Точка невозврата давно пройдена. Ради обратной совместимости уже нагорожено несколько слоёв костылей, одно тянет за собой другое, поддерживать приходится не только совместимость с Си, но и с предыдущими версиями стандарта, так что малой кровью выпутаться не получится.

как range-based for вообще коррелирует с этим высказыванием?

Сообщение от Nick Alte Ну хорошо, не привязана к библиотеке, но привязана к "волшебным именам". Тоже костыльно

честно говоря, мне надоедает задавать вам каждый раз один и тот же вопрос:
"почему?"

вы вообще в состоянии предоставить аргументированный ответ?
ваше голословное "бла бла бла" как то не очень интересно.

Сообщение от Nick Alte особенно весело получается, если в текущей области видимости определены свои функции begin и/или end.

проиллюстрируйте проблему.

и когда я пишу "проиллюстрируйте", то я имею ввиду кодом.
например здесь:
http://rextester.com/l/cpp_online_compiler_gcc

могу заранее вам сказать,
что никаких проблем со своими личными begin/end
в этой ситуации не будет.

Сообщение от Nick Alte В таком случае рекомендую найти и посмотреть выступление Александреску под названием Iterators must go, там коротко и по сути объясняется, почему надо перейти от итераторов в их текущем виде к диапазонам.

спасибо
*сделал пометку в блокнотике*

Сообщение от Nick Alte Модули - это одно из средств, которые могли бы в отдалённом светлом будущем позволить уйти от препроцессора (а именно, от директивы #include). Модуль - это гораздо больше, чем просто подключение статической библиотеки. По замыслу, модули должны содержать предварительно обработанный текст (нечто вроде precompiled headers, но в более удобной форме): готовые к использованию определения типов, шаблоны и всё такое прочее.

совершенно верно.

Сообщение от Nick Alte Так что не надо тут рассказывать про прагму и выставлять её как какой-то "факт". Она вообще не имеет отношения к вопросу о модулях и препроцессоре.

я опустил деталь про precompile header, как несущественную.
ну ок.

создайте проект с предварительно скомпилированным заголовком.
закидайте туда всяких заголовков, макросов, любой ботвы,
и в конце впишите прагму.

и о боже! оно работает!
и макросы ему внезапно работать не мешают.
факт.

Сообщение от Nick Alte Использование UB только для того

да не нужно мне объяснять нюансы эксплуатации UB.
я просто привел вам пример "проблемы препроцессора".
который наглядно иллюстрирует:
такая проблема существовала всегда.

но на практике как это это жить никому не мешает.
и модулям палки в колеса не вставит.

Сообщение от Nick Alte Уж точно не из-за того, что там можно использовать C-style cast и сырые указатели.

я б ещё понял фразу в духе:
"из-за прямой работы с памятью, что позволяет писать эффективные..."

но это - деццкий сад какой т.

Сообщение от Nick Alte Во-первых, эти "более развитые решения" не приводят к отказу от старых, недоразвитых и опасных.

ну и что?

Сообщение от Nick Alte Во-вторых, факт того, что у языка есть серьёзные проблемы с развитием, очевиден. Достаточно посмотреть на список всего того, что обещали в C++17 и что туда не вошло.

так никто ж и не отрицает.
однако с чего вы взяли, что проблема именно с легаси?

Сообщение от Nick Alte Утверждение о том, что я глуп и что язык D представляет из себя одну лишь глупость - объективный и справедливый тезис?

я не утвержда, что D представляет из себя одну лишь глупость.
не нужно приписывать мне то, что я не сообщал.

я писал:

Сообщение от hoggy видимо вы не отдаете отчета в том, какую глупость сморозили. взгляните на язык "D": глупость в действии.

и это - объективное суждение,
которое опирается на реальную ситуацию с языком D.

язык D изначально задумывался, как прямой поток языка с++,
в котором должны быть учтены недостатки предшественника.

то бишь, "как с++, только более совершенный и продуманный".
с точки зрения дизайна, язык D действительно неплох.

однако его создатели совершили две фатальные ошибки:

1.
во имя синтаксического сахара,
пренебрегли священной коровой с++ - эффективностью.

2.
и это уже фатально:
пренебрегли обратной совместимостью с с++

какой изначально должна была бы быть целевая аудитория "улучшенного с++" ?
очевидно жеж - программисты с++.

но отсутствие обратной совместимости с языком с++
воспрепятствовало массовому исходу программистов на язык D.

а отсутствие профита в плане перфоманса - сделало неочевидным сам мотив такого исхода.

в результате язык D, при всей своей "улучшенности" оказался мертворожденным - невостребованным.

это - объективный факт.

а вот вам другой объективный факт:
хитрый Страуструп понимал, что его клиенты - сишники.
и специально так все подстроил,
что бы максимально облегчить переход с сишки на плюсы.
и вот вам результат - массовый исход в масштабе всей Индустрии.

Сообщение от Nick Alte В первую очередь мозговрзывательность происходит из-за того, что метапрограммирование выполняется на побочных эффектах, а не на явно предназначенных для этого конструкциях.

бред.

Сообщение от Nick Alte Проблема не в дизайне шаблонов, а в том, что он замышлялся для других целей, и что вместо введения чётких конструкций языка пользуются побочными эффектами как будто так и надо

так вы определитесь: у них есть проблема с дизайном, или нет?
потому что первая часть предложения противоречит 3й.

и вы честно говоря достали уже со своими побочными эффектами.
да, именно так и нужно.

я повторюсь:
ещё ни один хейтер шаблонов не смог предложить хотя бы просто идею годной альтернативы.

Сообщение от Nick Alte Это скорее ваши трудности с чтением и восприятием, чем мои. Замечу, что у меня претензии не к шаблонам как таковым, а к метапрограммированию на побочных эффектах (точнее - к отсутствию в языке интенциональных конструкций для выполнения этих задач).

вот если бы вы хотя б 1 пример привели вот этой самой "интенциональных конструкции",
тогда я б согласился - да, пример есть.
и этот пример можно было бы рассмотреть.

но у вас я вижу только голословное бла бла бла.
а не примеры.

вы функциональное программирование "побочными эффектами" обозвали.
это все, что я пока от вас в плане шаблонов смог добиться.

Сообщение от Nick Alte то-то концепты уже мимо третьей версии стандарта пролетают как Анри Фурнье над Парижем.

ага. и при этом они уже хз сколько времени доступны для gcc
а эти ваши модули - доступны для вижуал студийного компилятора.
и что?

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

Сообщение от Nick Alte зачем их от меня требуете?

я ничего от вас не требую.

мне просто любопытно было:
понимали ли вы на самом деле смысл собственного тезиса.
или так просто - не подумавши брякнули.

1

hoggy, на следующем заседании будут решать, включать ли в С++17 constexpr if (наподобие static if).
Однако, в отличие от static if в D, у constexpr if есть ограничения:
1) только внутри block scope
2) только внутри шаблонов
3) всегда создает новый scope
4) нужно, чтобы все ветки до инстанцирования были компилябельны.
Короче говоря, constexpr if позволяет в зависимости от условия не инстанцировать определенные ветки внутри шаблона.
Я так помню, ты этого хотел? Или нет?

0

Сообщение от ct0r Я так помню, ты этого хотел? Или нет?

нет.
пункт 4 делает такой статик_иф бесполезным чуть менее, чем полностью.

0

Сообщение от hoggy нет. пункт 4 делает такой статик_иф бесполезным чуть менее, чем полностью.

Ну что сказать...

The "controversial" parts of N3329 are that: 1) it does not introduce a new scope, and 2) the non-selected branch is completely ignored (the tokens aren't even required to be parseable) This makes it fundamentally incompatible with the template model used by at least two major implementations. If, instead, it introduced a new scope (as proposed in this thread) and we had a requirement that it is possible to instantiate each arm of the static if (that is, the same requirement we have for other token sequences in templates), then I believe the over-my-dead-body objections from implementors would disappear.

0

Сообщение от ct0r а рынке С++ по-прежнему будет скатываться в свои ниши - в ниши, где производительность критична.

На самом деле он в другую нишу скатывается - в ту нишу где разработчику обязательно нужны мозги и понимание как комп вычислит. На самом то деле C++ никуда не скатывается, и даже размер ниши растет. Другое дело в том что сам рынок растет гораздо быстрее, при этом очень быстро растет ниша в которой разрабу думать и знать особо не обязательно, нужно формы клепать и что нить с вектора в вектор гонять при этом ничего не покрешив, даже при отсутствии понимания что он делает.

1

Сообщение от ct0r Ну что сказать...

пельчка, чо.


зачем вообще нужен статик_иф ?

что бы привычном для нубья, императивным образом
выбирать какую ветку нужно компилировать.

в теории, киллер-фича такого подхода в том,
что это может быть альтернативной SFINAE.
которая при всех возможностях СФИНЬИ,
позволяет сохранить простоту и читабельность кода.

но если статик_иф требует компилябельности нафик не упавших веток,
значит оно лососнет по полной,
ведь СФИНЬЯ для того и используется,
что бы отсекать нежизнеспособные ветви.

а значит, спецы по прежнему будут пользовать СФИНЬЮ.

а всякие неосиляторы плакать, и жаловаццо:

Сообщение от Nick Alte метапрограммирование выполняется на побочных эффектах, а не на явно предназначенных для этого конструкциях

0

Вообще сейчас в индустрии формируется такой стереотип что C++ - это только для "крутых". Но ведь дело не в том что для того чтобы эту дикую лошадь С++ объездить способности вдруг стали выше. Нет C++ в принципе каким был таким и остался. Просто особенно с появлением визуальной разработки появились более другие пони, которые могут объездить те кто С++ не осилил. Это не значит что задач под C++ стало меньше. Просто общее количество задач выросло.

Сообщение от ct0r НЕ ВИЖУ, КАКИЕ РЕАЛЬНО НАСУЩНЫЕ ПРОБЛЕМЫ ОН РЕШАЕТ

Вот в том то и оно. А насущно на сегодняшний день на уровне стандарта - делегаты, свойства, RTTI, указание в хидере с чем линковать (причем де-факто в разных диалектах эффективные решения существуют уже как минимум 20 лет). Кстати те разработчики у которых в диалекте C++ эти расширения есть, в стороны никаких других языков не смотрят. Еще хорошей фишкой будет введение арифметики над массивами, потому как процессоры стали векторными, и без непосредственного указания со стороны программиста что он именно хочет с массивом сделать на основании того что он делает с элементами угадывать оптимизатору все сложнее и сложнее.
Естественно комитет все это тормозит, хотя бы потому что на самом деле является отделом по сбыту фирмы Dinkumware, а введение таких штук в стандарт означает что кое что из STL придется почекрыжить за ненадобностью.

0

hoggy, можешь привести пример, где по-прежнему нужно будет использовать sfinaе вместо концептов+constexpr if?

Сообщение от Fulcrum_013 в ту нишу где разработчику обязательно нужны мозги и понимание как комп вычислит

Ну это много где нужно.

Сообщение от Fulcrum_013 такой стереотип что C++ - это только для "крутых"

Не знаю, не встречал такого. Да и неправда это.

Сообщение от Fulcrum_013 Просто особенно с появлением визуальной разработки появились более другие пони, которые могут объездить те кто С++ не осилил.

Не знаю, о чем ты. Полно инструментов, которые для определенных целей удобнее, надежнее, продуктивнее, чем С++. Осилил/неосилил тут не в кассу.

Сообщение от Fulcrum_013 в диалекте C++

Мало кого интересуют диалекты.

Сообщение от Fulcrum_013 Еще хорошей фишкой будет введение арифметики над массивами, потому как процессоры стали векторными, и без непосредственного указания со стороны программиста что он именно хочет с массивом сделать на основании того что он делает с элементами угадывать оптимизатору все сложнее и сложнее.

Ну дык http://www.open-std.org/jtc1/s... 193r0.html

0

Сообщение от ct0r Мало кого интересуют диалекты

Начнем с того что Visual C++, Intel С++ и С++ Builder имеют свои расширения синтаксиса, а значит являются диалектами. что самое интересное расширения именно в эту сторону и направлены - свойства, делегаты, RTTI, только у каждого это по своему, некоторые поддерживают два формата - свой и MSVC. И вот получается у всех как бы есть а в стандарте как бы нет. А комитет черте чем занимается вместо того чтобы это стандартизировать.

Сообщение от ct0r которые для определенных целей удобнее, надежнее, продуктивнее, чем С++

Сомнительно. Да естественно есть к примеру ниша скриптовых языков для WEB типа PHP и JS. Но это по большому счету специализированные диалекты C++

Добавлено через 5 минут

Сообщение от ct0r Да и неправда это.

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

Сообщение от ct0r Ну это много где нужно.

Обычно в наших широтах таки формошлепство востребовано. Да и в таких гигантах мысли аки мелкософт оно тоже процветает.

Добавлено через 18 минут

Сообщение от ct0r Осилил/неосилил тут не в кассу.

Ну не скажи. Полно людей которые теже скрипты под 1С делают и норм. При этом скрипты то управляют иерархией классов писанных на C++. Пусти их этой же иерархией управлять на С++ горя не оберешся. Это потому что они больше бухгалтера нежели программисты.

0

Сообщение от ct0r можешь привести пример, где по-прежнему нужно будет использовать sfinaе вместо концептов+constexpr if?

я честно говоря не проникся концептами.
чем они принципиально отличаются от самой сфиньи?
у них даже дизайн такой же забористый.

давайте порассуждаем на примере реальной задачки:

смарт-обертка параметризуется некоторым T
далее, когда при помощи emplace-фабрики происходит захват ресурса,
при этом срабатывает следующая логика:

1.
U может быть либо T, либо наследником.

2.
если у T доступен T::clone нужной сигнатуры,
тогда обертка делегирует задачу по клонированию самому ресурсу:

а иначе, wrapper<T> инстанцируется с дополнительным членом данных:
type-erasure helper,
который порождается в момент захвата ресурса
и "запоминает" тип U

и в этом случае задача по клонированию делегируется хэлперу:

такое применяется механизмом std::shared_ptr,
например.

задача на самом деле не сложная.
решение у неё можно сказать классическое.
и основывается оно на СФИНЬЕ.

однако для нетренированных мазгов,
это то, что в народе называют "шаблоно-магия".

по идее годный static_if мог бы упразднить СФИНЬЮ,
упростив тем самым конструкцию.

но как здесь могут помочь эти дикие концепты,
и костыльй статик_иф, который как я понял,
вообще не умеет того, что требуется от СФИНЬИ,
я хз.

1

Сообщение от ct0r 4) нужно, чтобы все ветки до инстанцирования были компилябельны.

hoggy, это про проверку кода, т.е
Оригинальный static_if допускал второй случай (код считался валидным).

Ну а ваша задачка
решается довольно просто
И никаких SFINAE и enable_if.

3

Сообщение от NotNot constexpr if (resource_has_clone) {

я правильно понял:
с помощью сочетания концепта и статик_иф, можно выполнять проверку
компилябельности любой ботвы?

0

hoggy, не. Ботва должна быть синтаксически валидна.

0

Только что уронил gcc концептами (internal compiler error)

Сообщение от NotNot решается довольно просто

Это понятно. Интереснее было бы посмотреть, как сделать так, чтобы еще при этом m_helper присутствовал/отсутствовал в классе и класс, чьим объектом является m_helper, компилировался/не компилировался в зависимости от того, есть ли у m_resource функция-член clone или нет.

0

Сообщение от ct0r Только что уронил gcc концептами (internal compiler error)

Недопилено, это да.

Сообщение от ct0r Интереснее было бы посмотреть, как сделать так, чтобы еще при этом m_helper присутствовал/отсутствовал в классе и класс, чьим объектом является m_helper, компилировался/не компилировался в зависимости от того, есть ли у m_resource функция-член clone или нет.

А, сам m_helper то я проворонил.

Ну, если по тупому и в лоб, специализируя сам wrapper<T>, то как-то так http://melpon.org/wandbox/perm... xqxmJszpK5. Тогда constexpr if нафиг не сдался, и отличается оно от плясок с enable_if, собственно, отсутсвием enable_if.

1