Re: [boost] RFC: Boost.XML API prototype in the sandbox

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-07-10 12:31:06

Doug Gregor wrote:
> On Jul 9, 2007, at 11:12 PM, Stefan Seefeld wrote:
>> I'm using here libxml2 as backend

>> I want a seamless mapping that doesn't impose any 
>> unnecessary copying or other indirection to mitigate the 'impedance 
>> mismatch'.

> This is a very, very, very, very, very good approach.

[I have quoted Stefan's words in the hope that I've captured the core 
of what Doug is agreeing so emphatically with - I hope I've got it right.]

Aiming for the minimum overhead in your libxml2 wrapper is a valid 
objective.  But perhaps in that case you should be selling this as a 
"C++ wrapper for libxml2", not as a "Boost XML library"?  I would have 
thought that a largely backend-independent (or self-contained) library 
with STL-like interface would be more "Boost-compatible".

Does anyone have any experience of how little overhead could be 
involved in going from

e.attributes["foo"]="blah";
to
e.set_attribute("foo","blah");
?

Sketch of implementation:

class AttributeProxy {
   Element& e;
   string name;
public:
   AttributeProxy(Element& e_, string name_): e(e_), name(name_) {}
   operator=(string value) { e.set_attribute(name,value); }
};

class Attributes {
   Element& e;
public:
   Attributes(Element& e_): e(e_) {}
   AttributeProxy operator[](string name) { return 
AttributeProxy(e,name); }  // hmm, returns temporary!
};

class Element {
public:
   Attributes attributes;
   Element(): attributes(*this) {}
private:
   set_attribute(string name, string value) { .... }
}

What do current compilers do with that?  What can we expect in the future?

Phil.