On 01-04-2011 07:14, Alex Peshkoff wrote: > On 03/31/11 19:13, Adriano dos Santos Fernandes wrote: >> On 31-03-2011 07:49, Alex Peshkoff wrote: >> >>>> People would like to detach a parent and not care about statements >>>> created but unfreed for this attachment. >>>> >>> If they do not call addRef for statements, they will be destroyed when >>> attachment goes away >>> >> This is against of what you already said, and in fact destroys the >> concept of recounting. >> >> If I call attachment->allocateStatement, this statement is owned by me >> now, even if I don't call addRef on it. >> > > Sorry. Certainly you are right - looks like I was tired in the evening > and therefore said such foolish thing. >
Now look at this. This, while a not very good practice, is something very used and is how our ISC API work. User detachs an attachment and there is no memory leak from transactions, blobs, statements, etc. And who generally closes all handles? Most probably languages with RAII support, especially C++. But wait, to make RAII work in C++ with our API we don't need refcounters. You're refcounters are to support another bad practice: use after freed. So while them "fix" a very-bad practice, it makes a not so bad to leak memory. >> If someone else calls release on it, they must have called addRef >> before. Then, you have leaks if one releases the attachment and leave >> the statement. > > Certainly. If one requested an object, got it and did not release() in > any way - there is memory leak. > >> So again, two different bad things for two different choices. >> >>>> And for who is using C++ and RAII, they don't need addRef/release in our >>>> objects to use that. >>> Absolutely wrong. >>> >> "Wrong" because you want to support bad practices, of use a object after >> it's freed. >> > > Looks like what you call 'bad practices' is what almost everyone here > wants to support :) > One cannot use free then use a pointer. One cannot delete then use a pointer. This is bad practice. On the other hand, people are used to quit an application and see no memory leaks. They destroy a pool to not delete individual objects. And so on. I think you must really think, your fix to a bad practice is done a damage to normal usage. > Getting serious - certainly, an object can't be used after it's freed. > The question is what we call 'freed'. > In old API freed meant detach/commit was done, but even after it (if > noone allocates about 2**32 handles) correct diagnostics about that > usage was provided. > > That said - certainly people can't use object after it was > detached/dropped/etc. But they have reasons to get correct diagnostics > instead segfault in such a case. As we have agreed, sometimes it's very > hard to guarantee that an attachment is alive even in the next line > after attach was called. And what - segfault? > I will again must say to take another look at the problem. OS kernels has handles or numeric file descriptors. When user mode calls the kernel, kernel verifies it's valid. So as our handles. But if a OS library returns a pointer, there is no protection to wrong usage on them. User must use memory correct, or must use a language with they don't need to deal with it directly. So as our objects must be. Adriano ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
