reference-binding

Does forming a reference to an object constitute access?

由 微笑、不失礼 提交于 2021-02-07 20:30:49
问题 Does forming a reference to an object constitute access? Here's what GCC and Clang currently do: void test(int const volatile* ptr) noexcept { *ptr; // movl (%rdi), eax // Reads *ptr [[maybe_unused]] int const volatile& ref = *ptr; // Does not read *ptr } My question is specifically about the statement [[maybe_unused]] int const volatile& ref = *ptr; According to the abstract machine, does this read the value of the object pointed to by ptr ? Would this statement, in isolation, be undefined

Reference initialization and direct vs indirect binding

由 元气小坏坏 提交于 2020-01-01 07:19:12
问题 Consider the following case struct A { operator int(); }; int &&x = A(); The spec says at http://eel.is/c++draft/dcl.init.ref#5 about whether the reference binding is direct or indirect In all cases except the last (i.e., creating and initializing a temporary from the initializer expression), the reference is said to bind directly to the initializer expression. The case above doesn't match the last, but the second last bullet. If T1 or T2 is a class type and T1 is not reference-related to T2,

Does this C++ static analysis rule make sense as is?

由 主宰稳场 提交于 2020-01-01 04:24:26
问题 I'm implementing some C++ static analysis rules, and one of them prohibits a function from returning a reference or pointer to a reference parameter of the function, i.e. the following are all non-compliant: int *f(int& x) { return &x; } // #1 const int *g(const int& x) { return &x; } // #2 int& h(int& x) { return x; } // #3 const int& m(const int& x) { return x; } // #4 The justification given for this is that "It is implementation-defined behaviour whether the reference parameter is a

Will temporary object be deleted if there is no const reference to it?

由 三世轮回 提交于 2019-12-23 12:13:15
问题 Lets take a look to this two functions: std::string get_string() { std::string ret_value; // Calculate ret_value ... return ret_value; } void process_c_string(const char* s) { std::cout << s << endl; } And here are two possible calls of process_c_string with argument returned by get_string . Without binding const reference to the returned object of get_string . process_c_string(get_string().c_str()); With binding const reference to the returned object of get_string . const std::string& tmp

Prolonging life of a temporary object using const reference

由 流过昼夜 提交于 2019-12-11 06:15:35
问题 I need a few clarification regarding const reference. From this link: const Foo &myFoo = FuncBar(); const reference extended the life of the local object. But when I checked this link although they used a const reference Sandbox(const string& n) : member(n) {} the lifetime of string "four" did not increase. Sandbox sandbox(string("four")); They used the sentence Only local const references prolong the lifespan. Then in the second link isn't the string "four" local to the main function and

Reference initialization and direct vs indirect binding

由 空扰寡人 提交于 2019-12-03 22:30:46
Consider the following case struct A { operator int(); }; int &&x = A(); The spec says at http://eel.is/c++draft/dcl.init.ref#5 about whether the reference binding is direct or indirect In all cases except the last (i.e., creating and initializing a temporary from the initializer expression), the reference is said to bind directly to the initializer expression. The case above doesn't match the last, but the second last bullet. If T1 or T2 is a class type and T1 is not reference-related to T2, user-defined conversions are considered ... The result of the call to the conversion function, as

Does const reference prolong the life of a temporary object returned by a temporary object?

由 非 Y 不嫁゛ 提交于 2019-12-02 22:29:11
问题 I know that const reference prolongs the life of a temporary locally. Now I am asking myself if this propriety can be extended on a chain of temporary objects, that is, if I can safely define: std::string const& foo = aBar.getTemporaryObject1().getTemporaryObject2(); My feeling is that, since the the first method aBar.getTemporaryObject1() returns already a temporary object, the propriety doesn't hold for aBar.getTemporaryObject2() . 回答1: The lifetime extension only applies when a reference

Does const reference prolong the life of a temporary object returned by a temporary object?

由 戏子无情 提交于 2019-12-02 09:02:20
I know that const reference prolongs the life of a temporary locally. Now I am asking myself if this propriety can be extended on a chain of temporary objects, that is, if I can safely define: std::string const& foo = aBar.getTemporaryObject1().getTemporaryObject2(); My feeling is that, since the the first method aBar.getTemporaryObject1() returns already a temporary object, the propriety doesn't hold for aBar.getTemporaryObject2() . The lifetime extension only applies when a reference is directly bound to that temporary. For example, initializing another reference from that reference does not

Using placement new to update a reference member?

由 ￡可爱￡侵袭症＋ 提交于 2019-12-01 09:26:24
Is the following code legal in C++? template<typename T> class Foo { public: Foo(T& v) : v_(v) {} private: T& v_; }; int a = 10; Foo<int> f(a); void Bar(int& a) { new (&f)Foo<int>(a); } References are not supposed to be bound twice, right? This is perfectly invalid. [basic.life]/1, emphasis mine: The lifetime of an object of type T ends when: if T is a class type with a non-trivial destructor (12.4), the destructor call starts, or the storage which the object occupies is reused or released. The placement new reuses the storage, ending the lifetime of the object denoted by f . [basic.life]/7:

Using placement new to update a reference member?

由 末鹿安然 提交于 2019-12-01 07:12:34
问题 Is the following code legal in C++? template<typename T> class Foo { public: Foo(T& v) : v_(v) {} private: T& v_; }; int a = 10; Foo<int> f(a); void Bar(int& a) { new (&f)Foo<int>(a); } References are not supposed to be bound twice, right? 回答1: This is perfectly invalid. [basic.life]/1, emphasis mine: The lifetime of an object of type T ends when: if T is a class type with a non-trivial destructor (12.4), the destructor call starts, or the storage which the object occupies is reused or
订阅 reference-binding