> On 16/05/2011 14:12, Vlad Khorsun wrote:
>>> 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*.
>>
> This is something new you invented.
You asked about semantics and i explained how i understand it. If you have
something technical against it - show it here and we'll decide what to do.
>>> 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.
>>
> See above.
I see nothing, are you ?
>>> 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.
>>
> Everything is constructed explicitly.
I'm not agree here. See below.
>> 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.
>>
> IFirebirdConf and IPluginConf, for example. They're released with release.
IPluginConf is not constructed explicitly from the user POV - it is created
by the Firebird and passed into user code, see :
IPluginFactory::createPlugin(IPluginConfig* factoryParameter), where
user is implemented IPluginFactory interface.
IFirebirdConf also not constructed by user request as it is obtained via
method of IPluginConfig instance passed above :
IFirebirdConf* IPluginConfig::getFirebirdConf()
If you ask me why attach() and getFirebirdConf() is different - the answer
is : by semantics. And by presence explicit "destructor" function.
> The situation with new classes trying to be smart using reference
> counting is still almost unexplained from the POV of why that was done.
>
> Sure you may create artificial and specific examples of where they make
> things to not crash.
>
> But nothing except an atomic counter is currently being cared regard
> MT-safeness. Y-valve has internal state not synchronized, for example.
> Y-valve delegates call to another providers, and they do nothing re.
> died objects to return information.
This is still work in progress, i think. Probably Alex have better answer.
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
