> libNew serves two purposes: > - provide basic memory checking (it checks for out of bounds access > see the description in the source file NewDelete.cxx) > - it is needed for the shared memory features of ROOT. If the current > directory is a shared memory file all object allocations will be done > in a separate heap mapped to shared memory. Sure, I understand what it is doing, and why it is needed to run some kinds of code. I'm using something else to deal with the first in a much more extensive way, and I'm not using the shared memory features at the moment. Insure++ doesn't play nicely with libNew (I'm not QUITE sure why), so I have good reason not to use libNew while trying to employ this tool. > Zeroing memory is a service provided by ROOT. If you don't use ROOT you are > exposed to the nasty hostile world. Services are great, wonderful things, and I have no problem with them in general. I guess the complaint I have with this one is that it is not provided (nor is it possible to provide it) uniformly, because you cannot (I don't think) intercept a compiler's allocation of memory on the stack. That means that people come to depend on the service, since they usually allocate on the heap; but when in some situation they allocate on the stack, the service does not appear. Then, they have to track down some potentially very hard-to-find bugs (segvios because of invalid pointers are easy; problems with bools or ints or floats which hold garbage can be much harder). If ROOT could guarantee to always zero memory, even in stack allocation, I would have no problem with it, but it can't... can it? Using a ROOT-derived object on the stack is still using root, right? If ROOT didn't zero the memory, all the users would get in the habit of routinely writing their constructors to initialize all variables, because otherwise it will almost always fail; and it will be much easier to catch these kinds of errors during testing of the class being written. George Heintzelman gah@bnl.gov
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:31 MET