On 05/17/11 11:41, Vlad Khorsun wrote: >> On 05/16/11 23:47, Vlad Khorsun wrote: >>>> 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. >>> >> Vlad, let's start with the following - why is calling release() to >> remove last reference is bad? > Because it opens a way to make bugs - rolled back work, for example. > >> Currently I see just one reason - error can't be reported. What if we >> find a way to report an error in such case? > What error do you mean ? At previous message you said that release() > could > be called if detach() failed. Do you see a problem if release() also will > fail ? Or > you talk about something else ? >
Treat it as enumeration of possible solutions. :) What about the following - we always pass status vector to release(). It's not a problem technically - IStatus is not refCounted. We use it in 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. 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. >>>> 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. >> Vlad, I'm afraid that this difference is not enough precise... > attach() constructed object for *my private use* and i'm responcible for > *destroying* it after use. > > getFirebirdConf(), in general, could return some *common* object instance > > and i can't destroy it - i just must *release* it after usage. > > Difference between "destoy" and "release" is semantics. I don't know how > to explain it else. > _I_ understand you. But not sure it's OK for documentation POV. Notice - if we add status vector to release, the problem is almost gone. We may just say: people, always check error status please. ------------------------------------------------------------------------------ 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
