There is no reason anyone should ever write: T* p = new T[8]; ... delete[] p; The compiler should issue a warning telling them to stop being silly. It should probably only trigger for integer literals, because a variable or a macro might be constant in some build configurations and not in others. But an integer literal that isn't the result of macro-expansion is just silly.
Can you be more specific? Do you mean people should have written: T tab[8]; instead? What if 8 or sizeof(T) is large? If your "..." includes possible writes to p, or if p escapes and "..." may throw, I guess that cancels the warning? At some point the issue becomes similar to optimizing malloc to a stack allocation.
(In reply to Marc Glisse from comment #1) > Can you be more specific? Do you mean people should have written: > T tab[8]; Yes, exactly. I was fixing some code earlier today that used a dynamically allocated buffer of 8 chars and deleted it at the end of the function (but failed to do so on two early return paths). There was no reason it was done that way instead of using an automatic array, probably just someone who learnt to programme in Java and didn't know better. > instead? What if 8 or sizeof(T) is large? The case I looked at was char, it would probably be OK to only warn for scalar types, and for small array lengths (for some value of small). > If your "..." includes possible > writes to p, or if p escapes and "..." may throw, I guess that cancels the > warning? At some point the issue becomes similar to optimizing malloc to a > stack allocation. Part of the problem in the code I was fixing was that the "..." certainly could throw, and the delete never happened. But maybe the escape analysis is too tricky.
(In reply to Jonathan Wakely from comment #2) > (In reply to Marc Glisse from comment #1) > > Can you be more specific? Do you mean people should have written: > > T tab[8]; > > Yes, exactly. I was fixing some code earlier today that used a dynamically > allocated buffer of 8 chars and deleted it at the end of the function (but > failed to do so on two early return paths). There was no reason it was done > that way instead of using an automatic array, probably just someone who > learnt to programme in Java and didn't know better. > > > instead? What if 8 or sizeof(T) is large? > > The case I looked at was char, it would probably be OK to only warn for > scalar types, and for small array lengths (for some value of small). > > > If your "..." includes possible > > writes to p, or if p escapes and "..." may throw, I guess that cancels the > > warning? At some point the issue becomes similar to optimizing malloc to a > > stack allocation. > > Part of the problem in the code I was fixing was that the "..." certainly > could throw, and the delete never happened. > > But maybe the escape analysis is too tricky. Worth trying anyways; confirmed that it could be worthwhile to add this warning.
Rather than warning for benign but inefficient code I'd find it more friendly if GCC optimized it instead (if possible of course). In this case, it should be possible to rewrite it as suggested (i.e., turn dynamic allocation into automatic). A warning would then be useful if the automatic rewrite wasn't possible for some reason. Conversely, it could also turn stack allocation into dynamic for very large sizes (under some option controlling the cut-off point). This would be especially useful for VLAs.