On 09-04-2011 08:58, Vlad Khorsun wrote: >> On 08-04-2011 13:43, alexpeshk...@users.sourceforge.net wrote: >>> Revision: 52693 >>> http://firebird.svn.sourceforge.net/firebird/?rev=52693&view=rev >>> Author: alexpeshkoff >>> Date: 2011-04-08 16:43:05 +0000 (Fri, 08 Apr 2011) >>> >>> Log Message: >>> ----------- >>> Use interface IBlrMessage instead passing C++ class pointer to API >>> interface's functions >>> >> I'm *very* against this *undiscussed* change. > > You also against endless discucssions of every tiny code change, isn't is > ? :) > >> Pointer to plain struct is know to be portable and usable by the clients >> we expect to use our API. > > Plain struct ? It was declared as "class", not as "struct", sorry. If you > want understanding > from other developers, please, make you ideas clear. Else there will be such > "incidents". > Something obvious for you is not obvious for me and far not obvious for end > users. This is life. > > 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. 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) And "MessageBuffer" was discussed here in this list and you had all your time to comment on it. > Also, please, when you introduce new class or struct or constant - any > bit of code in API - > please, make comments about its intended usage. Also, please, write > explicitly who is responsible > for implementation of every interface (firebird itself, plugin creator or > application developer) and how > to obtain instance of this interface. This is request for all developers, not > for Adriano only :) API > headers should be as much self documented as possible and new readers should > understand it > without huge efforts. > >> 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. > 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. But if you want to make things more difficult, feel free to make plain struct. Adriano ------------------------------------------------------------------------------ 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
