On Thu, 2007-10-25 at 21:21 -0400, Andrew Stitcher wrote:
> I agree with most of Alan's thoughts, but see below.
>
> Alan Conway wrote:
> > We use boost heavily in the C++ implementation, the question arises
> > whether we use it in the public API. We do link with boost libraries so
> > we will require boost runtimes to be installed regardless.
> >
> > There are 3 levels:
> > 0 - No boost includes in public header files. We do not require boost
> > developer package (header files) to be installed.
> >
> > 1 - Private/implicit use of boost. We do require boost-devel headers
> > installed for Qpid developers but we don't require the user to know
> > anything about boost or even be aware we're using it.
> >
> > 2 - Public use of boost: we include boost types in the public API.
> >
> > I've been convinced that 2 is bad as it ties us to boost for future
> > source-compatibility. We have some work to do to eliminate
> > boost::shared_ptr from the current API but I think it's reasonable and
> > all the client API needs can be met without it.
> >
> Completely agree here, but I'm not convinced that there is so much
> difference. As the difference here is that you could in theory
I guess that was interrupted - what were you going to say?
As long as you'll let me use boost keywords for the client API I'm happy
to kick out shared_ptr - actually I don't like it anymore since I've
realized what a heap hog it is, I'd like to generally replace it with a
traditional RefCounted base class for internal purposes (although I
still like boost::intrusive_ptr as the smart pointer :)
I will also buy the argument that we shouldn't use boost::variant as the
API for field table values, although I would argue we could profitably
use it as the *implementation* to reduce heap allocation. boost::any is
another candidate for that. I'd like to lose the clunky getFoo() API
field table API.
What do you think of this as an API:
class FieldValue {
template <class T> bool is() const; // True if is of type T.
template <class T> T& get() const; // throw BadTypeException if not T
template <class T> void put(const T&);
template <class T> operator=(const T& t) { put(t); }
// I'll stop short of a template <class T> operator T() !!
};
typedef std::map<FieldValue> FieldTable;
// Probably not an actual typedef but equivalent API.
We can use various techniques to make this type safe in the sense that
trying to instantiate FieldValue template methods with T that is not a
valid field table type will be a compile-time error. FieldValue could be
implemented with boost::variant, boost::any, qpid::framing::Blob or some
other discriminated-union approach.
