Why prevent a HeapBlock from being allocated on the heap?

What are the arguments for preventing that behaviour?

It does seem defeatist initially, but indirectly a HeapBlock will be allocated on the heap if it’s a member of an object that was allocated on the heap.

For example, MemoryBlock internally manipulates a HeapBlock, and there are situations where MemoryBlocks are allocated on the heap.

It’d be like allocating a pointer on the heap… I can’t really see much sense in it, and added the restriction because so many n00bs seem to just heap-allocate classes unnecessarily. I wish I could make File and String non-heap-allocatable!

can’t think of any intelligent place in any code where i would create a MemoryBlock on the heap.

Well, the term “JUCE_PREVENT_HEAP_ALLOCATION” is just misleading

What if I have a MemoryBlock as a member in a class that represent a Node in a tree?
Of course, I could be allocating those Nodes dynamically on the heap. Hence also their MemoryBlocks will, am I right?

What are the arguments for ever doing “new HeapBlock”? Or “new MemoryBlock”, for that matter? They are just lightweight “handles” to a pointer, so why should they ever be dynamically allocated?

i was saying you will never ever need to do new MemoryBlock or HeapBlock, not that the memory block could not be on the heap. actually in juce, since the application (or the plugin) instance is created using new, then anything is on the heap

You can make a tenuous argument for “new MemoryBlock” or “new File” because although you should never write that in your own code, you may want to store them in some kind of templated container that allocates its objects on the heap. But HeapBlock isn’t like that - it’s basically a pointer and there’d be edge-cases when constructing and copying it, so I really don’t think there’s a good use case for allowing it there.