Сообщение Re[8]: Насколько корректно использовать адрес переменной в с от 26.07.2017 14:44
Изменено 26.07.2017 14:44 watchmaker
Re[8]: Насколько корректно использовать адрес переменной в стеке
Здравствуйте, Nick-77, Вы писали:
N7>Здравствуйте, watchmaker, Вы писали:
W>>Здравствуйте, Nick-77, Вы писали:
N7>>>вот тут я перестал понимать, ведь это самое r и будет в стеке функции, который помрёт, т.е. от возврата указателя толку мало, или там будет какая-то неявная обёртка в memcpy?
W>>Память под BigStruct будет выделена в стеке вызывающей функции. Поэтому эта память будет жить и после завершения вызываемой функции. И поэтому функция может вернуть указатель на эту память, так как этот указатель останется валидным даже после завершения foo.
W>>И по этому указателю компилятор будет хранить r (на момент выхода из функции).
W>>Уточнение в скобках важно.
W>>То есть у функции foo есть участок в стеке, который заведомо переживёт время жизни самой foo, и в которой должна размещаться переменная r.
W>>При этом, если переменная r размещается в этом месте всё время своей жизни, то это называется NRVO. Иначе же допускается, что переменная может быть сконструирована на собственном стеке foo, а потом перед выходом скопирована в указанную память, в том числе и через memcpy (эта ситуация называется "NRVO не сработал").
W>>В общем-то Кодт очень хорошо написал выше вручную код, который компилятор сам делает. Можно сверится с ним.
N7>тык у меня ж речь о голом С, а он разве подправляет заголовки функций, ведь получается, что допустим struct Mtype f(int a); должна быть преобразована НЕЯВНО в struct * Mtype f(Struct *val, int a);
N7>что, мягко говоря, вызывает вопросы как это чудо будет линоваться, особенно с не-С кодом, с каким-нить пайтоном...
N7>?
Это правильный вопрос. Конкретный ответ на него даёт ABI. И обычно ответ: все должны делать эту замену (неявно, при совпадении некоторых условий).
И такая замена действительно происходит и при сборке C++, и при сборке голого C, и даже при сборке бинарных модулей Python.
Ведь, конечно, верно, что если бы это не происходило во всех языках одновременно и синхронно, то они бы не смогли корректно линковаться между собой.
Просто что касается того же Python, то внутри у него (у CPython) возврат структур сделан через собственную виртуальную машину и там вопрос про стек немного не имеет смысла. Но если нужно вызвать из Python какой-нибудь бинарный модуль, написанный на C, который при этом возвращает структуру, то такая замена произойдёт.
Но, конечно, в самом интерпретаторе Python об таких деталях не особо упоминают просто из-за того, что это немного offtopic. А Python делегирует эту низкоуровневую работу либо соответствующему компилятору (если собираем модуль на C, например), либо libffi (если подключаем модуль в run-time).
N7>Здравствуйте, watchmaker, Вы писали:
W>>Здравствуйте, Nick-77, Вы писали:
N7>>>вот тут я перестал понимать, ведь это самое r и будет в стеке функции, который помрёт, т.е. от возврата указателя толку мало, или там будет какая-то неявная обёртка в memcpy?
W>>Память под BigStruct будет выделена в стеке вызывающей функции. Поэтому эта память будет жить и после завершения вызываемой функции. И поэтому функция может вернуть указатель на эту память, так как этот указатель останется валидным даже после завершения foo.
W>>И по этому указателю компилятор будет хранить r (на момент выхода из функции).
W>>Уточнение в скобках важно.
W>>То есть у функции foo есть участок в стеке, который заведомо переживёт время жизни самой foo, и в которой должна размещаться переменная r.
W>>При этом, если переменная r размещается в этом месте всё время своей жизни, то это называется NRVO. Иначе же допускается, что переменная может быть сконструирована на собственном стеке foo, а потом перед выходом скопирована в указанную память, в том числе и через memcpy (эта ситуация называется "NRVO не сработал").
W>>В общем-то Кодт очень хорошо написал выше вручную код, который компилятор сам делает. Можно сверится с ним.
N7>тык у меня ж речь о голом С, а он разве подправляет заголовки функций, ведь получается, что допустим struct Mtype f(int a); должна быть преобразована НЕЯВНО в struct * Mtype f(Struct *val, int a);
N7>что, мягко говоря, вызывает вопросы как это чудо будет линоваться, особенно с не-С кодом, с каким-нить пайтоном...
N7>?
Это правильный вопрос. Конкретный ответ на него даёт ABI. И обычно ответ: все должны делать эту замену (неявно, при совпадении некоторых условий).
И такая замена действительно происходит и при сборке C++, и при сборке голого C, и даже при сборке бинарных модулей Python.
Ведь, конечно, верно, что если бы это не происходило во всех языках одновременно и синхронно, то они бы не смогли корректно линковаться между собой.
Просто что касается того же Python, то внутри у него (у CPython) возврат структур сделан через собственную виртуальную машину и там вопрос про стек немного не имеет смысла. Но если нужно вызвать из Python какой-нибудь бинарный модуль, написанный на C, который при этом возвращает структуру, то такая замена произойдёт.
Но, конечно, в самом интерпретаторе Python об таких деталях не особо упоминают просто из-за того, что это немного offtopic. А Python делегирует эту низкоуровневую работу либо соответствующему компилятору (если собираем модуль на C, например), либо libffi (если подключаем модуль в run-time).
Re[8]: Насколько корректно использовать адрес переменной в с
Здравствуйте, Nick-77, Вы писали:
N7>тык у меня ж речь о голом С, а он разве подправляет заголовки функций, ведь получается, что допустим struct Mtype f(int a); должна быть преобразована НЕЯВНО в struct * Mtype f(Struct *val, int a);
N7>что, мягко говоря, вызывает вопросы как это чудо будет линоваться, особенно с не-С кодом, с каким-нить пайтоном...
N7>?
Это правильный вопрос. Конкретный ответ на него даёт ABI. И обычно ответ: все должны делать эту замену (неявно, при совпадении некоторых условий).
И такая замена действительно происходит и при сборке C++, и при сборке голого C, и даже при сборке бинарных модулей Python.
Ведь, конечно, верно, что если бы это не происходило во всех языках одновременно и синхронно, то они бы не смогли корректно линковаться между собой.
Просто что касается того же Python, то внутри у него (у CPython) возврат структур сделан через собственную виртуальную машину и там вопрос про стек немного не имеет смысла. Но если нужно вызвать из Python какой-нибудь бинарный модуль, написанный на C, который при этом возвращает структуру, то такая замена произойдёт.
Но, конечно, в самом интерпретаторе Python об таких деталях не особо упоминают просто из-за того, что это немного offtopic. А Python делегирует эту низкоуровневую работу либо соответствующему компилятору (если собираем модуль на C, например), либо libffi (если подключаем модуль в run-time).
N7>тык у меня ж речь о голом С, а он разве подправляет заголовки функций, ведь получается, что допустим struct Mtype f(int a); должна быть преобразована НЕЯВНО в struct * Mtype f(Struct *val, int a);
N7>что, мягко говоря, вызывает вопросы как это чудо будет линоваться, особенно с не-С кодом, с каким-нить пайтоном...
N7>?
Это правильный вопрос. Конкретный ответ на него даёт ABI. И обычно ответ: все должны делать эту замену (неявно, при совпадении некоторых условий).
И такая замена действительно происходит и при сборке C++, и при сборке голого C, и даже при сборке бинарных модулей Python.
Ведь, конечно, верно, что если бы это не происходило во всех языках одновременно и синхронно, то они бы не смогли корректно линковаться между собой.
Просто что касается того же Python, то внутри у него (у CPython) возврат структур сделан через собственную виртуальную машину и там вопрос про стек немного не имеет смысла. Но если нужно вызвать из Python какой-нибудь бинарный модуль, написанный на C, который при этом возвращает структуру, то такая замена произойдёт.
Но, конечно, в самом интерпретаторе Python об таких деталях не особо упоминают просто из-за того, что это немного offtopic. А Python делегирует эту низкоуровневую работу либо соответствующему компилятору (если собираем модуль на C, например), либо libffi (если подключаем модуль в run-time).