Comments 18
Плюсы такие плюсы) Не, в целом мне С++17 нравится, но лично я не использую deduction guides. Не потому, что не понимаю, а потому, что понимаю, что:
1) Использование функций-генераторов куда прозрачнее и понятнее. К тому же, во многих случаях когда приходится писать даже меньше.
2) Я точно знаю, что когда у чего-то в языке такие охрененно сложные правила, то примерно каждый второй разработчик будет тупо не знать каких-то нюансов и это приведет к печальным последствиям.
3) Код использующий deduction guides невозможно читать. Ты никогда не уверен в том, какой у тебя тут конкретно тип, потому что кто угодно в каком-нибудь заголовочнике написал свой deduction guide и ты охренеешь искать проблему.
3) Вот только find definition для функции — стандартная фича в любой IDE и мало-мальски адекватном редакторе. Найти где же этот чертов гайд я не знаю как))
2) Для функций правила хоть и не менее сложные, в них всё же немного меньше шансов выстрелить себе в ногу, хотя бы о по причинам обозначенным в статье.
1) Может и субъективщина, но мне лично приятней было писать std::back_inserter, чем std::back_insert_iterator. Тем более, что в функции можно спрятать логику и посложнее тупого вывода шаблонов, взять хоть тот же std::make_shared, который позволяет сократить количество аллокаций.
Мне в целом не критично.
std::make_tupleвсего на 5 символов длиннее, зато я на 100% уверен, что на выходе получу кортеж именно точно из тех аргументов, что передал. И если мне нужен кортеж итераторов, я его получу, а не получу, скажем, кортеж значений в этих итераторах.
Лично для меня описанные проблемы в целом достаточная причина не пользоваться стреляющей в ноги вещью. К тому же цена-то совсем не велика — просто указать шаблоны в типе, коих обычно один или два.
CLion неплохо справляется, даже на больших объемах кода. Если не может найти нужную перегрузку по Ctrl+Click на функции/методе, вывалит весь список со всеми перегрузками, нужно просто выбрать. Без плагинов, прямо из коробки умеет. Не идеально, но всё же это хоть можно как-то исправить. Как сделать go to deduction guide, я если честно не особо представляю. Не говорю невозможно, просто честно не знаю.
Стандарт гарантирует. А делать перегрузки, да или хоть что в std — это UB. Если речь о собственных функциях, то ССЗБ :)
Ну, в целом, у меня кроме лени был аргумент про бОльшую прозрачность и более простую навигацию.
Я прямо сейчас работаю с большим проектом в котором есть части с просто охрененной вложенностью шаблонов) Когда я не могу понять какая из 5-15 специализаций используются, я просто ставлю брейкпоинт везде, благо найти все места очень просто.
По поводу "дешугаринга" это понятно) Но на дворе 2019, а я до сих пор не вижу этой фичи :)
3) Код использующий deduction guides невозможно читать. Ты никогда не уверен в том, какой у тебя тут конкретно тип, потому что кто угодно в каком-нибудь заголовочнике написал свой deduction guide и ты охренеешь искать проблему.
это является проблемой только если deduction guide реализует совершенно нелогичный вывод типов. От этого абсолютно аналогично не застрахованы ни make-функции, ни разработчики, эти make-функции использующие. Deduction guides призваны уменьшить шум, и увеличить устойчивость кода к изменениям. «Поменял что-то (в нашем случае тип) в одном месте и забыл поменять в другом» — одна из самых распространенных причин ошибок.
Очень даже ничего, этот наш deduction guides !
Теперь можно написать пару враперов в проекте (вокруг объектов схожего типа, для выноса доп. функционала) с темплейтным конструктором и уззз-ба-гоидьзя ))
Конечно, пригодится не всем и не для повседневного программирования, больше для разработчиков всяких там библиотек...
Но это реально классная фича !
Я точно знаю, что когда у чего-то в языке такие охрененно сложные правила, то примерно каждый второй разработчик будет тупо не знать каких-то нюансов и это приведет к печальным последствиям.
Да это же почти что теорема Гёделя для языков программирования! Можно попробовать вывести закономерности «Развитие языка программирования (ЯП) приводит к его усложнению», «В усложняющемся ЯП возникает всё большее количество способов отстрелить себе ногу» и, наконец, если устремить время в бесконечность, то «Со временем вероятность отстрелить себе ногу в усложняющемся ЯП будет стремиться к единице»
Пример с make_shared некорректен. CTAD его не заменит, т.к. там фишка в том, что аллоцируется одним блоком и объект и внутренний тэг shared_ptr.
std::pair<> p{1, 5};
То есть как я понимаю классы перегружать по шаблонным параметрам всё ещё не получится? Но выглядеть будет как будто есть куча классов с одинаковыми именами, но "перегруженных" по шаблонным параметрам.
Интересно как такие нововведения в итоге внедрения в конкретные компиляторы повлияют на время сборки.
В целом выглядит довольно красиво конечно, учитывая на сколько уже можно захламить с помощью SFINAE + type_traits любую функцию или класс.
std::vector v2(8, 15);
преступление.
Обычно более важен тип в контейнере (или итераторе), чем сам контейнер (или итератор).
Было бы неплохо писать что-то типа
auto iter = v.begin();
Class Template Argument Deduction