On 04/04/11 18:12, Adriano dos Santos Fernandes wrote:
> On 04-04-2011 10:10, Alex Peshkoff wrote:
>> On 04/04/11 16:40, Adriano dos Santos Fernandes wrote:
>>> On 04-04-2011 09:20, Alex Peshkoff wrote:
>>>> What about always start functions with status parameter - I do not
>>>> agree, because it's not required for upgradeInterface().
>>>>
>>> It's required for correct usage of things by user. Errors must be
>>> reported consistently, with the status parameter.
>>>
>>> Suppose we add a method in V4 which expect just an int parameter. Now
>>> the plugin built initially for V4 has no chance to work with V3, cause
>>> one can't return an error in status. User code should never pass a
>>> function that throw to be used as non-existent methods.
>> This depends upon decision how to report error 'missing function in
>> vtable' for particular interface. If some functions in it require status
>> anyway, use of it in all functions is sooner of all correct. Let me
>> suggest some other ways for other interfaces:
>> 1. All functions return int, on success value >= 0 is returned, on error
>> value < 0 is returned. If we reserve some negative value for missing
>> function in vtable, we just return it in our added function.
> I suppose nobody here wants to create N ways to report errors. Look at
> intl interface mistakes: it can't report any useful error code/message.
>
No problems with such requirement - but not due to need to upgrade
interface :-)
>> 2. Because added function is placed in same module as interface caller
>> (supposing caller does not pass interface somewhere else), the most
>> generic method is throw an exception. It will not pass module boundary,
>> therefore can be caught successfully.
>>
> You would need to support the plugins which has the method and return an
> error explicitly, so don't seems wise to insert such hacks in the design.
>
Let's finish with the following - recommended method for plugin
interfaces is to have status as the first parameter. However, this may
be changed for some plugins if we find it useful later.
>> I agree that in many cases presence of status as the first parameter is
>> very good, but please - let's not add it at least to functions of status
>> itself :-)
>>>>> And I'm not saying it's technically incorrect. I'm saying it's kind of
>>>>> unmaintainable code. Nobody would deduct this release where needed there
>>>>> without a deep analysis on these classes.
>>>> It can be deducted from generic rules of how to work with reference
>>>> counted interfaces.
>>>>
>>> IMO we have some logical problem when trying to use objects who manage
>>> its counter internally with smart pointers asking for them to do it.
>>>
>>> This was clear on the approach of objects being created with refcount=0
>>> and needing external addRef. Seems like a hack to pass them directly to
>>> RefPtr which otherwise would never delete them.
>> I see absolutely no logical problem here.
>> In _this_ aspect OLE2 requirements are very clear and simple.
>>
> I see nothing related to OLE2 here, as you said nobody need to addRef
> after get an object with a method. So here things are ok.
>
> But I disagree that objects must return from its constructor with
> refcount=0. The only "advantage" on this approach is to make this code
> valid:
> RefPtr<T> obj(new T());
>
> But note how bad more common code will do:
> T* obj = new T();
> obj->release(); // will make the refcount go to 0xFFFFFFFF and will
> not release the object
>
Calling operator new or any other function to return an object are 2
different cases. From operator new you for sure get pointer to new
object, and nobody except you knows about it. With function returning an
object - an object may have some non-zero refCount when
return ptr;
is executed. In the time between return and assignment to smart pointer
it may be decreased from other thread - and as the result instead valid
ptr we have a ptr to freed memory. Rules of working with reference
counters were invited except other things to avoid races, and we should
better follow them.
> Code managing the refcounter externally are much clear:
> boost::shared_ptr<T> obj(new T());
> // with T don't needing any refcount support
As long as we talk about operator new - fully agreed. Unfortunately,
this does not work reliably in other cases.
PS. I agree we love to better have clear code. But we also love to have
it reliable, yes?
------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
