On 04/11/11 16:31, Vlad Khorsun wrote: > We talk there about API *declarations*. API *declarations* ideally > shouldn't have code else > it will be hard to port it into another language. As for struct\interface > choice : > > - struct should be as simple as possible to avoid problems with different > alignment rules of > different compilers\languages > > - struct used as array member should be even more simple to avoid problems > with different rules > of array member alignment > > - struct is very hard to extend in the feature and it have no versioning > (many structures in Win32 > API have fixed first field used for versioning, user *must* fill it with > sizeof(struct) value, btw)
I'm afraid that need to check this version and change code behavior depending on it will give more performance issues than calls to virtual functions. > - interface (pure virtual class) are free from issues above but direct access > to the interface > "members" is impossible and costs virtual function call > > So, we can use struct, yes. But in very limited places. Regarding performance. I've tried to measure performance hit fetching records from create procedure looper(n int) returns(m int) as begin while(n > 0) do begin m = n; n = n - 1; suspend; end end and found no difference, as expected. Expected because I use AMD CPU, which has short pipe line. For intel result may differ. Therefore I tend to agree that my commit should better be reworked. I see the following possible ways to go: 1. Keep interface, but have single function with 4 returned parameters. 2. Use old schema with 4 separate parameters in fetch(). 3. Use POD structure as parameter for fetch. Telling true, I do not have personal what to choose. Each solution has it's obvious '+' and '-'. ------------------------------------------------------------------------------ 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
