Возврат ссылок rvalue

Я видел другие сообщения об этом, но я все еще немного смущен этим.

const std::string& func(std::string&& ref) { return ref; }

int main(void) {
  const std::string& r=func("E");
  std::cout << r << std::endl;
}

Технически это должен быть UB, я возвращаю ссылку на "E", которая должна быть уничтожена после выполнения выражения, присваивающего r, верно? Однако никаких предупреждений от clang или g++, возможно, я что-то упускаю?

const std::string& func(std::string ref) { return ref; }

int main(void) {
  const std::string& r=func("E");
  std::cout << r << std::endl;
}

Clang предупредит о чем-то подобном. Но об этом не предупреждает:

const std::string& func(std::string ref) { return std::move(ref); }

int main(void) {  
  const std::string& r=func("E");
  std::cout << r << std::endl;  
}

Он также не предупреждает о чем-то вроде:

std::string&& func(std::string&& ref) { return std::move(ref); }

int main(void) {
  std::string&& r=func("E");
  std::cout << r << std::endl;  
}

Это ведь не УБ?

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

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

Sam Varshavchik 14.12.2020 13:43

@0RR Последний тоже UB.

eerorika 14.12.2020 13:55

Итак... немного лишнего, но в каком случае законно возвращать ссылки rvalue?

Pol 14.12.2020 14:04

@pol Вы можете вернуть ссылку rvalue, если знаете, что объект, на который делается ссылка, все еще жив. Или если вы используете его в неоцененном контексте. std::declval приходит на ум.

super 14.12.2020 14:19
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
2
4
86
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Однако никаких предупреждений от clang или g++, возможно, я что-то упускаю?

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

Это ведь не УБ?

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


Что бы это ни стоило, и GCC, и Clang обнаруживают эту ошибку во время выполнения с помощью AddressSanitizer.

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

Pol 14.12.2020 14:00

Другие вопросы по теме