On 03/07/14 13:54, Dimitry Sibiryakov wrote: > 07.03.2014 10:44, Alex Peshkoff wrote: >> Yes. That's one of the reasons. Among others is the fact that >> IMessageMetadata may be returned from server after prepare, and at this >> step we have no buffer: it will be allocated after receiving metainfo >> based upon size of message from that info. > I also wonder why buffer is plain void* instead of IBuffer which could > perform > translation of field index into pointer. Such class would save quite a few > mess in every > place where now is written something like this: reinterpret_cast<int*>(buf + > Msg->getOffset(i)).
Main reason is performance compromise. It's faster to store required information from IMessageMetadata somewhere in end-user code and use it to access data instead of calling dozens of virtual functions. For C++ there can be a lot of various wrappers (see for example firebird/Message.h). Probably one can invent similar helpers for other languages. One more reasons to have plain buffer on my mind is use of API for writing various access components (like in Delphi). Component, working with IStatement, typically places rows received from server into set of row buffers. This helps to provide backscrolling, perform lookup operations, etc. It's obvious desire to make fetch() call to place returned data directly to the row buffer. With old SQLDA API it was necessary to change all pointers in SQLDA to achieve it. Currently one can just pass single pointer to next buffer to fetch() - and this job is done. Access to fields is usually performed by other layer of component. I have no idea how can IBuffer performing offset-to-pointer conversions help here. > Besides, it could allow to use any type of buffers, not only plain pool. > For example, > in SQLDA interface it would save the allocation of buffer and moving data > from SQLDA into > it and back. > Not sure it's possible for SQLDA where memory for fields allocated by user. Anyway, optimizing access from SQLDA interface is the last think I care about. In next version we will add namespaces, increase identifier's length - and that old monster will die silently. (Even today to access charset info one needs to get it from different fields for different data types!) ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
