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

Reply via email to