>>> the following way - if refCounter>  1, no error happened (later it
>>> always means that nothing like system call failed took place). If
>>> refCounter == 1 and object has no special dtor, again no error happened.
>>      If object have no explicit destructor then release must be called, no 
>> problem.
>>
> Your words are very incongruent. "Release" releases, and shall be valid 
> for any objects.

    Where i said it is not valid ? Current code not disabled it in any way. You 
can
call release event for last reference if you wish. But this is wrong practice 
and 
should be avoided.
 
> You broke the IAttachment from external engines, with are only 
> release-able. They should not be dropped or detached.

    If you would be more technical it will help to understand characters you 
wrote
here. So far i don't understand what i broke, why IAttachment from external 
engines
are only release-able while IAttachment from y-valve is detach-able (maybe 
something
wrong in external engines ?) and why they should not be dropped or detached.

    I can guess that *internal attachment* should not be detach'ed but this is 
perfectly
fits "my model" as it was not attach'ed by external engine code. But i can't 
even guess
why *externla attachment* can't be detach'ed...

> Making the release an error is like create private destructors. You 
> could do it, but difficultly you may justify it.

    If you'll play by proposed rules all will be ok. So far you gave zero 
technical reasons
agains this rules, only emotions and offence.

>>> But if we release something like transaction and due to it rollback some
>>> job - transaction is released (what can we do?), but error (or may be
>>> better warning? not sure...) is reported - job was implicitly rolled back.
>>      You can kill me, but i don't understand - why do we want to call 
>> release,
>> if good special explicit destructor is present ???
>>
>> ...
> Why are we adding addRef/release after all?
> 
> To support wrong code and solve nothing. With the cost of all this mess, 
> all this otherwise unneeded discussion, all the global/local pool mess.

    ...only emotions and offence...

Regards,
Vlad

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to