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. > 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 :) 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? >>> Well, if you want to say that someone is correct just because chose the >>> COM way, then we would need to say we're incorrect because we don't use >>> queryInterface... >> In many aspects use of queryInterface might be ideal. Two main reasons >> why we can't use it: >> - it will cause additional delays in time-critical places like fetching >> next record, >> - it will pollute each place in the code where we work with plugins. >> >> On the other hand I see no problems with adding that method to our >> interfaces, specially if it's needed to make Delphi people life easier. >> It does not conflict with our versioning support. >> > This is looking like a Frankenstein... To be precise - I see no tech problem. Logically it's not needed for our interface. ------------------------------------------------------------------------------ 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
