3 ms·
Conceptually yes, but IIUC there should be worlds of difference at the compilation output level (i.e. unlike calling a function, the compiler's not obligated to
by shadowgovt 4y ago
Conceptually yes, but IIUC there should be worlds of difference at the compilation output level (i.e. unlike calling a function, the compiler's not obligated to set up or tear down a context every time it enters or exits a block; it can just treat the static scope semantics without having any impact on the runtime semantics).
ETA: except for go's `defer`, and off the top of my head I don't actually know if Go is obliged to run the defer immediately upon exiting the block or can choose to run it at some other point in the function.
- Jtsummers 4y agoIn Go, `defer` runs at the end of the enclosing function, not the enclosing block.
- vlovich123 4y agoThat shouldn’t be the case for c++ and Rust lambdas that are immediately invoked. The compiler should see through it.
- slaymaker1907 4y agoNot necessarily for C++. At least for msbuild, you can use `__declspec(noinline)` on a lambda. This can be handy for complex macros that would otherwise allocate a bunch of memory.
- ollien 4y ago> unlike calling a function, the compiler's not obligated to set up or tear down a context I guess it depends on what you mean by "context" but the spec is very clear that a block creates scope, and the end removes scope. https://go.dev/ref/spec#Declarations_and_scope https://go.dev/ref/spec#Declarations_and_scope > The scope of a constant or variable identifier declared inside a function begins at the end of the ConstSpec or VarSpec (ShortVarDecl for short variable declarations) and ends at the end of the innermost containing block.