Можно ли передавать ссылку на вектор, созданный локально?

struct A
{
    float* X_;
    int size;
    const vector<float> & getX(){
        vector<float> tmp(X_,X_+size);
        return tmp;
    }
    
};

P.S. другими словами будет ли метод getX правильно работать? Почему?

Здравствуйте, sci_reseacher, Вы писали:

_>Можно ли передавать ссылку на вектор, созданный локально?
_>

_>struct A
_>{
_>    float* X_;
_>    int size;
_>    const vector<float> & getX(){
_>        vector<float> tmp(X_,X_+size);
_>        return tmp;
_>    }
    
_>};
_>

_>P.S. другими словами будет ли метод getX правильно работать? Почему?
Метод getX будет таки правильно работать. А вот то, что пользуется этим методом вряд ли. Разве что, в вызывающем кода в lvalue будет не ссылка, а собственный объект vector<float>, тогда может отработает какой-нить operator= или какая-нить move-семантика, и все создастся.

PS: а еще над лесом летал аист © А потом какой-нить оптимизатор поставит методу getX() соглашение __stdcall и будет вызывающему коду счастье

Здравствуйте, sci_reseacher, Вы писали:

_>Можно ли передавать ссылку на вектор, созданный локально?
нельзя, т.к. при выходе из метода объект "vector<float> tmp" уже будет уничтожен

Здравствуйте, sci_reseacher, Вы писали:

_>Можно ли передавать ссылку на вектор, созданный локально?
_>P.S. другими словами будет ли метод getX правильно работать? Почему?
https://herbsutter.com/2008/01/01/gotw-88-a-candidate-for-the-most-important-const/

Здравствуйте, uzhas, Вы писали:

U>Здравствуйте, sci_reseacher, Вы писали:

_>>Можно ли передавать ссылку на вектор, созданный локально?
U>нельзя, т.к. при выходе из метода объект "vector<float> tmp" уже будет уничтожен

на самом деле там есть нюанс:

en.cppreference.com/lifetime
There are two exceptions from that:

The lifetime of a temporary object may be extended by binding to a const lvalue reference or to an rvalue reference (since C++11), see reference initialization for details.

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

Здравствуйте, uzhas, Вы писали:

U>Здравствуйте, sci_reseacher, Вы писали:

_>>Можно ли передавать ссылку на вектор, созданный локально?
U>нельзя, т.к. при выходе из метода объект "vector<float> tmp" уже будет уничтожен

А как можно вернуть ссылку на std::vector<float> в данной ситуации, когда имеется float *?


что-то типа сделать?

vector<float>  getVector(){
  vector<float> tmp(X_,X_+size);
  return tmp;
}

const vector<float> & getX(){
  return static_cast<const vector<float>&>(getVector());
}

Здравствуйте, sci_reseacher, Вы писали:

_>А как можно вернуть ссылку на std::vector<float> в данной ситуации, когда имеется float *?
Зачем? Что ты хочешь добиться? Почему не устраивает возврат по значению, как делает нижеприведённый getVector, а хочется что-то вроде нерабочего getX?

_>что-то типа сделать?
_>

_>vector<float>  getVector(){
_>  vector<float> tmp(X_,X_+size);
_>  return tmp;
_>}

_>const vector<float> & getX(){
_>  return static_cast<const vector<float>&>(getVector());
_>}
_>

Здравствуйте, _hum_, Вы писали:

__>на самом деле там есть нюанс:
это не наш случай

Здравствуйте, uzhas, Вы писали:

U>Здравствуйте, _hum_, Вы писали:

__>>на самом деле там есть нюанс:
U>это не наш случай

и в чем несовпадение?

Здравствуйте, sci_reseacher, Вы писали:


_>А как можно вернуть ссылку на std::vector<float> в данной ситуации, когда имеется float *?
зачем вам ссылка нужна? какая задача? возвращайте по значению

вот так:

vector<float> getVector(){
  vector<float> tmp(X_,X_+size);
  return tmp;
}

vector<float> a1 = getVector(); // <-- valid
const vector<float>& a2 = getVector(); // <-- valid as well

Здравствуйте, _hum_, Вы писали:

__>и в чем несовпадение?

Недостаточно дать переменной имя tmp чтобы она стала считаться тем самым «temporary object» из цитаты :)

Здравствуйте, _hum_, Вы писали:

__>и в чем несовпадение?
в примере ТС нет "temporary object"

Здравствуйте, watchmaker, Вы писали:

_>>А как можно вернуть ссылку на std::vector<float> в данной ситуации, когда имеется float *?
W>Зачем? Что ты хочешь добиться? Почему не устраивает возврат по значению, как делает нижеприведённый getVector, а хочется что-то вроде нерабочего getX?

Он явно хочет отстрелить себе ногу

Здравствуйте, watchmaker, Вы писали:

W>Здравствуйте, _hum_, Вы писали:

__>>и в чем несовпадение?

W>Недостаточно дать переменной имя tmp чтобы она стала считаться тем самым «temporary object» из цитаты

а можно обоснованно, а не голословно?

Здравствуйте, _hum_, Вы писали:


__>а можно обоснованно, а не голословно?

по своей же ссылке читай отсюда: "Temporary objects are created in the following situations"
или обратись к Стандарту

Здравствуйте, uzhas, Вы писали:

U>Здравствуйте, _hum_, Вы писали:


__>>а можно обоснованно, а не голословно?

U>по своей же ссылке читай отсюда: "Temporary objects are created in the following situations"
U>или обратись к Стандарту

замечательно. читаем:

Temporary object lifetime

Temporary objects are created in the following situations: binding a reference to a prvalue, returning a prvalue from a function, conversion that creates a prvalue, lambda expression, (since C++11) copy-initialization that requires conversion of the initializer, list-initialization that constructs an std::initializer_list, (since C++11) and reference-initialization to a different but convertible type or to a bitfield.

при создании const vector<float>& как раз-таки происходит конвертация из vector<float> tmp;

Здравствуйте, _hum_, Вы писали:

__>читаем:
__>

__>Temporary object lifetime

__>Temporary objects are created in the following situations: binding a reference to a prvalue, returning a prvalue from a function, conversion that creates a prvalue, lambda expression, (since C++11) copy-initialization that requires conversion of the initializer, list-initialization that constructs an std::initializer_list, (since C++11) and reference-initialization to a different but convertible type or to a bitfield.

читаем внимательнее выделенное: different but convertible type

Здравствуйте, uzhas, Вы писали:

U>Здравствуйте, _hum_, Вы писали:

__>>читаем:
__>>

__>>Temporary object lifetime

__>>Temporary objects are created in the following situations: binding a reference to a prvalue, returning a prvalue from a function, conversion that creates a prvalue, lambda expression, (since C++11) copy-initialization that requires conversion of the initializer, list-initialization that constructs an std::initializer_list, (since C++11) and reference-initialization to a different but convertible type or to a bitfield.

U>читаем внимательнее выделенное: different but convertible type

а что const std::vector<float> и std::vector<float> — одинаковые типы?

Здравствуйте, uzhas, Вы писали:

U>читаем внимательнее выделенное: different but convertible type

кстати, вот в этом примере не должен создаваться "temporary object":

struct A {};
struct B : A {};
B b;
const A& a = b;

хотя тут есть "different but convertible type"
скорее всего эта цитата на сайте не очень точна и может ввести в заблуждение
рекомендую обратиться к Стандарту за более точной формулировкой:
начни отсюда, дальше по главам прыгать надо

12.2 Temporary objects [class.temporary]
1 Temporaries of class type are created in various contexts: binding a reference to a prvalue (8.5.3), returning
a prvalue (6.6.3), a conversion that creates a prvalue (4.1, 5.2.9, 5.2.11, 5.4), throwing an exception (15.1),
and in some initializations (8.5). [ Note: The lifetime of exception objects is described in 15.1. —end note ]
Even when the creation of the temporary object is unevaluated (Clause 5) or otherwise avoided (12.8), all
the semantic restrictions shall be respected as if the temporary object had been created and later destroyed.
[ Note: This includes accessibility (11) and whether it is deleted, for the constructor selected and for the
destructor. However, in the special case of a function call used as the operand of a decltype-specifier (5.2.2),
no temporary is introduced, so the foregoing does not apply to the prvalue of any such function call. —end
note ]

Здравствуйте, uzhas, Вы писали:

U>рекомендую обратиться к Стандарту за более точной формулировкой:
U>начни отсюда

Да там есть прямым текстом про всю эту ситуацию рассказано:

The lifetime of a temporary bound to the returned value in a function return statement (6.6.3) is not
extended; the temporary is destroyed at the end of the full-expression in the return statement.