Date: Fri, 11 Oct 2024 10:45:20 -0700
> Why not deallocate it in main in the end in that case? I honestly think
that you should always free your resources.
This is a C++ discussion list.
That code looks like it is asking/talking about C.
C++ has code that intentionally runs after main() has exited. For example
global or static (file scope or function scope) object destructors. That
code might need or use other long lasting data.
C is typically done with everything at the end of main() but even C can run
code after main(). For example: onexit(...). onexit might be doing some
cleanup or data/log dumps.
On Fri, Oct 11, 2024 at 10:15 AM Hyman Rosen via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Why not deallocate it in main in the end in that case? I honestly think
>> that you should always free your resources.
>>
> Because deallocation takes time and is useless at the end of the program.
> It's annoying when you ask an interactive program to exit and it sits there
> durdling for a while before going away.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
that you should always free your resources.
This is a C++ discussion list.
That code looks like it is asking/talking about C.
C++ has code that intentionally runs after main() has exited. For example
global or static (file scope or function scope) object destructors. That
code might need or use other long lasting data.
C is typically done with everything at the end of main() but even C can run
code after main(). For example: onexit(...). onexit might be doing some
cleanup or data/log dumps.
On Fri, Oct 11, 2024 at 10:15 AM Hyman Rosen via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> Why not deallocate it in main in the end in that case? I honestly think
>> that you should always free your resources.
>>
> Because deallocation takes time and is useless at the end of the program.
> It's annoying when you ask an interactive program to exit and it sits there
> durdling for a while before going away.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2024-10-11 17:45:36