Operator ->? и operator ?? для указателей

dix75
dix75

Их нужно расматривать в совокупности, так примеры вырзительнее.

Текущий вариант.

int cool(Person* p) {
    int x = 55;
    if(p != nullptr && p->ptr != nullptr && p->ptr->sub != nullptr)
      x = p->ptr->sub->toInt();
    return x;      
}

Там могло бы выглядеть упрощение.

int cool(Person* p) {
    return p?->ptr?->sub?->toInt() ?? 55;   
}

Еще примеры

auto x = ptr ?? 33;

auto y = ptr ?? new Person();

sAddedSyncIds?->Clear();
-2
рейтинг
15 комментариев
ru.night.beast
У "x" и "y" в примере какой тип?
ru.night.beast
dix75
ru.night.beast,
Здесь закралась ошибка с x
auto x = ptr ?? new int(33);
Во втором случаи Person
dix75
ru.night.beast
dix75, чет все равно не пойму. у ptr в обоих примерах одинаковый тип?
предположим, ptr имеет тип std::shared_ptr<int>.
опиши подробно, чего конкретно хочется.
ru.night.beast
yndx-antoshkka
Выглядит страшновато. Мне больше по душе:

int cool(Person* p) {
int x = 55;
if (p && p->ptr && p->ptr->sub)
x = p->ptr->sub->toInt();
return x;
}

На такой записи я не залипаю на 3 минуты в рассуждениях "что это всё значит?" и "почему не написали через if?"

Компилятор GCC имеет расширение похожее на вторую часть вашего предложения gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Conditionals.html
Но оно не пользуется популярностью.
yndx-antoshkka
ru.night.beast
yndx-antoshkka, для std::optional оператор ?: (с разыменованием), наверно, имел бы смысл.

одна из причин непопулярности в том что расширение, а не часть языка.
ru.night.beast
dix75
ru.night.beast,
вот именно, я многие фишки gcc не использую именно по этой причине.
dix75
dix75
yndx-antoshkka,
>> На такой записи я не залипаю на 3 минуты в рассуждениях "что это всё значит?"
Хм. странно, это только на первых порах. Тем более все новые вещи пропустить через себя приходится.
более понятный и простой пример
template<class T>
void clear(T* ptr) {
ptr?->doSMT();
ptr?->clerar();
delete ptr;
}
dix75
yndx-antoshkka
dix75, вот так будет выглядеть тело функции если все предложения по синтаксическому сахару за ~год включить в стандарт:

while (foo ~~ { @... }) {
return {} unless foo != bar;
foo += $&;
} else {
static decltype(return) var;
var += @ + ...;
g{hello}{word}[var]?->meow() ?? bark();
var;
}
{}

Вы уверены что вы этого хотите?
yndx-antoshkka
Nimius007
yndx-antoshkka, Да!
Nimius007
mrgordonfreman
Сомнительная красота. Как это будет выглядеть для базовых типов?
Вот такой пример
int foo(int** m) {
if (m != nullptr && *m != nullptr)
return **m;
return -1;
}
mrgordonfreman
dix75
mrgordonfreman,
Так же как и здесь, старый синтаксис никто не отменяет.
dix75
dix75
Очень часто мы по причине того что указатель никогда в функции не будет нулевым пишем так.

template<class T>
void clear(T* ptr) {
ptr->clear();
delete ptr;
}

но его можно будет обезопасить так

template<class T>
void clear(T* ptr) {
ptr?->clear();
delete ptr;
}

Что значит если указатель не нулевой вызови его функцию-член clear.
Выгода очевидна.

p.s. Ясное дело, что можно проверять указатель на nullptr, но не всегда мы это делаем, по разным причинам.
dix75
ru.night.beast
dix75> Выгода очевидна
мне, например, не очевидна.
конкретно в этом примере правильнее поставить assert или передавать ссылку.
нет смысла ради такой ерунды усложнять синтаксис.
ru.night.beast
Antervis
Вот так код ненамного длиннее и намного понятнее:
return (p && p->ptr && p->ptr->sub) ? p->ptr->sub->toInt() : 55;
Antervis
willir29
Наверное добавить новый оператор это дейстивительно так себе идея.

Можно подумать о методах в классы умных указателей. Напирмер ifPresent. Основнове приемущество по сравнению с if реализацией - не требуется создавать временную переменную для кода вида: getSome()->doSome(); Правда я не уверен что с ifPresent это будет выглядить лучше:
getSome().ifPresent(Some::doSome). И это ещё у doSome нету параметров. А то придётся писать

getSome().ifPresent([&] (auto *x) {x->doSome(val1, val2)});
Не сильно проще чем

auto some = getSome();
if (some) {
some->doSome(val1, val2);
}

В итоге, если мы не хотим получить perl, нам придётся писать более многословные вещи, и это наверное нормально.
willir29
Другие идеи
Группа создана, чтобы собирать предложения к стандарту C++, организовывать их внутренние обсуждения, помогать готовить их для отправки в комитет и защищать на общих собраниях в рабочей группе по С++ Международной организации по стандартизации (ISO).