On Mon, Nov 16, 2020 at 5:49 AM tapi...@gmail.com <tapir....@gmail.com> wrote: > > @Ian > How about forbidding manual allocated memory references normal pointers?
I suppose I don't understand how to do that without being either memory unsafe or being unexpectedly slow. (If it's OK to be memory unsafe, then I don't think Go would be the preferred language. Go provides hooks to permit unsafe memory use, but it doesn't make them particularly easy to use. That is intentional and I don't think we're going to change that.) Ian > On Sunday, November 15, 2020 at 9:23:54 PM UTC-5 Ian Lance Taylor wrote: >> >> On Sun, Nov 15, 2020 at 5:38 PM tapi...@gmail.com <tapi...@gmail.com> wrote: >> > >> > For example, by adding two new built-in functions: alloc and free, garbage >> > collector will ignore the memory allocated by alloc. The memory allocated >> > by alloc must be freed by calling the free function manually. >> > >> > This would relieve the burden of GC for some Go programs (such as games). >> >> I think this is a misunderstanding of where GC time goes. If you can >> store a normal Go pointer in memory allocated using the new alloc >> function, then memory allocated by alloc must still be scanned by the >> GC. >> >> Ian > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/21159b26-4a56-455d-9665-b4f1eeaf8f33n%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXF%2B6g8%2BphFYaJ9sR3Y4a-yMsWhhGGrbnUx8h2Ee9vN5Q%40mail.gmail.com.
