, погуглил слова "A conversion function is never used", которые нашёл в исходниках clang-а, которые выдают предупреждение в коде, который ты привёл.
Clang — крутой.
Если не поможет, будем действовать током... 600 Вольт (C)
К>gcc его вызывает , VC8 молча игнорирует, comeau пишет варнинг "этот код никогда не будет вызван". К>Ну и кто прав?
Присоединяюсь к вопросу — особенно в контексте того, какое время жизни должно быть у объектов, возвращенных из функции по значению и привязанных к константной ссылке. Мой коммент по этому вопросу
Здравствуйте, elw00d, Вы писали:
E>Присоединяюсь к вопросу — особенно в контексте того, какое время жизни должно быть у объектов, возвращенных из функции по значению и привязанных к константной ссылке. Мой коммент по этому вопросу
Кстати да, можно и потерять владение временным объектом!
Натурный эксперимент показывает, что компилятор со спокойной душой теряет.
Т.е. получается const A& ref = A().operator const A&(), дальше мы запоминаем возвращённую ссылку, а временный объект спокойно разрушаем.
Отсюда мораль: нестандартное поведение gcc порождает ошибки.
Здравствуйте, Кодт, Вы писали:
К>Кстати да, можно и потерять владение временным объектом! К>Натурный эксперимент показывает, что компилятор со спокойной душой теряет. К>Т.е. получается const A& ref = A().operator const A&(), дальше мы запоминаем возвращённую ссылку, а временный объект спокойно разрушаем.
Да, я тоже предполагаю, что все так и происходит. Хотя, на мой взгляд, у возвращаемого значения должно работать некое рекурсивное правило — скажем, если мы приводим объект к константной ссылке, его время жизни продлевается. Соответственно, если мы эту константную ссылку вытаскиваем дальше — и запоминаем в другой константной ссылке — то она продлевает время жизни промежуточной ссылки.
К>Отсюда мораль: нестандартное поведение gcc порождает ошибки.
Угу. Осталось только определить, насколько корректно такое поведение с точки зрения Стандарта.
К>gcc его вызывает , VC8 молча игнорирует, comeau пишет варнинг "этот код никогда не будет вызван". К>Ну и кто прав?
GNU C++ по-своему прав — он честно соблюдает 8.5.3/5:
A reference to type “cv1 T1” is initialized by an expression of type “cv2 T2” as follows:
— If the initializer expression
—— is an lvalue (but is not a bit-field), and “cv1 T1” is reference-compatible with “cv2 T2,” or
—— has a class type (i.e., T2 is a class type) and can be implicitly converted to an lvalue of type “cv3 T3,” where “cv1 T1” is reference-compatible with “cv3 T3” 92) (this conversion is selected by enumerating the applicable conversion functions (13.3.1.6) and choosing the best one through overload resolution (13.3)),
then the reference is bound directly to the initializer expression lvalue in the first case, and the reference is bound to the lvalue result of the conversion in the second case. In these cases the reference is said to bind directly to the initializer expression.
и 13.3.1.6/1:
Under the conditions specified in 8.5.3, a reference can be bound directly to an lvalue that is the result of applying a conversion function to an initializer expression. Overload resolution is used to select the conversion function to be invoked. Assuming that “cv1 T” is the underlying type of the reference being initialized, and “cv S” is the type of the initializer expression, with S a class type, the candidate functions are selected as follows:
— The conversion functions of S and its base classes are considered. Those that are not hidden within S and yield type “reference to cv2 T2”, where “cv1 T” is reference-compatible (8.5.3) with “cv2 T2”, are candidate functions.
A::operator const A& соответствует критериям к candidate functions. Далее, если инициализация посредством conversion function может быть выполнена, то остальная часть 8.5.3/5
— Otherwise, the reference shall be to a non-volatile const type (i.e., cv1 shall be const). [...]
В DR 641 для 8.5.3/5 была сделана существенная поправка, разрешающая противоречие с 12.3.2/1. Исправленной версии правил поведение GNU C++ не соответствует.
Здравствуйте, Кодт, Вы писали:
E>>Присоединяюсь к вопросу — особенно в контексте того, какое время жизни должно быть у объектов, возвращенных из функции по значению и привязанных к константной ссылке. Мой коммент по этому вопросу К>Кстати да, можно и потерять владение временным объектом!
Имхо, ссылка и не владеет объектом.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
К>Натурный эксперимент показывает, что компилятор со спокойной душой теряет. К>Т.е. получается const A& ref = A().operator const A&(), дальше мы запоминаем возвращённую ссылку, а временный объект спокойно разрушаем.
Точно разрушает? (Под рукой нет гцц, чтоб проверить). По стандарту же, если присваивать результат константной ссылке, то время жизни временного объекта продлевается до времени жизни этой ссылки.
24:
К>>Натурный эксперимент показывает, что компилятор со спокойной душой теряет. К>>Т.е. получается const A& ref = A().operator const A&(), дальше мы запоминаем возвращённую ссылку, а временный объект спокойно разрушаем.
24>Точно разрушает? (Под рукой нет гцц, чтоб проверить). По стандарту же, если присваивать результат константной ссылке, то время жизни временного объекта продлевается до времени жизни этой ссылки.
12.2/5:
A temporary bound to a reference parameter in a function call (5.2.2) persists until the completion of the full expression containing the call.
В данном случае "reference parameter in a function call" — это implicit object parameter функции A::operator const A&.
Здравствуйте, Vain, Вы писали:
К>>Кстати да, можно и потерять владение временным объектом! V>Имхо, ссылка и не владеет объектом.
Если не придираться к буквам, то, грубо говоря, владеет.
При конверсии rvalue в константную (а у VC — и в неконстантную тоже) ссылку в автоматическом хранилище, создаётся копия объекта (а с учётом RVO — временный объект размещается там сразу же). И время жизни этого объекта совпадает с временем жизни ссылки.
А вот если мы инициализируем ссылку какой-то другой ссылкой — то копия не создаётся, ну и дальше всё понятно.
Здравствуйте, 24, Вы писали:
К>>Натурный эксперимент показывает, что компилятор со спокойной душой теряет. К>>Т.е. получается const A& ref = A().operator const A&(), дальше мы запоминаем возвращённую ссылку, а временный объект спокойно разрушаем.
24>Точно разрушает? (Под рукой нет гцц, чтоб проверить).
Да, разрушает. Под рукой всегда есть гцц на кодепаде http://codepad.org/PRYGdtZY
24> По стандарту же, если присваивать результат константной ссылке, то время жизни временного объекта продлевается до времени жизни этой ссылки.
Это если присваивать ссылке rvalue. А если присваивать ссылку — то с какой радости? Компилятор же не телепат, чтобы догадаться об идентичности.
Здравствуйте, Кодт, Вы писали:
К>>>Кстати да, можно и потерять владение временным объектом! V>>Имхо, ссылка и не владеет объектом. К>Если не придираться к буквам, то, грубо говоря, владеет. К>При конверсии rvalue в константную (а у VC — и в неконстантную тоже) ссылку в автоматическом хранилище, создаётся копия объекта (а с учётом RVO — временный объект размещается там сразу же). И время жизни этого объекта совпадает с временем жизни ссылки.
Создание временного объекта не связано с владением, т.к. его просто нет. Есть объект, область жизни которого совпадает или не совпадает с областью жизни ссылки.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
, VC8 молча игнорирует, comeau пишет варнинг "этот код никогда не будет вызван".
Перекуём баги на фичи!
