On Mon, Sep 10, 2012 at 3:38 PM, Andrew Stitcher <[email protected]>wrote:
> On Mon, 2012-09-10 at 15:28 -0400, Rafael Schloming wrote: > > On Mon, Sep 10, 2012 at 3:23 PM, Andrew Stitcher <[email protected] > >wrote: > > > > > On Mon, 2012-09-10 at 15:01 -0400, Rafael Schloming wrote: > > > > Can you comment on why you decided to inline it directly into the C > > > header > > > > files as opposed to splitting it out somehow? Given William's > comment on > > > > exceptions, it seems like it might well expand/evolve enough to make > it > > > > awkward to inline. > > > > > > This was partly for speed, and partly because I tend to think of C and > C > > > ++ as peer languages so that if you're using proton from C++ you would > > > just use the same include files as using it from C. > > > > > > > Isn't there a way to split out the C++ stuff but still use the same > include > > files, e.g. include the C++ stuff rather than inline it? > > What would that gain? In any case if you mean have an extra #include > inside the #ifdef __cplusplus that could certainly be added if the file > got unmanageably large. > > I guess the question here is really the nature of the relationship between the C++ code and the C library. To date I've been able to remain blissfully ignorant of C++. With this stuff in here if I were to make a change to part of the C API (while still remaining blissfully ignorant of C++) then I could quite possibly break the C++ code, and the C portion of the source file might get ahead of the C++ portion of the source file. This is of course an issue with all the other bindings as well, but to some degree it is mitigated by swig managing to do the right thing much of the time. Notably in a couple cases where it doesn't there has been some breakage caused in a similar manner. I guess the root of the question is really package structure/workflow between development on the bindings and development on the core library. To what degree should we treat the bindings as independent packages that track a specific version of the library and might in fact lag it a little, and to what degree do we treat the whole thing as a unit and try to keep all the bindings 100% up to date at all times. I'm not sure about the answer right now, but having the C++ code inline with the C code seems to rule out (or at least make really awkward) the possibility of the C++ binding lagging the C library. On another note, to offer some commentary on the content of the API as opposed to it's delivery mechanism, I think it is a definitely a good thing to have and I'd like to see it included somehow. I'm not really a C++ expert, so I can't comment too deeply, but the one (ok most likely the first) thing I'd say is that the low overhead wrapping approach might actually be more beneficial with the lower level parts of the API that you haven't yet wrapped, whereas the overhead issues with a more idiomatic C++ wrapping of messenger are likely negligible. --Rafael
