I'm not opposed to any of this. I'm opposed to any of this NOW. Even TALKING about it NOW is out of place.
It clogs the communication channels and sucks precious brainpower from the important task at hand: release engineering. I'll write up a more cogent email about the topic, but, in brief: please stop. There will be no GC in 2.0.0. Since I started this whole "thaw" thing, I realize that I need to also be a champion of keeping it limited and timely. Be prepared for lots more flames. Aaron Dan Weber <[EMAIL PROTECTED]> said: > the amount of memory leaks dbmail has is unacceptable, there needs to be > a better solution, a coding style at that even, or resort to some stack > measure. Here is what I wrote to Ilja > > >Btw, you can kill me if you want, but this is the official Dan > solution >for solving memory leaks most of the time. Everything I code > thats my >own project I have a special style for handling these. > > > >1) create a goto section at the bottom of the function for exception > >handling > >2) As I allocate memory put free() for that in the goto section as I > go >along. > >3) make a local definition of an integer call funcError then assign > >defined error codes. > >4) All fail or pass handling be handled in the goto > > However, a better solution might be obstack, which is provided by > libiberty. Its the only thing I have found that implements a method > similar to NSAutoreleasePool. I know I am going against Timo on this > one. I would hate to use glib for this overall, since I just personally > don't like glib. My impression of glib is written by a person couldn't > remember typecasts and wanted to reimplement C++ in C, C++ style. It > has been very successful of imitating C++ in many ways including some of > the problems in C++. If it resorted to that, I'd prefer to use C++. > But as I was saying before, obstack is precisely what is needed. It > provides reference counting and a fairly sane way to handle stacks. > > Dan > > --------------enigF2DF6B5924E6CA118C1CF207 > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: OpenPGP digital signature > Content-Disposition: attachment; filename="signature.asc" > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFA9UjZF6i3K/AxoQERAo5BAJ9tGO0MEEAA3S+wXZRmy4bc5iGg0QCg0E+J > +fCVMK5R9wvBLeJ/ARRRfbc= > =36xw > -----END PGP SIGNATURE----- > > --------------enigF2DF6B5924E6CA118C1CF207-- > > --===============0537742862== --
