> On 16/05/2011 13:33, Vlad Khorsun wrote:
>> So, if code calls attach\release - this is bug, as for me, and i see
>> no reasons
>> to write code in this way intentionally. I consider at as very bad practice
>> as it
>> could lead to the inexpected side effects (such as implicit rollback).
>>
> Now every provider class has a way to "release" with another methods,
Again, "release" it not how object should be finally destroyed. It is for
additional references *only*.
> but take into account that release is base method.
Not sure i understand what do you want to say here. addRef\release used
for reference counting and not for creating\destructing objects.
> But what about different release-able classes? Are you going to add
> additional methods to release them, cause release is only for addRef?
Again not sure i understand you correctly. Basically, if something have
*explicit* constructor (attach) it must have explicit destructor (detach). If
something is not constructed *explicitly* (fb_get_master_interface) it should
be just release()'ed without additional methods.
Yes, in a very simple cases we can omit creation of explicit "destructor"
but
i prefer to have it even in simplest case. Your never know if tomorrow simplest
thing will not became more complex ;)
Show me example of what do you mean by "different release-able classes"
and i'll try to be more precisely.
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
