Сообщение Re[6]: Насколько корректно использовать адрес переменной в с от 26.07.2017 13:17
Изменено 26.07.2017 14:51 watchmaker
Re[6]: Насколько корректно использовать адрес переменной в стеке
Здравствуйте, Кодт, Вы писали:
W>>Поэтому такой трюк с дефолтным параметром сугубо вредный: он явно выражает то, что и так записано в ABI как необходимое действие.
К>Насчёт сугубо-вредности — тут можно пообсуждать.
К>Во-первых, мы не надеемся на NRVO
Тут как бы дело в том, что такого поведения требует ABI, а не стандарт C++. То есть NRVO тут вообще не при чём. Так делать компилятор обязан всегда, ибо программа должна удовлетворять требованиям из обоих этих документов.
То есть если рассматривать ситуацию с точки зрения только C++, то про конкретное устройство стека (и его взаимодействие с сигналами, прерываниями и прочем) практически ничего нельзя сказать, и поэтому нельзя утверждать, что такой код даст какой-то выигрыш.
Если же подключить знания об устройстве стека (которое описано в ABI), то выясняется, что такой код заведомо не нужен.
Вот этот последний ненужный код я и назвал вредным за то, что он просто сложнее при одновременном отсутствии какой-либо выгоды.
К> И заодно, снимаем требование о копируемости-перемещаемости с типа. (Правда, добавляя некоторую дефолтную инициализацию и вторую фазу).
Ага. Правда компилятор без этого трюка ещё и сам автоматически разрешит ситуацию, когда, например, у класса нет дефолтного инициализатора.
W>>Поэтому такой трюк с дефолтным параметром сугубо вредный: он явно выражает то, что и так записано в ABI как необходимое действие.
К>Насчёт сугубо-вредности — тут можно пообсуждать.
К>Во-первых, мы не надеемся на NRVO
Тут как бы дело в том, что такого поведения требует ABI, а не стандарт C++. То есть NRVO тут вообще не при чём. Так делать компилятор обязан всегда, ибо программа должна удовлетворять требованиям из обоих этих документов.
То есть если рассматривать ситуацию с точки зрения только C++, то про конкретное устройство стека (и его взаимодействие с сигналами, прерываниями и прочем) практически ничего нельзя сказать, и поэтому нельзя утверждать, что такой код даст какой-то выигрыш.
Если же подключить знания об устройстве стека (которое описано в ABI), то выясняется, что такой код заведомо не нужен.
Вот этот последний ненужный код я и назвал вредным за то, что он просто сложнее при одновременном отсутствии какой-либо выгоды.
К> И заодно, снимаем требование о копируемости-перемещаемости с типа. (Правда, добавляя некоторую дефолтную инициализацию и вторую фазу).
Ага. Правда компилятор без этого трюка ещё и сам автоматически разрешит ситуацию, когда, например, у класса нет дефолтного инициализатора.
Re[6]: Насколько корректно использовать адрес переменной в с
Здравствуйте, Кодт, Вы писали:
W>>Поэтому такой трюк с дефолтным параметром сугубо вредный: он явно выражает то, что и так записано в ABI как необходимое действие.
К>Насчёт сугубо-вредности — тут можно пообсуждать.
К>Во-первых, мы не надеемся на NRVO
Тут как бы дело в том, что такого поведения требует ABI, а не стандарт C++. Так делать компилятор обязан всегда, ибо программа должна удовлетворять требованиям из обоих этих документов.
То есть NRVO тут важно только из-за того, что ускоряет внутренности функции и избавляет от временных переменных, но на время жизни памяти оно не влияет.
То есть если рассматривать ситуацию с точки зрения только C++, то про конкретное устройство стека (и его взаимодействие с сигналами, прерываниями и прочем) практически ничего нельзя сказать, и поэтому нельзя утверждать, что такой код даст какой-то выигрыш.
Если же подключить знания об устройстве стека (которое описано в ABI), то выясняется, что такой код заведомо не нужен.
Вот этот последний ненужный код я и назвал вредным за то, что он просто сложнее при одновременном отсутствии какой-либо выгоды.
К> И заодно, снимаем требование о копируемости-перемещаемости с типа. (Правда, добавляя некоторую дефолтную инициализацию и вторую фазу).
Ага. Правда компилятор без этого трюка ещё и сам автоматически разрешит ситуацию, когда, например, у класса нет дефолтного инициализатора.
То есть там просто вместо готового объекта передаётся указатель на alignas(T) char buffer[sizeof(T)], в который потом можно сделать placement_new и вернуть указатель на новый объект.
W>>Поэтому такой трюк с дефолтным параметром сугубо вредный: он явно выражает то, что и так записано в ABI как необходимое действие.
К>Насчёт сугубо-вредности — тут можно пообсуждать.
К>Во-первых, мы не надеемся на NRVO
Тут как бы дело в том, что такого поведения требует ABI, а не стандарт C++. Так делать компилятор обязан всегда, ибо программа должна удовлетворять требованиям из обоих этих документов.
То есть NRVO тут важно только из-за того, что ускоряет внутренности функции и избавляет от временных переменных, но на время жизни памяти оно не влияет.
То есть если рассматривать ситуацию с точки зрения только C++, то про конкретное устройство стека (и его взаимодействие с сигналами, прерываниями и прочем) практически ничего нельзя сказать, и поэтому нельзя утверждать, что такой код даст какой-то выигрыш.
Если же подключить знания об устройстве стека (которое описано в ABI), то выясняется, что такой код заведомо не нужен.
Вот этот последний ненужный код я и назвал вредным за то, что он просто сложнее при одновременном отсутствии какой-либо выгоды.
К> И заодно, снимаем требование о копируемости-перемещаемости с типа. (Правда, добавляя некоторую дефолтную инициализацию и вторую фазу).
Ага. Правда компилятор без этого трюка ещё и сам автоматически разрешит ситуацию, когда, например, у класса нет дефолтного инициализатора.
То есть там просто вместо готового объекта передаётся указатель на alignas(T) char buffer[sizeof(T)], в который потом можно сделать placement_new и вернуть указатель на новый объект.