ph_piter Dec 26 2017 at 10:08

Новинки С++17, которые необходимо использовать каждому

7 min

37K

Издательский дом «Питер» corporate blogProgramming*C++*ООP*

Translation

+21

Comments 38

NelSon29 Dec 26 2017 at 10:49

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

Чего только стоит

Повсеместное использование

using namespace std;

Jamdaze Dec 26 2017 at 13:59

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

NelSon29 Dec 26 2017 at 14:36

Сейчас примеры почистили, но до сих пор остались сомнительные моменты, о которых более подробно расписали в комментариях на реддите.

Yarique Dec 26 2017 at 21:33

даже сам Бьярне в своих книгах для простоты использует

using namespace std;

maaGames Dec 26 2017 at 11:00

Вообще, очень сладенькие нововведения, хотя мне потребуется время, чтобы глаз перестал видеть ошибки в новом синтаксисе там, где их нет. И начал видеть так, где они есть.
Например, я до сих пор в шоке, что вместо emplace_back(make_pair(10,«a»)); можно написать emplace_back(10,«a»);
Код гораздо чище становится, конечно, но надо перепривыкать… И как бы всё это в итоге не вытекло в отладочный Адъ.

-2

broken Dec 27 2017 at 08:01

Это же std::forward в конструктор пары, еще с 11 стандарта так можно писать.

Yarique Dec 28 2017 at 13:38

шаблоны с переменным числом аргументов c++ погуглите ну и std::forward, всё логично

maaGames Dec 28 2017 at 13:41

Счастливые вы люди… Я лишь недавно смог перейти на 2008 студию.(

Yarique Dec 28 2017 at 14:06

Разрабатываете под винду? Сочувствую

maaGames Dec 28 2017 at 14:07

Хуже! Под винду в 2008 студии. Сочувствие в квадрате.

Jamdaze Dec 26 2017 at 14:29

Почему типам variant, optional, any уделяется столько внемания? Все кто хотел их уже давно используют из буста.

RPG18 Dec 26 2017 at 15:21

Тем, что теперь не надо будет тянуть буст.

Yarique Dec 28 2017 at 13:39

std:: variant, optional, any лучше boost:: variant, optional, any

pproger Dec 26 2017 at 14:35

книгу скачал, спасибо, на праздниках почитаю.

Jeka178RUS Dec 26 2017 at 14:35

Активное использование auto, вот главная проблема. Особенно больно видеть в объявлении функции. Элементарный пример: функция возвращает кортеж каких-то типов, используется привязка, все переменные объявлены как auto, что есть что непонятно, смотрим объявление функции, опять auto!!! Придется смотреть тело функции что бы понять, а что же на самом деле возвращает эта функция. Это мрак.

+10

AndreySu Dec 26 2017 at 19:26

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

Jeka178RUS Dec 26 2017 at 19:34

В случае со связыванием без авто не обойтись, например тут:

auto [name, age] = get();
std::cout << name << " is " << age << std::endl;

Dima_Sharihin Dec 27 2017 at 08:32

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

Все эти std::get сами по себе костыль, ни слова не говорящие о содержимом кортежа.

Cheater Dec 26 2017 at 14:45

Filesystem Technical Spec же забыли!

ИМХО гораздо более приятно видеть простые утилитарные нововведения (пресловутый filesystem API или давно ожидаемые модули) чем синтаксические новинки (constexpr lambda итд), которые применимы только если вся команда гарантированно хорошо разбирается в этом.

Jeka178RUS Dec 26 2017 at 19:29

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

-1

FoxCanFly Dec 28 2017 at 20:56

constexpr lambda не синтаксическая новинка, а просто исправление предыдущих стандартов с целью консистентности подхода (потому что незвозможнсть лямбды быть constexpr нелогична). Это как раз очень полезно, так как на уровне библиотек не эмулируется, чего не скажешь о filesystem. Все его всю жизнь из boost использовали и не страдали от этого

Yarique Dec 26 2017 at 21:45

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

Достаточно инстанцировать для структуры/класса
std::get
std::tuple_element
std::tuple_size
и можно

auto [n, a, [c1, c2]] = p2;

писать

Yarique Dec 27 2017 at 16:15

auto& [n, a, Loc] = p2; 
auto& [c1, c2] = Loc;

так можно для любой структуры вида:

struct Location {
    std::string city;
    std::string country;
};

struct Person {
    std::string name;
    uint32_t age;
    Location loc;
};

AxisPod Dec 27 2017 at 08:47

Объем опечаток, явных ошибок и отсутствие части материала соответствует станадрту «Packt>»?

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

Yarique Dec 27 2017 at 13:26

вот тоже последнее время решил брать оригиналы на английском

AxisPod Jan 19 2018 at 18:15

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

aamonster Dec 27 2017 at 12:21

s/необходимость в std::get отпадает/необходимость в std::tie отпадает/
"Зачем использовать std::variant" — вовсе не потому, что union чем-то плох (он решает свои задачи), а потому, что рано или поздно оказывается нужен именно variant — с явным хранением информации о типе. И каждый пишет свой велосипед. Лучше бы пример нормальный к нему привели — не try-catch, а хоть тот же visitor. И сказали бы, проконтроллирует ли компилятор обработку всех вариантов. И насколько хорошо он оптимизируется.
Про std::optional — тот же вопрос про оптимизацию. Например, если мы заменяем nullable pointer на std::optional — будет ли оверхед строго нулевым (с выигрышем по надёжности и простоте кода за счёт value_or и т.п.)

Конечно, ответ на все эти вопросы нетрудно найти и самому, но необходимости прямо сейчас — нету (лично мне не перейти так вдруг на 2017)

Ну и банальное: variant/optional/any давно были в boost, кто хотел — тот пользовался. Так что тут скорее уместен вопль 'ура-ура, они есть у нас 'из коробки"'.

Yarique Dec 27 2017 at 13:17

boost::variant может алоцировать память в куче, std::variant не аллоцирует память в куче никогда, так что это не тупо копия, а меньший оверхед

Yarique Dec 27 2017 at 13:24

std::optional и std::any тоже имеют меньший оверхэд, не принижайте людей из комитета стандартизации, там не дураки сидят

aamonster Dec 27 2017 at 14:11

Отлично (хотя и странно, в boost тоже умные люди пишут — но, возможно, какие-то оптимизации были недоступны).
Раз уж вы не поленились разобраться, то скажите: std::optional уже оптимизирован до предела? Т.е. можно всюду, где мы возвращали (возможно нулевой) указатель, возвращать optional и не проиграть ни в памяти, ни в быстродействии? Или пока нет?

Yarique Dec 27 2017 at 14:50

Человек, который boost::variant писал(Антон Полухин, в Москве(иногда и в Сибири) его можно найти на C++ User Group Meetup), признаётся, что std::variant имеет меньший оверхэд

boost всегда реализуют без учёта "математики компиляторов".
В Core WG и в Library WG комитета стандартизации С++ все правки рассматривают с точки зрения всех популярных компиляторов, воспринимая компиляторы как математические объекты, всё что в std:: добавляется из boost:: всегда будет, благодаря Core WG и Library WG, иметь меньший оверхэд.