$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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.