07.03.2014 13:18, Alex Peshkoff wrote: > On 03/07/14 15:14, Dimitry Sibiryakov wrote: >> There is no difference if you store offset got from a virtual function >> or a pointer got >> from other virtual function. In any case you'll have to perform >> "buffer+offset" operation >> every time you use the same or different buffer. With pointer you can >> receive new pointer >> only if buffer is changed. No difference between >> "buffer+Metadata.getOffset(i)" and >> "Buffer.getData(i)" which has the same "buffer+Metadata.getOffset(i)" inside. > > Certainly, such interface specially oriented on a case when buffer is > not changed may exist. > But offset-oriented interface is required anyway: remember, we get it > from server having no buffer at all.
After prepare we get from server a metadata-only object. There is no need in offsets in this object. Offsets are not a part of metadata at all, IMHO, and their presence in IMessageMetadata is an architectural mistake. > I.e. it will be duplication, which is not good in low level API. What duplication you are talking about? >> Exactly the same way: one just pass next (descendant of) IBuffer to >> fetch() and there >> is no need to worry how this IBuffer keeps information internally. Default >> TPlainBuffer >> can keep all values in single piece of memory, someone can invent >> TScatteredBuffer for any >> reason and so on. Polymorphism will allow server code to work with all of >> them. > > No. To make server work message's buffer should always be plain. > Certainly, we may rework server code and learn it to work with non-plain > buffers, but I see no reason to do it. So do I. But could you point to an example of code where plain data buffer is a requirement? > This requires exactly same thing - learn server to work with non-plain > message buffer. Or to explicit using of plain buffer class which data is copied to if necessary. -- WBR, SD. ------------------------------------------------------------------------------ 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
