On Monday, March 19, "Chris 'Xenon' Hanson" wrote:
quoted text
> 
>    Optimally, you could switch between allocators as a compile-time
> define. U se a tougher allocator for debugging and stress testing. Use
> a lighter, faster one in situ ations where you are confident that the
> code is solid and needs speed more than bullet-res istance.

If that was usefull, people would do this all the time.  You're making
a number of assumptions.  Amoung them is that the ligther allocator does
not have any bugs that are exploitable.  That there is no interaction
between it and the rest of your code (say it allocated free'd memory in
a certain pattern that is exploitable by external code), and a host of
other things.

Also, as most people that have done large-scale real-world deployment
of services will tell you, you need real-world excersizing of your code
in order to find your bugs.  The rest (test data, etc) is a way to get
some assurance, but in the end it does not substitute for the real thing.


Compile time options are bad.

--Toby.