Quoting Ulrik Mikaelsson <[email protected]>:
<snip>
> we SHOULD have a C-API, binding to the C-API is not necessarily the best
> option for other API:s. I have written a C#-binding for current Y, for
> instance, and after binding to the C-API for a while, I threw that idea out
> and implemented the protocol directly in native C# instead. IMHO that gave me
> much cleaner code, more obvious code, code that's consistent all the way out,
> and I think a somewhat better performance, since I did not have to transform
> message structs back and forth all the time, to compensate for the
> programming differences in C# and C.
At the moment, when it's a pure network protocol, this is a reasonable approach.
When we throw whings like shared memory, video ports, and all that junk into
the mix, it might not be so clever. However, that's a decision we should take
when we get there.
Did you try building the library as a managed C component - then it would have
been .netted (to a large extent) without a rewrite. I suspect^W am pretty sure
it won't work, but as the library gets larger it will possibly become cheaper to
shoehorn the C code into a .net-manageable form rather than duplicate
everything.
Of course, it might not. That's the joy of predicting the future...
Phil
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.