>> Btw, i see no problem curently. Alex made change but it is not means it
>> can't be undone if
>> necessary.
>>
> Ah, that's it. Every change I do, specially from you come this discurse
> of where the thing was discussed.
>
> But for others, no. It's just a commit that can be undone.
This is just not true. And i'm not going to waste my time to argue about
this.
> BTW what about if I just came to whole plugin thing and just removed the
> reference counters because it was obviously wrong? Is it just a piece of
> code that was write to be undone? (at least it appears to be till now,
> cause the implementation is currently broken)
If you'll remove something then there are two choices always :
a) it will be accepted by team
b) it will not be accepted by team
in the case (b) someone will undo this removal.
> And "MessageBuffer" was discussed here in this list and you had all your
> time to comment on it.
I look at (not mine) code when i have time and need to look at it. If you
think that i looking
with microscope at every your change just to find a way to undo it - you are
terrible wrong.
I have more important things to do, believe me ;)
>>> This change puts a very number of extra virtual call for each (from each
>>> layer) method called. Considering the methods involved are ones that are
>>> heavily called, this is going to make a vary large overhead.
>>
>> Could you point me - where do you see the large overhead ? Probably i
>> missed some loop with
>> hundreds calls of this methods ? Or it is just a few calls per whole API
>> call ?
>>
> To retrieve records, to insert records. Records * 4 *unnecessary*
> virtual calls at least.
a) all methods have no parameters so there is no stack allocation
b) 4 virtual calls per few thousands another instructions not looks as killer
overhead
>> I see no problem to revert this change in favor of "struct", but i'm
>> against "class" in public API.
>> Public API should use "struct" (as it have no methods) and pure virtual
>> classes (as it have no data
>> and no methods implemented). Else at some day someone will add methods into
>> your POD "class
>> Message" and ruin our public API.
>>
> If you understand C++ well you would understand that for C++ usage (this
> is a C++ header, after all) inline non-virtual methods and constructors
> would not make any damage to our interfaces.
When you start to port this C++ header into another language, you will
understand what i wrote.
Regards,
Vlad
PS Alex will explain you why "struct" or "class with data members" is bad for
*portable* code.
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
