That's simple. It throws an exception. Or, if you want, it does an automatic
rollback (logically correct, but probably more dangerous).
Jim Starkey
> On Feb 25, 2015, at 4:43 PM, Dmitry Yemanov wrote:
>
> 25.02.2015 23:28, Dimitry Sibiryakov wrote:
>
>> make release() the only "destroy met
Sorry. This is decades old technology. A destroy method is utterly
incompatible with reference counting. Logically, it has to be this way.
Anyone who is a passed a pointer is free to keep the pointer by increasing the
reference count but is obligated to release it when finished. It follows t
25.02.2015 23:28, Dimitry Sibiryakov wrote:
> make release() the only "destroy method"
And what's supposed to do for e.g. transactions? Commit or rollback?
Besides, "destroy methods" report the status while release() obviously
does not.
Dmitry
---
25.02.2015 16:20, Dmitry Yemanov wrote:
> IObject* obj = ...
> ...
> obj->something(status); // success
> ...
> obj->destroy(status); // detach / commit / cancel / etc
> ...
> obj->something(status); // returns "bad handle" error
> ...
> obj->release(); // destroys the object (if use_count reaches
23.02.2015 13:36, Vlad Khorsun wrote:
>> A solution must be to pass a parameter to destroy methods specifying if
>> they should release or not the object.
>
> Must be ? I don't think so. I'm not ready to point to correct solution
> right now, but additional parameter is not a solution, as for me.
On 02/23/15 13:47, Adriano dos Santos Fernandes wrote:
> On 23/02/2015 07:36, Vlad Khorsun wrote:
>> 22.02.2015 20:11, Adriano dos Santos Fernandes wrote:
>>
>>> A solution must be to pass a parameter to destroy methods specifying if
>>> they should release or not the object.
>> Must be ? I don
Guys, this is a little crazy. When the reference count goes to zero, the
object goes away. That's the point of reference counting. If an object is
reference counted, it shouldn' have a destroy method or a public destructor.
And, of course, a provider has exactly the same semantics as the Y-valv
On 23/02/2015 07:36, Vlad Khorsun wrote:
> 22.02.2015 20:11, Adriano dos Santos Fernandes wrote:
>
>> A solution must be to pass a parameter to destroy methods specifying if
>> they should release or not the object.
>Must be ? I don't think so. I'm not ready to point to correct solution
> right
22.02.2015 20:11, Adriano dos Santos Fernandes wrote:
> A solution must be to pass a parameter to destroy methods specifying if
> they should release or not the object.
Must be ? I don't think so. I'm not ready to point to correct solution
right now, but additional parameter is not a solution,
22.02.2015 19:11, Adriano dos Santos Fernandes wrote:
> A solution must be to pass a parameter to destroy methods specifying if
> they should release or not the object.
More dragon poker - more fun.
> And of course, all implementations should follow it.
>
> So with or without smart pointers, u
On 22-02-2015 14:51, Dimitry Sibiryakov wrote:
> 22.02.2015 18:35, Adriano dos Santos Fernandes wrote:
>> So you have:
>>
>> IBlob* blob = ...->openBlob(...);
>> blob->cancel();
>> // no leak
>
>Using of smart pointers here makes life even funnier. IMHO, it is Y-valve
> bug.
>But in absen
22.02.2015 18:35, Adriano dos Santos Fernandes wrote:
> So you have:
>
> IBlob* blob = ...->openBlob(...);
> blob->cancel();
> // no leak
Using of smart pointers here makes life even funnier. IMHO, it is Y-valve
bug.
But in absence of API specifications it is rather "as expected".
--
W
Hi!
Lets call YBlob::cancel, YTransaction::commit, YTransaction::rollback,
YEvents::cancel and maybe others as "destroy methods".
Destroy methods when called in y-valve objects automatically does a
"release" on them.
So you have:
IBlob* blob = ...->openBlob(...);
blob->cancel();
// no leak
On
13 matches
Mail list logo
