jez 9b32ed13e4 Some time ago, it was gently suggested to me that XPathValuePtr and XPathExpressionPtr both exposed an implementation detail, because they derive fromboost::shared_ptr, and provided an interface that was inconsisted with the DOM classes, because you accessed the member functions via -> rather than . ... At the time, I was just pleased to have got the XPath stuff done and wasn't really fussed, so I left it. Since then though, it's niggled and niggled away at the back of my mind and now I've decided to do something about it. XPathValuePtr will become XPathValue, with the member functions accessed through the . operator. The XPathValuePtr name and -> member access will be retained for the meantime, so that existing code won't be broken. XPathExpressionPtr will be similarly changed. This commit is the first bit of that work, now I've satisfied myself it's going to be pretty easy so long as I pay proper attention.		2007-10-19 21:59:24 +00:00
..
Arabica	renamed include/Utils to include/Arabica	2007-09-10 17:52:04 +00:00
convert	fixed codecvt specialisation include paths	2007-09-19 17:33:23 +00:00
DOM	fixed namespaces declaration	2007-09-25 19:17:58 +00:00
io	renamed include/Utils to include/Arabica	2007-09-10 17:52:04 +00:00
SAX	fixes for older gcc	2007-09-28 08:30:16 +00:00
text	renamed include/Utils to include/Arabica	2007-09-10 17:52:04 +00:00
XML	more namespace and file moving shenanigans	2007-09-10 17:24:17 +00:00
XPath	Some time ago, it was gently suggested to me that XPathValuePtr and XPathExpressionPtr both exposed an implementation detail, because they derive fromboost::shared_ptr, and provided an interface that was inconsisted with the DOM classes, because you accessed the member functions via -> rather than .	2007-10-19 21:59:24 +00:00
XSLT	reworked MatchExpr so that it doesn't expose its inner XPathExpression	2007-10-14 20:06:27 +00:00