Heap efficiency?

[_uj]

But (Again to the best of my understanding), have done ZERO quantitaive measurements to support this. IF I believe that variables should never have the letter O in them, with absolutely no quantitative evidence to support this position. I dont see a difference.

As I've told you several times, I don't use "look at me" argumentation. I just don't think personal results are valid evidence. Instead I stick with qualitative arguments and peer reviewed results. And of that I've posted plenty in support of my argumentation. Maybe you should do the same.

Very very simple. As soon as you replace the default allocator, you take on the full responsibility of testing EVERY piece of code that uses that allocator.

Not necessarily so if the provider of the default allocator and the replacement allocator is the same. As you may know Intel offers a popular C++ compiler. Intel also offers a replacement allocator as part of its TBB library. I'm sure Intel takes as much responsibility for the TBB allocator as it does for the standard allocator it ships with the compiler.

Having said that I realize that the most common situation may be that the replacement allocator doesn't come from the compiler provider. In that case there may be the implications you suggest but only if I've developed the allocator myself. Otherwise - no.

You have somehow arrived at the conclussion that original parts must always be better than third-party parts. This is a dire proposition for two reasons. Firstly it just isn't true. Third-party parts are likely to have been developed to the same high standard as the originals, if not even higher for the simple reason that otherwise they wouldn't sell. And secondly, it may give you a false sense of security. When an original part you unconditionally trust does fail you may be standing with your pants down because you didn't plan for what you thought could never happen.

So the secure world you've built yourself with original parts is nothing but an illusion. Cozy to be in but potentially dangerous if it makes you exclude the unexpected from your product testing.