> it's definitely nice that someone is finally pursuing reducing allocations (big enemy of GC / performance!). Now's the time to get in on the API design stage!
As an aside, I'd love to be able to stack allocate in .NET. I realize there are huge complications with doing this, but there are just so many short lived objects that I'd love to control the lifetime of.
Of course part of the problem is that in all the .NET libraries everyone news objects willy nilly, so it would likely require making a "stack alloc clean" library from scratch, so there wouldn't be much immediate benefit.
This is something that other GC languages like the Oberon family or Modula-3 get right, by default you use the stack unless the objects are NEWed.
Eiffel has it even better, you can declared if a class should be heap or value type (expanded in Eiffel speak) by default, but you get to override it when declaring variables.
Still you get this problem even in languages like C, if the developers went a bit too heap friendly.
That's crazy! I always thought objects were stack allocated by default unless escape analysis showed them to escape the function return. Goes to show how little I know about .Net memory allocation..
Could you elaborate on what the problems would be with storing on the stack? I'm oblivious to what the problem would be. Stack relocation?
You can stackalloc in .net. the very library I am writing in the article uses it for things like 32byte temp hashes etc. Var a = stackalloc byte[32]; for instance
As an aside, I'd love to be able to stack allocate in .NET. I realize there are huge complications with doing this, but there are just so many short lived objects that I'd love to control the lifetime of.
Of course part of the problem is that in all the .NET libraries everyone news objects willy nilly, so it would likely require making a "stack alloc clean" library from scratch, so there wouldn't be much immediate benefit.