Человек на видео упоминает про бесконечный цикл без побочных эффектов, который компилятор якобы оптимизирует.
Но мне кажется, что проблема тут как раз в отсутствии определения этого бесконечного цикла (и даже в отсутствии попыток это сделать).
return false выкидывается так как в цикле нет условий для прерывания, а оставшийся цикл выкидывается по принципу "программист же не дурак, зачем бы он стал писать бесконечный цикл" без каких-либо проверок.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
EP>>Объяснение (частичное) на видео. VTT>Человек на видео упоминает про бесконечный цикл без побочных эффектов, который компилятор якобы оптимизирует. VTT>Но мне кажется, что проблема тут как раз в отсутствии определения этого бесконечного цикла (и даже в отсутствии попыток это сделать). VTT>return false выкидывается так как в цикле нет условий для прерывания, а оставшийся цикл выкидывается по принципу "программист же не дурак, зачем бы он стал писать бесконечный цикл" без каких-либо проверок.
Возможно так и есть.
Вот стандарт:
1.10/24 The implementation may assume that any thread will eventually do one of the following:
— terminate,
— make a call to a library I/O function,
— access or modify a volatile object, or
— perform a synchronization operation or an atomic operation.
[ Note: This is intended to allow compiler transformations such as removal of empty loops, even when termination cannot be proven. —end note ]
Здравствуйте, B0FEE664, Вы писали:
BFE>? Вроде же нет прямого запрета.
Из стандарта:
[Note: Because the explicit template argument list follows the function template name, and because conversion member function templates and constructor member function templates are called without using a function name, there is no way to provide an explicit template argument list for these function templates. —end note]
Здравствуйте, Evgeny.Panasyuk, Вы писали: BFE>>? Вроде же нет прямого запрета. EP>Из стандарта: EP>
EP>[Note: Because the explicit template argument list follows the function template name, and because conversion member function templates and constructor member function templates are called without using a function name, there is no way to provide an explicit template argument list for these function templates. —end note]
Мне на этом форуме как-то раз говорили, что Note не являются частью стандарта, а являются выводами из его положений.
Однако, в данном случае, как мне кажется, сделанный вывод не соответствует положениям стандарта.
Т.е. положение верно для, скажем, объявления переменной:
A a<2>();// так нельзя.
А вот для delegating constructor это не так.
A mem-initializer-list can delegate to another constructor of the constructor’s class using any class-ordecltype
that denotes the constructor’s class itself. If a mem-initializer-id designates the constructor’s class,
it shall be the only mem-initializer; the constructor is a delegating constructor, and the constructor selected
by the mem-initializer is the target constructor.
Здравствуйте, B0FEE664, Вы писали:
BFE>Почему же нельзя задать шаблонный параметр конструктора? BFE>Теоретически, даже такое должно компилироваться:
Практически можно сделать конструктор с шаблоном:
Здравствуйте, _NN_, Вы писали:
BFE>>Почему же нельзя задать шаблонный параметр конструктора? BFE>>Теоретически, даже такое должно компилироваться: _NN>Практически можно сделать конструктор с шаблоном: _NN>
_NN>struct A
_NN>{
_NN> template <int n> A(){} // OK
_NN>};
_NN>
_NN>Только вызвать его нельзя никак
Вот корректный вызов:
struct A
{
template <int n> A(){} // OK
A(int) : A::A<2>() {} // call of template <int n> A(){}
};
Здравствуйте, fin_81, Вы писали:
_>А давайте применим стандарт с++ (с его неопределенными поведениями форматирующими жесткий диск) как формальную систему и опровергнем теорему Ферма.
Я нашёл этому поистине чудесное доказательство, но оно в процессе сохранения форматирует носитель, на который его сохраняют.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Вот стандарт: EP>
EP>1.10/24 The implementation may assume that any thread will eventually do one of the following:
EP>— terminate,
EP>— make a call to a library I/O function,
EP>— access or modify a volatile object, or
EP>— perform a synchronization operation or an atomic operation.
EP>[ Note: This is intended to allow compiler transformations such as removal of empty loops, even when termination cannot be proven. —end note ]
EP>
Если нет явного указания на то, что в противном случае UB, то от нормального компилятора можно ожидать другой логики:
Выхода из цикла нет значит в цикле есть модификация volatile object и так "оптимизировать" нельзя. Одним словом clang на помойку.
Здравствуйте, Лазар Бешкенадзе, Вы писали:
ЛБ>Если нет явного указания на то, что в противном случае UB, то от нормального компилятора можно ожидать другой логики:
ЛБ>Выхода из цикла нет значит в цикле есть модификация volatile object и так "оптимизировать" нельзя. Одним словом clang на помойку.
Но volatile object в цикле нет, так что оптимизируем с чистой совестью. Или стандарт на помойку.
Так-то я против тупого следования букве стандарта. Но с С++ это получается очень весело.