Re: [Firebird-devel] Providers, yvalve, external engines and object lifecycle

[Alex P. <pes...@ma...>]

 On 03/24/11 16:50, Adriano dos Santos Fernandes wrote:
> On 24-03-2011 06:14, Alex Peshkoff wrote:
>>  On 03/23/11 17:29, Adriano dos Santos Fernandes wrote:
>>>> Adriano, are you serious that all described here is simpler than proxy
>>>> objects in engine? :-)
>>>>
>>> I'm *sure* it is. I showed you ~15 lines of code, against
>>> addRefs/releases around by Firebird and all-over-the-world users code.
>> Most of addRef/release in firebird are done using smart pointers.
>> Therefore this is not a problem.
>>
> Of course it is. Currently why.cpp is completely unnecessarily
> overloaded by RefPtrs, References, etc. I'm rewriting it in much simple way.
>

Adriano PLEASE do not hurry too much.
We still have no decision on a problem...

>> What about users code - if user is not going to use an object in complex
>> MT environment he need not care about reference counters at all. May be
>> you did not pay attention, but detach, commit and all other calls,
>> closing handle, perform release automatically on successful completion.
>>
>> In MT environment existing inside exported object reference counters
>> will just help to minimize user code - remember your own words that if
>> someone needs MT safety he will have to completely implement logic
>> himself without reference counters?
>>
> Please let me know, with details, what *user* problem you want to solve
> making *user* call addRef in his MT program.

Big desire to recommend you to read microsoft's com-related
documentation :-)
In 2 words problem is as follows - avoid segfault when pointer to
already non-existing interface is used.