Hi George,
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.
Zeroing memory is a service provided by ROOT. If you don't use ROOT you are
exposed to the nasty hostile world. If we would have used a garbage collector
then you would not have had to worry about deleting your objects (which
is the purpose of using a garbage collector). So using a GC but still requiring
to delete your objects would defeat the purpose of the GC. So also zeroed
memory in libNew.
Running without libNew is fully supported by us, except you can not use
TMapFile and you have to initialize all your objects data members and
you are not warned when writing out of bounds.
For example: root-config --nonew --libs
returns the needed ROOT libs without libNew.
Cheers, Fons.
On Fri, Aug 18, 2000 at 08:19:46PM -0400, George Heintzelman wrote:
>
> Rooters,
>
> I was just wondering what the 'official' position was on running
> without libNew. Is this mode officially supported? Since they are
> separate libraries, it is obviously very easy to omit libNew and either
> use the default system on or put in your own.
>
> The reason I ask this is that the way libNew works makes it very easy
> to write wrong code which will fail drastically without it. LibNew
> initializes all of the memory space allocated inside it to 0; and that
> means that people assume that pointer (and other) members in a TObject
> default to 0 (laying aside the issue of the rare compiler that does not
> use all-bits-0 for the null pointer). They do not, of course, in
> ordinary C++ code; they are left unintialized, meaning random garbage,
> unless you initialize them. This is true even on the stack, of course,
> but since the ROOT idiom seems to be strongly slanted towards heap
> allocation*, many users never see the errors that could crop up from
> failure to correctly initialize on the stack.
>
> Now, I am trying to run root and our local root-derived libraries under
> Insure++, a leak/memory misuse detection system that doesn't interact
> very well with libNew (and takes on libNew's functionality and more, so
> there's no point in keeping it around). But because libNew's convenient
> zeroing of members is now gone, I get to deal with all the
> non-initialized problems which people should have seen long ago and
> fixed, even before getting to use the tool to find the real problems
> I'm looking for.
>
> Since the global operator new doesn't get called for static allocation,
> this also provides a very nasty surprise for people who think that code
> has been well-tested -- until someone tries to use one of their object
> on the stack.
>
> So I guess I am suggesting that the zero-ing out provided in libNew is
> more of a curse than a blessing, in the long run, and ought to be
> removed in favor of making (er, helping to encourage) people write
> their constructors correctly the first time.
>
> George Heintzelman
> gah@bnl.gov
>
> *It's so strongly slanted that I've seen people (who have never seen
> C++ outside of Root) write code like this, I kid you not. Don't even
> ask about using contained data members instead of pointers:
>
> void function() {
> TSomeObject *x = new TSomeObject();
> // Do some processing
> // ..
> // ..
>
> delete x;
> }
>
--
Org: CERN, European Laboratory for Particle Physics.
Mail: 1211 Geneve 23, Switzerland
E-Mail: Fons.Rademakers@cern.ch Phone: +41 22 7679248
WWW: http://root.cern.ch/~rdm/ Fax: +41 22 7677910
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 11:50:31 MET