11.03.2014 17:09, Alex Peshkoff wrote: > On 03/11/14 19:54, Dimitry Sibiryakov wrote: >> Unfortunately, at the same time it makes any other using as hard as >> possible. >> Flexibility is lacked. > > Did you pay attention to what Adriano suggested? Wrappers on the top of > the API.
Yes, but I disagree with position, see below. > Yes, putting related data in memory together in natural order is a very > useful requirement. Rather "selfish" than "useful". > But what about performance I strongly disagree - using trivial inline > methods in C++ templates is much faster than calling virtual functions. > Each virtual function call means pipeline reset (hmm, at least for known > to me HW, in theory this can be fixed in CPU). If you forgot, I didn't like idea of OO API from the beginning. > No, I prefer all buffers to be 'Kosher'. I prefer Newton and Einstein to be wrong about gravitation because flying is more convenient than walking. But we have to live with reality. ;) >> No. Current message buffers are uncompressed. You won't be able send it >> as is unless >> you add another requirement for users: provide the buffer in compressed >> format. But you >> can't do it without breaking backward compatibility. Dead end. > > I can compress it myself as a whole block. And this lead to another requirement: to fill buffer with zeros before using. As Ann and Jim said more than once, encoding is better than compressing. > What a problem if that conversion (if needed) is done by wrapper? No problem. And the wrapper named JStatement is the best candidate for this job because it is always aware of current requirements. -- WBR, SD. ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
