On Mon, Sep 10, 2012 at 3:38 PM, Andrew Stitcher <astitc...@redhat.com>wrote:

> On Mon, 2012-09-10 at 15:28 -0400, Rafael Schloming wrote:
> > On Mon, Sep 10, 2012 at 3:23 PM, Andrew Stitcher <astitc...@redhat.com
> >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.


Reply via email to