2005-08-04 23:23:48 +02:00
# ifndef XPATHIC_EXECUTE_TEST_HPP
# define XPATHIC_EXECUTE_TEST_HPP
2005-10-16 00:45:24 +02:00
# include "../CppUnit/framework/TestCase.h"
# include "../CppUnit/framework/TestSuite.h"
# include "../CppUnit/framework/TestCaller.h"
# include <XPath/XPath.hpp>
2007-09-05 00:55:47 +02:00
# include <DOM/Simple/DOMImplementation.hpp>
2005-10-16 00:45:24 +02:00
template < class string_type , class string_adaptor >
2005-10-17 13:48:44 +02:00
class StringVariableResolver : public Arabica : : XPath : : VariableResolver < string_type , string_adaptor >
2005-10-16 00:45:24 +02:00
{
public :
2010-01-10 18:07:41 +01:00
virtual Arabica : : XPath : : XPathValue < string_type , string_adaptor > resolveVariable ( const string_type & /* namespace_uri */ ,
2007-07-19 18:57:04 +02:00
const string_type & name ) const
2005-10-16 00:45:24 +02:00
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-24 05:33:52 +02:00
typename VarMap : : const_iterator n = map_ . find ( name ) ;
2005-10-16 00:45:24 +02:00
if ( n = = map_ . end ( ) )
throw UnboundVariableException ( string_adaptor : : asStdString ( name ) ) ;
2007-10-22 19:42:50 +02:00
return XPathValue < string_type , string_adaptor > ( new StringValue < string_type , string_adaptor > ( ( * n ) . second ) ) ;
2005-10-16 00:45:24 +02:00
} // resolveVariable
void setVariable ( const string_type & name , const string_type & value )
{
map_ [ name ] = value ;
} // setVariable
private :
typedef std : : map < string_type , string_type > VarMap ;
VarMap map_ ;
} ; // StringVariableResolver
template < class string_type , class string_adaptor >
2005-10-17 13:48:44 +02:00
class NodeSetVariableResolver : public Arabica : : XPath : : VariableResolver < string_type , string_adaptor >
2005-10-16 00:45:24 +02:00
{
2005-10-22 05:18:28 +02:00
//typedef string_adaptorstring_adaptor;
2005-10-16 00:45:24 +02:00
public :
2010-01-10 18:07:41 +01:00
virtual Arabica : : XPath : : XPathValue < string_type , string_adaptor > resolveVariable ( const string_type & /* namepace_uri */ ,
2007-07-19 18:57:04 +02:00
const string_type & name ) const
2005-10-16 00:45:24 +02:00
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-24 05:33:52 +02:00
typename VarMap : : const_iterator n = map_ . find ( name ) ;
2005-10-16 00:45:24 +02:00
if ( n = = map_ . end ( ) )
throw UnboundVariableException ( string_adaptor : : asStdString ( name ) ) ;
2007-10-22 19:42:50 +02:00
return XPathValue < string_type , string_adaptor > ( new NodeSetValue < string_type , string_adaptor > ( ( * n ) . second ) ) ;
2005-10-16 00:45:24 +02:00
} // resolveVariable
2007-09-08 01:52:30 +02:00
void setVariable ( const string_type & name , const Arabica : : XPath : : NodeSet < string_type , string_adaptor > & value )
2005-10-16 00:45:24 +02:00
{
map_ [ name ] = value ;
} // setVariable
private :
2007-09-08 01:52:30 +02:00
typedef std : : map < string_type , Arabica : : XPath : : NodeSet < string_type , string_adaptor > > VarMap ;
2005-10-16 00:45:24 +02:00
VarMap map_ ;
} ; // class NodeSetVariableResolver
template < class string_type , class string_adaptor >
2005-10-17 13:48:44 +02:00
class TestFunction : public Arabica : : XPath : : XPathFunction < string_type , string_adaptor >
2005-10-16 00:45:24 +02:00
{
2005-10-22 05:18:28 +02:00
//typedef string_adaptorstring_adaptor;
2005-10-16 00:45:24 +02:00
public :
2007-10-25 22:42:00 +02:00
TestFunction ( const std : : vector < Arabica : : XPath : : XPathExpression < string_type , string_adaptor > > & args ) :
2005-10-17 13:48:44 +02:00
Arabica : : XPath : : XPathFunction < string_type , string_adaptor > ( 0 , 0 , args ) { }
2005-10-16 00:45:24 +02:00
2007-12-19 00:03:16 +01:00
virtual Arabica : : XPath : : ValueType type ( ) const { return Arabica : : XPath : : STRING ; }
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 23:59:24 +02:00
virtual Arabica : : XPath : : XPathValue_impl < string_type , string_adaptor > * evaluate ( const Arabica : : DOM : : Node < string_type , string_adaptor > & context ,
2010-01-10 18:07:41 +01:00
const Arabica : : XPath : : ExecutionContext < string_type , string_adaptor > & /* executionContext */ ) const
2005-10-16 00:45:24 +02:00
{
string_type name = string_adaptor : : construct_from_utf8 ( " test- " ) ;
string_adaptor : : append ( name , context . getLocalName ( ) ) ;
2005-10-17 13:48:44 +02:00
return new Arabica : : XPath : : StringValue < string_type , string_adaptor > ( name ) ;
2005-10-16 00:45:24 +02:00
} // evaluate
} ; // TestFunction
template < class string_type , class string_adaptor >
2010-02-20 22:56:47 +01:00
class TestFunctionResolver : public Arabica : : XPath : : NullFunctionResolver < string_type , string_adaptor >
2005-10-16 00:45:24 +02:00
{
2005-10-22 05:18:28 +02:00
//typedef string_adaptorstring_adaptor;
2005-10-16 00:45:24 +02:00
public :
2007-07-19 18:57:04 +02:00
virtual Arabica : : XPath : : XPathFunction < string_type , string_adaptor > * resolveFunction (
2010-01-10 18:07:41 +01:00
const string_type & /* namespace_uri */ ,
2007-07-19 18:57:04 +02:00
const string_type & name ,
2007-10-25 22:42:00 +02:00
const std : : vector < Arabica : : XPath : : XPathExpression < string_type , string_adaptor > > & argExprs ) const
2005-10-16 00:45:24 +02:00
{
if ( name = = string_adaptor : : construct_from_utf8 ( " test-function " ) )
return new TestFunction < string_type , string_adaptor > ( argExprs ) ;
return 0 ;
} // resolveFunction
} ; // class TestFunctionResolver
template < class string_type , class string_adaptor >
class ExecuteTest : public TestCase
{
2007-09-08 01:52:30 +02:00
Arabica : : XPath : : XPath < string_type , string_adaptor > parser ;
Arabica : : DOM : : DOMImplementation < string_type , string_adaptor > factory_ ;
Arabica : : DOM : : Document < string_type , string_adaptor > document_ ;
2005-10-16 00:45:24 +02:00
2007-09-08 01:52:30 +02:00
Arabica : : DOM : : Element < string_type , string_adaptor > root_ ;
2005-10-16 00:45:24 +02:00
2007-09-08 01:52:30 +02:00
Arabica : : DOM : : Element < string_type , string_adaptor > element1_ ;
Arabica : : DOM : : Element < string_type , string_adaptor > element2_ ;
Arabica : : DOM : : Element < string_type , string_adaptor > element3_ ;
Arabica : : DOM : : Element < string_type , string_adaptor > spinkle_ ;
2005-10-16 00:45:24 +02:00
2007-09-08 01:52:30 +02:00
Arabica : : DOM : : Attr < string_type , string_adaptor > attr_ ;
2005-10-16 00:45:24 +02:00
2007-09-08 01:52:30 +02:00
Arabica : : DOM : : Text < string_type , string_adaptor > text_ ;
2005-10-16 00:45:24 +02:00
2007-09-08 01:52:30 +02:00
Arabica : : DOM : : Comment < string_type , string_adaptor > comment_ ;
2005-10-16 00:45:24 +02:00
2007-09-08 01:52:30 +02:00
Arabica : : DOM : : ProcessingInstruction < string_type , string_adaptor > processingInstruction_ ;
2005-10-16 00:45:24 +02:00
2007-09-08 01:52:30 +02:00
Arabica : : DOM : : Document < string_type , string_adaptor > chapters_ ;
2005-10-16 00:45:24 +02:00
2007-09-08 01:52:30 +02:00
Arabica : : DOM : : Document < string_type , string_adaptor > numbers_ ;
2005-10-16 00:45:24 +02:00
typedef string_adaptor SA ;
public :
ExecuteTest ( std : : string name ) : TestCase ( name )
{
} // ExecuteTest
void setUp ( )
{
2007-09-08 01:52:30 +02:00
factory_ = Arabica : : SimpleDOM : : DOMImplementation < string_type , string_adaptor > : : getDOMImplementation ( ) ;
2005-10-16 00:45:24 +02:00
document_ = factory_ . createDocument ( SA : : construct_from_utf8 ( " " ) , SA : : construct_from_utf8 ( " root " ) , 0 ) ;
root_ = document_ . getDocumentElement ( ) ;
element1_ = document_ . createElement ( SA : : construct_from_utf8 ( " child1 " ) ) ;
element2_ = document_ . createElement ( SA : : construct_from_utf8 ( " child2 " ) ) ;
element3_ = document_ . createElement ( SA : : construct_from_utf8 ( " child3 " ) ) ;
element1_ . setAttribute ( SA : : construct_from_utf8 ( " one " ) , SA : : construct_from_utf8 ( " 1 " ) ) ;
element2_ . setAttribute ( SA : : construct_from_utf8 ( " one " ) , SA : : construct_from_utf8 ( " 1 " ) ) ;
element2_ . setAttribute ( SA : : construct_from_utf8 ( " two " ) , SA : : construct_from_utf8 ( " 1 " ) ) ;
element2_ . setAttribute ( SA : : construct_from_utf8 ( " three " ) , SA : : construct_from_utf8 ( " 1 " ) ) ;
element2_ . setAttribute ( SA : : construct_from_utf8 ( " four " ) , SA : : construct_from_utf8 ( " 1 " ) ) ;
text_ = document_ . createTextNode ( SA : : construct_from_utf8 ( " data " ) ) ;
comment_ = document_ . createComment ( SA : : construct_from_utf8 ( " comment " ) ) ;
processingInstruction_ = document_ . createProcessingInstruction ( SA : : construct_from_utf8 ( " target " ) , SA : : construct_from_utf8 ( " data " ) ) ;
element2_ . appendChild ( text_ ) ;
spinkle_ = document_ . createElement ( SA : : construct_from_utf8 ( " spinkle " ) ) ;
element2_ . appendChild ( spinkle_ ) ;
element2_ . appendChild ( comment_ ) ;
element2_ . appendChild ( processingInstruction_ ) ;
attr_ = element1_ . getAttributeNode ( SA : : construct_from_utf8 ( " one " ) ) ;
root_ . appendChild ( element1_ ) ;
root_ . appendChild ( element2_ ) ;
root_ . appendChild ( element3_ ) ;
chapters_ = factory_ . createDocument ( SA : : construct_from_utf8 ( " " ) , SA : : construct_from_utf8 ( " document " ) , 0 ) ;
chapters_ . getFirstChild ( ) . appendChild ( chapters_ . createElement ( SA : : construct_from_utf8 ( " chapter " ) ) ) . appendChild ( chapters_ . createTextNode ( SA : : construct_from_utf8 ( " one " ) ) ) ;
chapters_ . getFirstChild ( ) . appendChild ( chapters_ . createElement ( SA : : construct_from_utf8 ( " chapter " ) ) ) . appendChild ( chapters_ . createTextNode ( SA : : construct_from_utf8 ( " two " ) ) ) ;
chapters_ . getFirstChild ( ) . appendChild ( chapters_ . createElement ( SA : : construct_from_utf8 ( " chapter " ) ) ) . appendChild ( chapters_ . createTextNode ( SA : : construct_from_utf8 ( " three " ) ) ) ;
chapters_ . getFirstChild ( ) . appendChild ( chapters_ . createElement ( SA : : construct_from_utf8 ( " chapter " ) ) ) . appendChild ( chapters_ . createTextNode ( SA : : construct_from_utf8 ( " four " ) ) ) ;
chapters_ . getFirstChild ( ) . appendChild ( chapters_ . createElement ( SA : : construct_from_utf8 ( " chapter " ) ) ) . appendChild ( chapters_ . createTextNode ( SA : : construct_from_utf8 ( " five " ) ) ) ;
numbers_ = factory_ . createDocument ( SA : : construct_from_utf8 ( " " ) , SA : : construct_from_utf8 ( " doc " ) , 0 ) ;
numbers_ . getFirstChild ( ) . appendChild ( numbers_ . createElement ( SA : : construct_from_utf8 ( " number " ) ) ) . appendChild ( numbers_ . createTextNode ( SA : : construct_from_utf8 ( " 1 " ) ) ) ;
numbers_ . getFirstChild ( ) . appendChild ( numbers_ . createElement ( SA : : construct_from_utf8 ( " number " ) ) ) . appendChild ( numbers_ . createTextNode ( SA : : construct_from_utf8 ( " 2 " ) ) ) ;
numbers_ . getFirstChild ( ) . appendChild ( numbers_ . createElement ( SA : : construct_from_utf8 ( " number " ) ) ) . appendChild ( numbers_ . createTextNode ( SA : : construct_from_utf8 ( " 3 " ) ) ) ;
numbers_ . getFirstChild ( ) . appendChild ( numbers_ . createElement ( SA : : construct_from_utf8 ( " number " ) ) ) . appendChild ( numbers_ . createTextNode ( SA : : construct_from_utf8 ( " 4 " ) ) ) ;
numbers_ . getFirstChild ( ) . appendChild ( numbers_ . createElement ( SA : : construct_from_utf8 ( " number " ) ) ) . appendChild ( numbers_ . createTextNode ( SA : : construct_from_utf8 ( " 5 " ) ) ) ;
numbers_ . getFirstChild ( ) . appendChild ( numbers_ . createElement ( SA : : construct_from_utf8 ( " number " ) ) ) . appendChild ( numbers_ . createTextNode ( SA : : construct_from_utf8 ( " 6 " ) ) ) ;
numbers_ . getFirstChild ( ) . appendChild ( numbers_ . createElement ( SA : : construct_from_utf8 ( " number " ) ) ) . appendChild ( numbers_ . createTextNode ( SA : : construct_from_utf8 ( " 7 " ) ) ) ;
numbers_ . getFirstChild ( ) . appendChild ( numbers_ . createElement ( SA : : construct_from_utf8 ( " number " ) ) ) . appendChild ( numbers_ . createTextNode ( SA : : construct_from_utf8 ( " 8 " ) ) ) ;
numbers_ . getFirstChild ( ) . appendChild ( numbers_ . createElement ( SA : : construct_from_utf8 ( " number " ) ) ) . appendChild ( numbers_ . createTextNode ( SA : : construct_from_utf8 ( " 9 " ) ) ) ;
} // setUp
void test1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-25 22:42:00 +02:00
XPathExpression < string_type , string_adaptor > xpath ;
2005-11-09 22:13:22 +01:00
xpath = parser . compile ( SA : : construct_from_utf8 ( " root " ) ) ;
2007-12-19 00:03:16 +01:00
assertValuesEqual ( NODE_SET , xpath . type ( ) ) ;
2007-10-25 22:42:00 +02:00
XPathValue < string_type , string_adaptor > result = xpath . evaluate ( document_ ) ;
2005-10-16 00:45:24 +02:00
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
Arabica : : DOM : : Node < string_type , string_adaptor > n = result . asNodeSet ( ) [ 0 ] ;
2005-10-16 00:45:24 +02:00
assertTrue ( root_ = = n ) ;
} // test1
void test2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-25 22:42:00 +02:00
XPathExpression < string_type , string_adaptor > xpath = parser . compile ( SA : : construct_from_utf8 ( " root/child2 " ) ) ;
2007-12-19 00:03:16 +01:00
assertValuesEqual ( NODE_SET , xpath . type ( ) ) ;
2007-10-25 22:42:00 +02:00
XPathValue < string_type , string_adaptor > result = xpath . evaluate ( document_ ) ;
2005-10-16 00:45:24 +02:00
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
Arabica : : DOM : : Node < string_type , string_adaptor > n = result . asNodeSet ( ) [ 0 ] ;
2005-10-16 00:45:24 +02:00
assertTrue ( element2_ = = n ) ;
} // test2
void test3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-25 22:42:00 +02:00
XPathExpression < string_type , string_adaptor > xpath = parser . compile ( SA : : construct_from_utf8 ( " root/* " ) ) ;
2007-12-19 00:03:16 +01:00
assertValuesEqual ( NODE_SET , xpath . type ( ) ) ;
2007-10-25 22:42:00 +02:00
XPathValue < string_type , string_adaptor > result = xpath . evaluate ( document_ ) ;
2005-10-16 00:45:24 +02:00
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 3 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element1_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 1 ] ) ;
assertTrue ( element3_ = = result . asNodeSet ( ) [ 2 ] ) ;
2005-10-16 00:45:24 +02:00
} // test4
void test4 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-25 22:42:00 +02:00
XPathExpression < string_type , string_adaptor > xpath = parser . compile ( SA : : construct_from_utf8 ( " root/*/text() " ) ) ;
2007-12-19 00:03:16 +01:00
assertValuesEqual ( NODE_SET , xpath . type ( ) ) ;
2007-10-25 22:42:00 +02:00
XPathValue < string_type , string_adaptor > result = xpath . evaluate ( document_ ) ;
2005-10-16 00:45:24 +02:00
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( text_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( text_ . getNodeValue ( ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // test4
void test5 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-25 22:42:00 +02:00
XPathExpression < string_type , string_adaptor > xpath = parser . compile ( SA : : construct_from_utf8 ( " root/*/text() " ) ) ;
assertTrue ( text_ . getNodeValue ( ) = = xpath . evaluateAsString ( document_ ) ) ;
2005-10-16 00:45:24 +02:00
} // test5
void test6 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-25 22:42:00 +02:00
XPathExpression < string_type , string_adaptor > xpath = parser . compile ( SA : : construct_from_utf8 ( " * " ) ) ;
2007-12-19 00:03:16 +01:00
assertValuesEqual ( NODE_SET , xpath . type ( ) ) ;
2005-10-16 00:45:24 +02:00
2007-10-25 22:42:00 +02:00
XPathValue < string_type , string_adaptor > result = xpath . evaluate ( document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( root_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
2007-10-25 22:42:00 +02:00
result = xpath . evaluate ( root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 3 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element1_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 1 ] ) ;
assertTrue ( element3_ = = result . asNodeSet ( ) [ 2 ] ) ;
2005-10-16 00:45:24 +02:00
2007-10-25 22:42:00 +02:00
result = xpath . evaluate ( element1_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 0 , result . asNodeSet ( ) . size ( ) ) ;
2005-10-16 00:45:24 +02:00
2007-10-25 22:42:00 +02:00
result = xpath . evaluate ( element2_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
2005-10-16 00:45:24 +02:00
2007-10-25 22:42:00 +02:00
result = xpath . evaluate ( element3_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 0 , result . asNodeSet ( ) . size ( ) ) ;
2005-10-16 00:45:24 +02:00
} // test6
void test7 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-25 22:42:00 +02:00
XPathExpression < string_type , string_adaptor > xpath = parser . compile ( SA : : construct_from_utf8 ( " /root " ) ) ;
2005-10-16 00:45:24 +02:00
2007-10-25 22:42:00 +02:00
XPathValue < string_type , string_adaptor > result = xpath . evaluate ( document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( root_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
2007-10-25 22:42:00 +02:00
result = xpath . evaluate ( text_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( root_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // test7
void test8 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-16 00:45:24 +02:00
StandardNamespaceContext < string_type , string_adaptor > nsContext ;
nsContext . addNamespaceDeclaration ( SA : : construct_from_utf8 ( " urn:something:or:other " ) , SA : : construct_from_utf8 ( " ns " ) ) ;
parser . setNamespaceContext ( nsContext ) ;
2007-10-25 22:42:00 +02:00
XPathExpression < string_type , string_adaptor > xpath = parser . compile ( SA : : construct_from_utf8 ( " /ns:root " ) ) ;
2007-12-19 00:03:16 +01:00
assertValuesEqual ( NODE_SET , xpath . type ( ) ) ;
2005-10-16 00:45:24 +02:00
parser . resetNamespaceContext ( ) ;
2007-10-25 22:42:00 +02:00
XPathValue < string_type , string_adaptor > result = xpath . evaluate ( document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 0 , result . asNodeSet ( ) . size ( ) ) ;
2005-10-16 00:45:24 +02:00
2007-10-25 22:42:00 +02:00
result = xpath . evaluate ( text_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 0 , result . asNodeSet ( ) . size ( ) ) ;
2005-10-16 00:45:24 +02:00
} // test8
void test9 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-25 22:42:00 +02:00
XPathExpression < string_type , string_adaptor > xpath = parser . compile ( SA : : construct_from_utf8 ( " child2 " ) ) ;
2005-10-16 00:45:24 +02:00
2007-10-25 22:42:00 +02:00
XPathValue < string_type , string_adaptor > result = xpath . evaluate ( root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
xpath = parser . compile ( SA : : construct_from_utf8 ( " ./child2 " ) ) ;
2007-10-25 22:42:00 +02:00
result = xpath . evaluate ( root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // test9
void test10 ( )
{
2007-10-22 19:42:50 +02:00
assertTrue ( root_ = = parser . evaluate ( SA : : construct_from_utf8 ( " . " ) , root_ ) . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( document_ = = parser . evaluate ( SA : : construct_from_utf8 ( " . " ) , document_ ) . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element3_ = = parser . evaluate ( SA : : construct_from_utf8 ( " . " ) , element3_ ) . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( comment_ = = parser . evaluate ( SA : : construct_from_utf8 ( " . " ) , comment_ ) . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( processingInstruction_ = = parser . evaluate ( SA : : construct_from_utf8 ( " . " ) , processingInstruction_ ) . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( text_ = = parser . evaluate ( SA : : construct_from_utf8 ( " . " ) , text_ ) . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( attr_ = = parser . evaluate ( SA : : construct_from_utf8 ( " . " ) , attr_ ) . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // test10
void test11 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-25 22:42:00 +02:00
XPathExpression < string_type , string_adaptor > xpath = parser . compile ( SA : : construct_from_utf8 ( " .. " ) ) ;
2005-10-16 00:45:24 +02:00
2007-10-25 22:42:00 +02:00
XPathValue < string_type , string_adaptor > result = xpath . evaluate ( element3_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( root_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // test11
void test12 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-25 22:42:00 +02:00
XPathExpression < string_type , string_adaptor > xpath = parser . compile ( SA : : construct_from_utf8 ( " root/*[2] " ) ) ;
XPathValue < string_type , string_adaptor > result = xpath . evaluate ( document_ ) ;
2005-10-16 00:45:24 +02:00
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
Arabica : : DOM : : Node < string_type , string_adaptor > n = result . asNodeSet ( ) [ 0 ] ;
2005-10-16 00:45:24 +02:00
assertTrue ( element2_ = = n ) ;
} // test12
void test13 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[2]/comment() " ) , document_ ) ;
2005-10-16 00:45:24 +02:00
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( comment_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // test13
void test14 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[2]/node()[3] " ) , document_ ) ;
2005-10-16 00:45:24 +02:00
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( comment_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // test14
void test15 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " root/*[spinkle] " ) , document_ ) ;
2005-10-16 00:45:24 +02:00
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // test15
void test16 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " root/*[doesnotmatch] " ) , document_ ) ;
2005-10-16 00:45:24 +02:00
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 0 , result . asNodeSet ( ) . size ( ) ) ;
2005-10-16 00:45:24 +02:00
} // test16
void test17 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[@two = '1'] " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // test17
void test18 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-16 00:45:24 +02:00
StringVariableResolver < string_type , string_adaptor > svr ;
svr . setVariable ( SA : : construct_from_utf8 ( " index " ) , SA : : construct_from_utf8 ( " 1 " ) ) ;
parser . setVariableResolver ( svr ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[@two = $index] " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
parser . resetVariableResolver ( ) ;
} // test18
void test19 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-25 22:42:00 +02:00
XPathExpression < string_type , string_adaptor > xpath = parser . compile ( SA : : construct_from_utf8 ( " root/*[position() = 2] " ) ) ;
XPathValue < string_type , string_adaptor > result = xpath . evaluate ( document_ ) ;
2005-10-16 00:45:24 +02:00
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
Arabica : : DOM : : Node < string_type , string_adaptor > n = result . asNodeSet ( ) [ 0 ] ;
2005-10-16 00:45:24 +02:00
assertTrue ( element2_ = = n ) ;
} // test19
void test20 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-25 22:42:00 +02:00
XPathExpression < string_type , string_adaptor > xpath = parser . compile ( SA : : construct_from_utf8 ( " root/*[last()] " ) ) ;
XPathValue < string_type , string_adaptor > result = xpath . evaluate ( document_ ) ;
2005-10-16 00:45:24 +02:00
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element3_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // test20
void test21 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-25 22:42:00 +02:00
XPathExpression < string_type , string_adaptor > xpath = parser . compile ( SA : : construct_from_utf8 ( " root/*[position() != last()] " ) ) ;
XPathValue < string_type , string_adaptor > result = xpath . evaluate ( document_ ) ;
2005-10-16 00:45:24 +02:00
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 2 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element1_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 1 ] ) ;
2005-10-16 00:45:24 +02:00
} // test21
void test22 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-25 22:42:00 +02:00
XPathExpression < string_type , string_adaptor > xpath = parser . compile ( SA : : construct_from_utf8 ( " root/*[position() = 2 or position() = 1] " ) ) ;
XPathValue < string_type , string_adaptor > result = xpath . evaluate ( document_ ) ;
2005-10-16 00:45:24 +02:00
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 2 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element1_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 1 ] ) ;
2005-10-16 00:45:24 +02:00
} // test22
void test23 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-25 22:42:00 +02:00
XPathExpression < string_type , string_adaptor > xpath = parser . compile ( SA : : construct_from_utf8 ( " root/*[position() = 2 and @two = '1'] " ) ) ;
XPathValue < string_type , string_adaptor > result = xpath . evaluate ( document_ ) ;
2005-10-16 00:45:24 +02:00
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // test23
void test24 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-25 22:42:00 +02:00
XPathExpression < string_type , string_adaptor > xpath = parser . compile ( SA : : construct_from_utf8 ( " root/*[last()][1] " ) ) ;
XPathValue < string_type , string_adaptor > result = xpath . evaluate ( document_ ) ;
2005-10-16 00:45:24 +02:00
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element3_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // test24
void test25 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-25 22:42:00 +02:00
XPathExpression < string_type , string_adaptor > xpath = parser . compile ( SA : : construct_from_utf8 ( " root/*[last()][2] " ) ) ;
XPathValue < string_type , string_adaptor > result = xpath . evaluate ( document_ ) ;
2005-10-16 00:45:24 +02:00
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 0 , result . asNodeSet ( ) . size ( ) ) ;
2005-10-16 00:45:24 +02:00
} // test25
void test26 ( )
2008-04-17 11:54:55 +02:00
{
using namespace Arabica : : XPath ;
XPathExpression < string_type , string_adaptor > xpath = parser . compile ( SA : : construct_from_utf8 ( " /root/child2/spinkle/ancestor::* " ) ) ;
XPathValue < string_type , string_adaptor > result = xpath . evaluate ( document_ ) ;
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 2 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( result . asNodeSet ( ) [ 0 ] = = element2_ ) ;
assertTrue ( result . asNodeSet ( ) [ 1 ] = = root_ ) ;
assertTrue ( result . asNodeSet ( ) . forward ( ) = = false ) ;
} // test26
void test26a ( )
2005-10-16 00:45:24 +02:00
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-25 22:42:00 +02:00
XPathExpression < string_type , string_adaptor > xpath = parser . compile ( SA : : construct_from_utf8 ( " /root/child2/spinkle/ancestor::node()[2] " ) ) ;
XPathValue < string_type , string_adaptor > result = xpath . evaluate ( document_ ) ;
2005-10-16 00:45:24 +02:00
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( result . asNodeSet ( ) [ 0 ] = = root_ ) ;
assertTrue ( result . asNodeSet ( ) . forward ( ) = = false ) ;
2008-04-17 11:54:55 +02:00
} // test26a
2005-10-16 00:45:24 +02:00
void test27 ( )
2008-04-17 11:54:55 +02:00
{
using namespace Arabica : : XPath ;
XPathExpression < string_type , string_adaptor > xpath = parser . compile ( SA : : construct_from_utf8 ( " /root/child2/spinkle/ancestor-or-self::* " ) ) ;
XPathValue < string_type , string_adaptor > result = xpath . evaluate ( document_ ) ;
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 3 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( result . asNodeSet ( ) [ 0 ] = = spinkle_ ) ;
assertTrue ( result . asNodeSet ( ) [ 1 ] = = element2_ ) ;
assertTrue ( result . asNodeSet ( ) [ 2 ] = = root_ ) ;
assertTrue ( result . asNodeSet ( ) . forward ( ) = = false ) ;
} // test27
void test27a ( )
2005-10-16 00:45:24 +02:00
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-25 22:42:00 +02:00
XPathExpression < string_type , string_adaptor > xpath = parser . compile ( SA : : construct_from_utf8 ( " /root/child2/spinkle/ancestor-or-self::node()[2] " ) ) ;
XPathValue < string_type , string_adaptor > result = xpath . evaluate ( document_ ) ;
2005-10-16 00:45:24 +02:00
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( result . asNodeSet ( ) [ 0 ] = = element2_ ) ;
assertTrue ( result . asNodeSet ( ) . forward ( ) = = false ) ;
2008-04-17 11:54:55 +02:00
} // test27a
2005-10-16 00:45:24 +02:00
void test28 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-25 22:42:00 +02:00
XPathExpression < string_type , string_adaptor > xpath = parser . compile ( SA : : construct_from_utf8 ( " /root/child2/spinkle/ancestor-or-self::node()[3] " ) ) ;
XPathValue < string_type , string_adaptor > result = xpath . evaluate ( document_ ) ;
2005-10-16 00:45:24 +02:00
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( result . asNodeSet ( ) [ 0 ] = = root_ ) ;
2005-10-16 00:45:24 +02:00
} // test28
void test29 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /child::root/child::*[attribute::two = '1'] " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // test29
void test30 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " / " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertTrue ( document_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // test30
void test31 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " / " ) , element1_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertTrue ( document_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // test31
void test32 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " //comment() " ) , root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertTrue ( comment_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // test32
void test33 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " //comment() " ) , root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertTrue ( comment_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( result . asNodeSet ( ) . forward ( ) = = true ) ;
2005-10-16 00:45:24 +02:00
} // test33
void test34 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " //* " ) , root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 5 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( root_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element1_ = = result . asNodeSet ( ) [ 1 ] ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 2 ] ) ;
assertTrue ( spinkle_ = = result . asNodeSet ( ) [ 3 ] ) ;
assertTrue ( element3_ = = result . asNodeSet ( ) [ 4 ] ) ;
2005-10-16 00:45:24 +02:00
} // test34
void test35 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " //* " ) , element2_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 5 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( root_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element1_ = = result . asNodeSet ( ) [ 1 ] ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 2 ] ) ;
assertTrue ( spinkle_ = = result . asNodeSet ( ) [ 3 ] ) ;
assertTrue ( element3_ = = result . asNodeSet ( ) [ 4 ] ) ;
2005-10-16 00:45:24 +02:00
} // test35
void test36 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " //*/* " ) , element2_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 4 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element1_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 1 ] ) ;
assertTrue ( spinkle_ = = result . asNodeSet ( ) [ 2 ] ) ;
assertTrue ( element3_ = = result . asNodeSet ( ) [ 3 ] ) ;
2005-10-16 00:45:24 +02:00
} // test36
void test37 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " //*/*/* " ) , element2_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( spinkle_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // test37
void test38 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " //*/*/*/* " ) , element2_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 0 , result . asNodeSet ( ) . size ( ) ) ;
2005-10-16 00:45:24 +02:00
} // test38
void test39 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /*/* " ) , element2_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 3 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element1_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 1 ] ) ;
assertTrue ( element3_ = = result . asNodeSet ( ) [ 2 ] ) ;
2005-10-16 00:45:24 +02:00
} // test39
void test40 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root//* " ) , element2_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 4 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element1_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 1 ] ) ;
assertTrue ( spinkle_ = = result . asNodeSet ( ) [ 2 ] ) ;
assertTrue ( element3_ = = result . asNodeSet ( ) [ 3 ] ) ;
2005-10-16 00:45:24 +02:00
} // test40
// see http://jira.codehaus.org/browse/JAXEN-94
void test41 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " 2+1-1+1 " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 3.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // test41
2006-06-24 00:53:07 +02:00
void test42 ( )
{
using namespace Arabica : : XPath ;
2007-09-08 01:52:30 +02:00
Arabica : : DOM : : Element < string_type , string_adaptor > f1 = chapters_ . createElement ( SA : : construct_from_utf8 ( " footer " ) ) ;
Arabica : : DOM : : Element < string_type , string_adaptor > f2 = chapters_ . createElement ( SA : : construct_from_utf8 ( " footer " ) ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > ch = parser . evaluate ( SA : : construct_from_utf8 ( " /document/chapter " ) , chapters_ ) ;
Arabica : : DOM : : Node < string_type , string_adaptor > n = ch . asNodeSet ( ) [ 0 ] ;
2006-06-24 00:53:07 +02:00
n . appendChild ( f1 ) ;
2007-10-22 19:42:50 +02:00
n = ch . asNodeSet ( ) [ 1 ] ;
2006-06-24 00:53:07 +02:00
n . appendChild ( f2 ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > footers = parser . evaluate ( SA : : construct_from_utf8 ( " //footer " ) , chapters_ ) ;
assertValuesEqual ( NODE_SET , footers . type ( ) ) ;
assertValuesEqual ( 2 , footers . asNodeSet ( ) . size ( ) ) ;
assertTrue ( f1 = = footers . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( f2 = = footers . asNodeSet ( ) [ 1 ] ) ;
2006-06-24 00:53:07 +02:00
footers = parser . evaluate ( SA : : construct_from_utf8 ( " /document/chapter/footer[1] " ) , chapters_ ) ;
2007-10-22 19:42:50 +02:00
assertValuesEqual ( NODE_SET , footers . type ( ) ) ;
assertValuesEqual ( 2 , footers . asNodeSet ( ) . size ( ) ) ;
assertTrue ( f1 = = footers . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( f2 = = footers . asNodeSet ( ) [ 1 ] ) ;
2006-06-24 00:53:07 +02:00
footers = parser . evaluate ( SA : : construct_from_utf8 ( " //footer[1] " ) , chapters_ ) ;
2007-10-22 19:42:50 +02:00
assertValuesEqual ( NODE_SET , footers . type ( ) ) ;
assertValuesEqual ( 2 , footers . asNodeSet ( ) . size ( ) ) ;
assertTrue ( f1 = = footers . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( f2 = = footers . asNodeSet ( ) [ 1 ] ) ;
2006-06-24 00:53:07 +02:00
footers = parser . evaluate ( SA : : construct_from_utf8 ( " //footer[2] " ) , chapters_ ) ;
2007-10-22 19:42:50 +02:00
assertValuesEqual ( NODE_SET , footers . type ( ) ) ;
assertValuesEqual ( 0 , footers . asNodeSet ( ) . size ( ) ) ;
2006-06-24 00:53:07 +02:00
footers = parser . evaluate_expr ( SA : : construct_from_utf8 ( " (//footer)[1] " ) , chapters_ ) ;
2007-10-22 19:42:50 +02:00
assertValuesEqual ( NODE_SET , footers . type ( ) ) ;
assertValuesEqual ( 1 , footers . asNodeSet ( ) . size ( ) ) ;
assertTrue ( f1 = = footers . asNodeSet ( ) [ 0 ] ) ;
2006-06-24 00:53:07 +02:00
footers = parser . evaluate_expr ( SA : : construct_from_utf8 ( " (//footer)[2] " ) , chapters_ ) ;
2007-10-22 19:42:50 +02:00
assertValuesEqual ( NODE_SET , footers . type ( ) ) ;
assertValuesEqual ( 1 , footers . asNodeSet ( ) . size ( ) ) ;
assertTrue ( f2 = = footers . asNodeSet ( ) [ 0 ] ) ;
2006-06-24 00:53:07 +02:00
} // test42
2005-10-16 00:45:24 +02:00
void testUnion1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[@one|data] " ) , root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 2 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element1_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 1 ] ) ;
2005-10-16 00:45:24 +02:00
} // testUnion1
void testUnion2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[buttle|tuttle] " ) , root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 0 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( result . asNodeSet ( ) . forward ( ) = = true ) ;
2005-10-16 00:45:24 +02:00
} // testUnion2
void testUnion3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[preceding-sibling::child2|@two] " ) , root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 2 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element3_ = = result . asNodeSet ( ) [ 1 ] ) ;
2005-10-16 00:45:24 +02:00
} // testUnion3
void testUnion4 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-16 00:45:24 +02:00
try {
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[@two|4] " ) , root_ ) ;
2005-10-16 00:45:24 +02:00
} // try
catch ( RuntimeException re ) {
// yay!
} // catch
} // testUnion4
void testUnion5 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[preceding-sibling::child2|@two|following-sibling::child2] " ) , root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 3 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element1_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 1 ] ) ;
assertTrue ( element3_ = = result . asNodeSet ( ) [ 2 ] ) ;
2005-10-16 00:45:24 +02:00
} // testUnion5
void testUnion6 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " /root/child2|/root/child1 " ) , root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 2 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element1_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 1 ] ) ;
2005-10-16 00:45:24 +02:00
} // testUnion6
void testUnion7 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " /root/child1|/root/child2 " ) , root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 2 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element1_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 1 ] ) ;
2005-10-16 00:45:24 +02:00
} // testUnion7
void testUnion8 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " /root/child2/@one|/root/child2|/root/child1 " ) , root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 3 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element1_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 1 ] ) ;
assertTrue ( element2_ . getAttributeNode ( SA : : construct_from_utf8 ( " one " ) ) = = result . asNodeSet ( ) [ 2 ] ) ;
2005-10-16 00:45:24 +02:00
} // testUnion8
void testUnion9 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " /root/child1/@one|/root/child2/@one|/root/child2|/root/child1 " ) , root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 4 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element1_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element1_ . getAttributeNode ( SA : : construct_from_utf8 ( " one " ) ) = = result . asNodeSet ( ) [ 1 ] ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 2 ] ) ;
assertTrue ( element2_ . getAttributeNode ( SA : : construct_from_utf8 ( " one " ) ) = = result . asNodeSet ( ) [ 3 ] ) ;
2005-10-16 00:45:24 +02:00
} // testUnion9
void testUnion10 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " /root/child3|/root/child3/preceding-sibling::* " ) , root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 3 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element1_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 1 ] ) ;
assertTrue ( element3_ = = result . asNodeSet ( ) [ 2 ] ) ;
2005-10-16 00:45:24 +02:00
} // testUnion10
void testUnion11 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-09-08 01:52:30 +02:00
Arabica : : DOM : : DocumentFragment < string_type , string_adaptor > frag = document_ . createDocumentFragment ( ) ;
2005-10-16 00:45:24 +02:00
frag . appendChild ( document_ . createElement ( SA : : construct_from_utf8 ( " foo " ) ) ) ;
NodeSetVariableResolver < string_type , string_adaptor > svr ;
2007-09-08 01:52:30 +02:00
NodeSet < string_type , string_adaptor > ns ;
2005-10-16 00:45:24 +02:00
ns . push_back ( frag ) ;
svr . setVariable ( SA : : construct_from_utf8 ( " fruit " ) , ns ) ;
parser . setVariableResolver ( svr ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " $fruit/foo|/root/child3 " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 2 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element3_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // testUnion11
void testUnion12 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-09-08 01:52:30 +02:00
Arabica : : DOM : : DocumentFragment < string_type , string_adaptor > frag = document_ . createDocumentFragment ( ) ;
Arabica : : DOM : : Node < string_type , string_adaptor > n1 = document_ . createElement ( SA : : construct_from_utf8 ( " foo " ) ) ;
Arabica : : DOM : : Node < string_type , string_adaptor > n2 = document_ . createElement ( SA : : construct_from_utf8 ( " bar " ) ) ;
2005-10-16 00:45:24 +02:00
frag . appendChild ( n1 ) ;
frag . appendChild ( n2 ) ;
NodeSetVariableResolver < string_type , string_adaptor > svr ;
2007-09-08 01:52:30 +02:00
NodeSet < string_type , string_adaptor > ns ;
2005-10-16 00:45:24 +02:00
ns . push_back ( frag ) ;
svr . setVariable ( SA : : construct_from_utf8 ( " fruit " ) , ns ) ;
parser . setVariableResolver ( svr ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " $fruit/bar|$fruit/foo " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 2 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( n1 = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( n2 = = result . asNodeSet ( ) [ 1 ] ) ;
2005-10-16 00:45:24 +02:00
} // testUnion12
void testUnion13 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-16 00:45:24 +02:00
NodeSetVariableResolver < string_type , string_adaptor > svr ;
2007-09-08 01:52:30 +02:00
NodeSet < string_type , string_adaptor > ns ;
2005-10-16 00:45:24 +02:00
ns . push_back ( document_ . createElement ( SA : : construct_from_utf8 ( " foo " ) ) ) ;
svr . setVariable ( SA : : construct_from_utf8 ( " fruit " ) , ns ) ;
parser . setVariableResolver ( svr ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " $fruit|/root/child3 " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 2 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element3_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // testUnion13
void testUnion14 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-16 00:45:24 +02:00
NodeSetVariableResolver < string_type , string_adaptor > svr ;
2007-09-08 01:52:30 +02:00
NodeSet < string_type , string_adaptor > ns ;
2005-10-16 00:45:24 +02:00
ns . push_back ( document_ . createElement ( SA : : construct_from_utf8 ( " foo " ) ) ) ;
ns . push_back ( document_ . createElement ( SA : : construct_from_utf8 ( " bar " ) ) ) ;
svr . setVariable ( SA : : construct_from_utf8 ( " fruit " ) , ns ) ;
parser . setVariableResolver ( svr ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " $fruit|/root/child3|$fruit " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 3 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element3_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // testUnion14
void testPlus1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[1+1] " ) , root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // testPlus1
void testPlus2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[1+1+1] " ) , root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element3_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // testPlus2
void testNodeSetEquality1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[@two = 1] " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // testNodeSetEquality1
void testNodeSetEquality2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[@two = true()] " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // testNodeSetEquality2
void testNodeSetEquality3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[@two != false()] " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // testNodeSetEquality3
void testNodeSetEquality4 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[@* = 1] " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertTrue ( element1_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 1 ] ) ;
2005-10-16 00:45:24 +02:00
} // testNodeSetEquality4
void testNodeSetEquality5 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[@* = '1'] " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertTrue ( element1_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 1 ] ) ;
2005-10-16 00:45:24 +02:00
} // testNodeSetEquality5
void testNodeSetEquality6 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[@* = @one] " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertTrue ( element1_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 1 ] ) ;
2005-10-16 00:45:24 +02:00
} // testNodeSetEquality6
void testNodeSetEquality7 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[@* = @two] " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // testNodeSetEquality7
void testNodeSetEquality8 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/child2[-(@two) = -1] " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // testNodeSetEquality8
void testNodeSetEquality9 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/child2[-(@two) - 1 = -2] " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // testNodeSetEquality9
void testCountFn1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[count(@*) = 4] " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // testCountFn1
void testCountFn2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[count(@*) = 1] " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element1_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // testCountFn2
void testCountFn3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[count(@*) = 999] " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 0 , result . asNodeSet ( ) . size ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testCountFn3
void testNotFn1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[@two != not(true())] " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // testNotFn1
void testNotFn2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[@two = not(false())] " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // testNotFn2
void testBooleanFn1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[boolean(@three)] " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // testBooleanFn1
void testBooleanFn2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate ( SA : : construct_from_utf8 ( " /root/*[boolean(1)] " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 3 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( element1_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 1 ] ) ;
assertTrue ( element3_ = = result . asNodeSet ( ) [ 2 ] ) ;
2005-10-16 00:45:24 +02:00
} // testBooleanFn2
void testNumberFn1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " number(true()) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 1.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testNumberFn1
void testNumberFn2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " number(false()) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 0.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testNumberFn2
void testNumberFn3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " number(1.5) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 1.5 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testNumberFn3
void testNumberFn4 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " number('1.5') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 1.5 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testNumberFn4
void testNumberFn5 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " number( \" 1.5 \" ) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 1.5 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testNumberFn5
void testNumberFn6 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " number(/root/child2/@one) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 1.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testNumberFn6
void testNumberFn7 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " number('trousers') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertTrue ( isNaN ( result . asNumber ( ) ) ) ;
2005-10-16 00:45:24 +02:00
} // testNumberFn7
2008-11-03 19:29:10 +01:00
void testNumberFn8 ( )
{
using namespace Arabica : : XPath ;
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " number('-1.5') " ) , document_ ) ;
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( - 1.5 , result . asNumber ( ) , 0.0 ) ;
} // testNumberFn8
void testNumberFn9 ( )
{
using namespace Arabica : : XPath ;
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " number('+1.5') " ) , document_ ) ;
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertTrue ( isNaN ( result . asNumber ( ) ) ) ;
} // testNumberFn9
void testNumberFn10 ( )
{
using namespace Arabica : : XPath ;
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " number('-1.5 ') " ) , document_ ) ;
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( - 1.5 , result . asNumber ( ) , 0.0 ) ;
} // testNumberFn10
void testNumberFn11 ( )
{
using namespace Arabica : : XPath ;
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " number('+1.5') " ) , document_ ) ;
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertTrue ( isNaN ( result . asNumber ( ) ) ) ;
} // testNumberFn11
void testNumberFn12 ( )
{
using namespace Arabica : : XPath ;
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " number(' -1.5 ') " ) , document_ ) ;
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( - 1.5 , result . asNumber ( ) , 0.0 ) ;
} // testNumberFn12
void testNumberFn13 ( )
{
using namespace Arabica : : XPath ;
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " number(' +1.5 ') " ) , document_ ) ;
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertTrue ( isNaN ( result . asNumber ( ) ) ) ;
} // testNumberFn13
2005-10-16 00:45:24 +02:00
void testFloorFn1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " floor(1) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 1.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testFloorFn1
void testFloorFn2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " floor(1.0) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 1.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testFloorFn2
void testFloorFn3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " floor('1.0') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 1.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testFloorFn3
void testFloorFn4 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " floor(1.1) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 1.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testFloorFn4
void testFloorFn5 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " floor(0) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 0.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testFloorFn5
void testFloorFn6 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " floor(-1) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( - 1.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testFloorFn6
void testFloorFn7 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " floor(-1.0) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( - 1.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testFloorFn7
void testFloorFn8 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " floor(-1.1) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( - 2.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testFloorFn8
void testFloorFn9 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " floor('NaN') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertTrue ( isNaN ( result . asNumber ( ) ) ) ;
2005-10-16 00:45:24 +02:00
} // testFloorFn9
void testCeilingFn1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " ceiling(1) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 1.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testCeilingFn1
void testCeilingFn2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " ceiling(1.0) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 1.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testCeilingFn2
void testCeilingFn3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " ceiling('1.0') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 1.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testCeilingFn3
void testCeilingFn4 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " ceiling(1.1) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 2.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testCeilingFn4
void testCeilingFn5 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " ceiling(0) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 0.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testCeilingFn5
void testCeilingFn6 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " ceiling(-1) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( - 1.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testCeilingFn6
void testCeilingFn7 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " ceiling(-1.0) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( - 1.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testCeilingFn7
void testCeilingFn8 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " ceiling(-1.1) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( - 1.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testCeilingFn8
void testCeilingFn9 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " ceiling('NaN') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertTrue ( isNaN ( result . asNumber ( ) ) ) ;
2005-10-16 00:45:24 +02:00
} // testCeilingFn9
void testStringFn1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " string(0) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " 0 " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testStringFn1
void testStringFn2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " string(true()) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " true " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testStringFn2
void testStringFn3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " string(false()) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " false " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testStringFn3
void testStringFn4 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " string(number('poo')) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " NaN " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testStringFn4
void testStringFn5 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " string('NaN') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " NaN " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testStringFn5
void testRoundFn1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " round(1.0) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 1.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testRoundFn1
void testRoundFn2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " round(1.1) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 1.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testRoundFn2
void testRoundFn3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " round(1.5) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 2.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testRoundFn3
void testRoundFn4 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " round(1.9) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 2.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testRoundFn4
void testRoundFn5 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " round(-1.0) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( - 1.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testRoundFn5
void testRoundFn6 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " round(-1.1) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( - 1.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testRoundFn6
void testRoundFn7 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " round(-1.5) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( - 1.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testRoundFn7
void testRoundFn8 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " round(-1.9) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( - 2.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testRoundFn8
void testRoundFn9 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " round('NaN') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertTrue ( isNaN ( result . asNumber ( ) ) ) ;
2005-10-16 00:45:24 +02:00
} // testRoundFn9
void testRoundFn10 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " round(-0.4) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( - 0.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testRoundFn10
void testSumFn1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " sum(/root) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 0.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testSumFn1
void testSumFn2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " sum(/root/child1/@one) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 1.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testSumFn2
void testSumFn3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " sum(/root//@one) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 2.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testSumFn3
void testSumFn4 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " sum(/root/child2/@*) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 4.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testSumFn4
void testConcatFn1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " concat('a', 'b') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " ab " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testConcatFn1
void testConcatFn2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " concat('a', 'b', 'c') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " abc " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testConcatFn2
void testConcatFn3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " concat('a', 'b', 'c', 'd') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " abcd " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testConcatFn3
void testConcatFn4 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " concat(/root/child2/@one, /root/child2/@two, /root/child2/@three) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " 111 " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testConcatFn4
void testConcatFn5 ( )
{
try {
parser . evaluate_expr ( SA : : construct_from_utf8 ( " concat('please explode') " ) , document_ ) ;
assertTrue ( false ) ;
}
catch ( . . . ) { }
} // testConcatFn5
void testStartsWithFn1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " starts-with('hello', 'charlie drake') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( Arabica : : XPath : : BOOL , result . type ( ) ) ;
assertValuesEqual ( false , result . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testStartsWithFn1
void testStartsWithFn2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " starts-with('hello', 'hello mother') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( Arabica : : XPath : : BOOL , result . type ( ) ) ;
assertValuesEqual ( false , result . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testStartsWithFn2
void testStartsWithFn3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " starts-with('hello mother', 'hello') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( Arabica : : XPath : : BOOL , result . type ( ) ) ;
assertValuesEqual ( true , result . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testStartsWithFn3
void testStartsWithFn4 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " starts-with('hello mother', 'hello mother') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( Arabica : : XPath : : BOOL , result . type ( ) ) ;
assertValuesEqual ( true , result . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testStartsWithFn4
void testStringLengthFn1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " string-length('') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 0.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testStringLengthFn1
void testStringLengthFn2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " string-length('ab') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 2.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testStringLengthFn2
void testStringLengthFn3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " string-length('abcd') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 4.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testStringLengthFn3
void testStringLengthFn4 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " string-length(concat('ab', 'cd')) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 4.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testStringLengthFn4
void testStringLengthFn5 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " string-length() " ) , attr_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 1.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testStringLengthFn5
void testStringLengthFn6 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " string-length() " ) , element1_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NUMBER , result . type ( ) ) ;
assertDoublesEqual ( 0.0 , result . asNumber ( ) , 0.0 ) ;
2005-10-16 00:45:24 +02:00
} // testStringLengthFn6
void testContainsFn1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " contains('hello', 'charlie drake') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( Arabica : : XPath : : BOOL , result . type ( ) ) ;
assertValuesEqual ( false , result . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testContainsFn1
void testContainsFn2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " contains('hello', 'hello mother') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( Arabica : : XPath : : BOOL , result . type ( ) ) ;
assertValuesEqual ( false , result . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testContainsFn2
void testContainsFn3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " contains('hello mother', 'hello') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( Arabica : : XPath : : BOOL , result . type ( ) ) ;
assertValuesEqual ( true , result . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testContainsFn3
void testContainsFn4 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " contains('hello mother', 'hello mother') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( Arabica : : XPath : : BOOL , result . type ( ) ) ;
assertValuesEqual ( true , result . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testContainsFn4
void testContainsFn5 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " contains('she heard a call hello mother somewhere in the distance', 'hello') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( Arabica : : XPath : : BOOL , result . type ( ) ) ;
assertValuesEqual ( true , result . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testContainsFn5
void testContainsFn6 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " contains('my dogs says hello mother', 'hello mother') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( Arabica : : XPath : : BOOL , result . type ( ) ) ;
assertValuesEqual ( true , result . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testContainsFn6
void testSubstringBeforeFn1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " substring-before('1999/04/01', '/') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " 1999 " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testSubstringBeforeFn1
void testSubstringBeforeFn2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " substring-before('1999/04/01', 'mogadon') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testSubstringBeforeFn2
void testSubstringBeforeFn3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " substring-before('1999/04/01', '/01') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " 1999/04 " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testStringBeforeFn3
void testSubstringBeforeFn4 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " substring-before('1999/04/01', '1') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testStringBeforeFn4
void testSubstringAfterFn1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " substring-after('1999/04/01', '/') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " 04/01 " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testSubstringAfterFn1
void testSubstringAfterFn2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " substring-after('1999/04/01', 'mogadon') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testSubstringAfterFn2
void testSubstringAfterFn3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " substring-after('1999/04/01', '/01') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testStringAfterFn3
void testSubstringAfterFn4 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " substring-after('1999/04/01', '19') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " 99/04/01 " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testStringAfterFn4
void testSubstringFn1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " substring('12345', 2, 3) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " 234 " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testSubstringFn1
void testSubstringFn2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " substring('12345', 2) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " 2345 " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testSubstringFn2
void testSubstringFn3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " substring('12345', 1.5, 2.6) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " 234 " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testSubstringFn3
void testSubstringFn4 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " substring('12345', 0, 3) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " 12 " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testSubstringFn4
void testSubstringFn5 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " substring('12345', 0 div 0, 3) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testSubstringFn5
void testSubstringFn6 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " substring('12345', 1, 0 div 0) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testSubstringFn6
void testSubstringFn7 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " substring('12345', -42, 1 div 0) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " 12345 " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testSubstringFn7
void testSubstringFn8 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " substring('12345', -1 div 0, 1 div 0) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testSubstringFn8
void testSubstringFn9 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " substring('12345', 1, 'NaN') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testSubstringFn9
void testSubstringFn10 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " substring('12345', NaN) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testSubstringFn10
void testSubstringFn11 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " substring('12345', NaN, NaN) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testSubstringFn11
void testNormalizeSpaceFn1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " normalize-space('12345') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " 12345 " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNormalizeSpaceFn1
void testNormalizeSpaceFn2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " normalize-space(' 12345') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " 12345 " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNormalizeSpaceFn2
void testNormalizeSpaceFn3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " normalize-space('12345 ') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " 12345 " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNormalizeSpaceFn3
void testNormalizeSpaceFn4 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " normalize-space(' 12345 ') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " 12345 " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNormalizeSpaceFn4
void testNormalizeSpaceFn5 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " normalize-space(' 12 3 45 ') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " 12 3 45 " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNormalizeSpaceFn5
void testNormalizeSpaceFn6 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " normalize-space('1 2 3 4 5') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " 1 2 3 4 5 " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNormalizeSpaceFn6
void testNormalizeSpaceFn7 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " normalize-space('1 \t 2 \r 3 \n 4 \r \n 5') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " 1 2 3 4 5 " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNormalizeSpaceFn7
void testNormalizeSpaceFn8 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " normalize-space(' \n \n \n \n \n 1 \n \n \n \n \n 2 \n \n \n \n \n 3 \n \n \n \n \n \n 4 \n \n \n \n \n \n 5 \n \n \n \n \n ') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " 1 2 3 4 5 " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNormalizeSpaceFn8
void testNormalizeSpaceFn9 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " normalize-space(' \r \n \r \n \r \n \r \n \r \n 1 \r \n \r \n \r \n \r \n \r \n 2 \r \n \r \n \r \n \r \n \r \n 3 \r \n \r \n \r \n \r \n \r \n \r \n 4 \r \n \r \n \r \n \r \n \r \n \r \n 5 \r \n \r \n \r \n \r \n \r \n ') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " 1 2 3 4 5 " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNormalizeSpaceFn9
void testTranslateFn1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " translate('bar','abc','ABC') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " BAr " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testTranslateFn1
void testTranslateFn2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " translate('--aaa--','abc-','ABC') " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " AAA " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testTranslateFn2
void testLocalNameFn1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " local-name(/root) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " root " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testLocalNameFn1
void testLocalNameFn2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " local-name(/root/child2/@one) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " one " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testLocalNameFn2
void testLocalNameFn3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " local-name(//comment()) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testLocalNameFn3
void testLocalNameFn4 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " local-name(//processing-instruction()) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " target " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testLocalNameFn4
void testLocalNameFn5 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " local-name() " ) , root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " root " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testLocalNameFn5
void testLocalNameFn6 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " local-name() " ) , attr_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " one " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testLocalNameFn6
void testLocalNameFn7 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " local-name(//comment()) " ) , comment_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testLocalNameFn7
void testLocalNameFn8 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " local-name(//processing-instruction()) " ) , processingInstruction_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " target " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testLocalNameFn8
void testLocalNameFn9 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-16 00:45:24 +02:00
root_ . appendChild ( document_ . createElementNS ( SA : : construct_from_utf8 ( " test-uri " ) ,
SA : : construct_from_utf8 ( " element4 " ) ) ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " local-name(/root/*[last()]) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " element4 " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testLocalNameFn9
void testLocalNameFn10 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-16 00:45:24 +02:00
root_ . setAttributeNS ( SA : : construct_from_utf8 ( " test-uri " ) ,
SA : : construct_from_utf8 ( " q:woot " ) ,
SA : : construct_from_utf8 ( " hello " ) ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " local-name(/root/@*) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " woot " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testLocalNameFn10
void testLocalNameFn11 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-16 00:45:24 +02:00
root_ . appendChild ( document_ . createElementNS ( SA : : construct_from_utf8 ( " test-uri " ) ,
SA : : construct_from_utf8 ( " q:noob " ) ) ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " local-name(/root/*[last()]) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " noob " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testLocalNameFn11
void testNamespaceURIFn1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " namespace-uri(/root) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNamespaceURIFn1
void testNamespaceURIFn2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " namespace-uri(/root/child2/@one) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNamespaceURIFn2
void testNamespaceURIFn3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " namespace-uri(//comment()) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNamespaceURIFn3
void testNamespaceURIFn4 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " namespace-uri(//processing-instruction()) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNamespaceURIFn4
void testNamespaceURIFn5 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " namespace-uri() " ) , root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNamespaceURIFn5
void testNamespaceURIFn6 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " namespace-uri() " ) , attr_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNamespaceURIFn6
void testNamespaceURIFn7 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " namespace-uri(//comment()) " ) , comment_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNamespaceURIFn7
void testNamespaceURIFn8 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " namespace-uri(//processing-instruction()) " ) , processingInstruction_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNamespaceURIFn8
void testNamespaceURIFn9 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-16 00:45:24 +02:00
root_ . appendChild ( document_ . createElementNS ( SA : : construct_from_utf8 ( " test-uri " ) ,
SA : : construct_from_utf8 ( " element4 " ) ) ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " namespace-uri(/root/*[last()]) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " test-uri " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNamespaceURIFn9
void testNamespaceURIFn10 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-16 00:45:24 +02:00
root_ . setAttributeNS ( SA : : construct_from_utf8 ( " test-uri " ) ,
SA : : construct_from_utf8 ( " q:woot " ) ,
SA : : construct_from_utf8 ( " hello " ) ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " namespace-uri(/root/@*) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " test-uri " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNamespaceURIFn10
void testNamespaceURIFn11 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-16 00:45:24 +02:00
root_ . appendChild ( document_ . createElementNS ( SA : : construct_from_utf8 ( " test-uri " ) , SA : : construct_from_utf8 ( " q:noob " ) ) ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " namespace-uri(/root/*[last()]) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " test-uri " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNamespaceURIFn1
void testNameFn1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " name(/root) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " root " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNameFn1
void testNameFn2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " name(/root/child2/@one) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " one " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNameFn2
void testNameFn3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " name(//comment()) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNameFn3
void testNameFn4 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " name(//processing-instruction()) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " target " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNameFn4
void testNameFn5 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " name() " ) , root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " root " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNameFn5
void testNameFn6 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " name() " ) , attr_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " one " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNameFn6
void testNameFn7 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " name(//comment()) " ) , comment_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNameFn7
void testNameFn8 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " name(//processing-instruction()) " ) , processingInstruction_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " target " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNameFn8
void testNameFn9 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-16 00:45:24 +02:00
root_ . appendChild ( document_ . createElementNS ( SA : : construct_from_utf8 ( " test-uri " ) ,
SA : : construct_from_utf8 ( " element4 " ) ) ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " name(/root/*[last()]) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " element4 " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNameFn9
void testNameFn10 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-16 00:45:24 +02:00
root_ . setAttributeNS ( SA : : construct_from_utf8 ( " test-uri " ) ,
SA : : construct_from_utf8 ( " q:woot " ) ,
SA : : construct_from_utf8 ( " hello " ) ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " name(/root/@*) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " q:woot " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNameFn10
void testNameFn11 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-16 00:45:24 +02:00
root_ . appendChild ( document_ . createElementNS ( SA : : construct_from_utf8 ( " test-uri " ) ,
SA : : construct_from_utf8 ( " q:noob " ) ) ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " name(/root/*[last()]) " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " q:noob " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testNameFn11
void testDocumentOrder1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " string(/document/*) " ) , chapters_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " one " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testDocumentOrder1
void testDocumentOrder2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " string(/document/*[last()]) " ) , chapters_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " five " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testDocumentOrder2
void testDocumentOrder3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " string(/document/chapter[5]/preceding-sibling::*[1]) " ) , chapters_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " four " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testDocumentOrder3
void testDocumentOrder4 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " string(/document/chapter[5]/preceding-sibling::*[last()]) " ) , chapters_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " one " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testDocumentOrder4
void testDocumentOrder5 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " string(/document/chapter[5]/preceding-sibling::*) " ) , chapters_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " one " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testDocumentOrder5
void testLessThan1 ( )
{
2007-10-22 19:42:50 +02:00
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " true() < true() " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " true() < false() " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " false() < false() " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " false() < true() " ) , chapters_ ) . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testLessThan1
void testLessThan2 ( )
{
2007-10-22 19:42:50 +02:00
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 1 < 1 " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 3.0 < 2.0 " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 2.0 < 3.0 " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " -1 < 1 " ) , chapters_ ) . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testLessThan2
void testLessThan3 ( )
{
2007-10-22 19:42:50 +02:00
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " '1' < '1' " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " '3.0' < '2.0' " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " '2.0' < '3.0' " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " '-1' < '1' " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " -1 < 'ooop' " ) , chapters_ ) . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testLessThan3
void testLessThan4 ( )
{
2007-10-22 19:42:50 +02:00
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number < 0 " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number[2] < 0 " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number < 2 " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number < 12 " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 0 < /doc/number " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 0 < /doc/number[2] " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 1 < /doc/number " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 7 < /doc/number " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 12 < /doc/number " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number[position()<5] < /doc/number[position()>5] " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number[position()<=5] < /doc/number[position()>4] " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number[position()>5] < /doc/number[position()<5] " ) , numbers_ ) . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testLessThan4
void testLessThanEquals1 ( )
{
2007-10-22 19:42:50 +02:00
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " true() <= true() " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " true() <= false() " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " false() <= false() " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " false() <= true() " ) , chapters_ ) . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testLessThanEquals1
void testLessThanEquals2 ( )
{
2007-10-22 19:42:50 +02:00
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 1 <= 1 " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 3.0 <= 2.0 " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 2.0 <= 3.0 " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " -1 <= 1 " ) , chapters_ ) . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testLessThanEquals2
void testLessThanEquals3 ( )
{
2007-10-22 19:42:50 +02:00
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " '1' <= '1' " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " '3.0' <= '2.0' " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " '2.0' <= '3.0' " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " '-1' <= '1' " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " -1 <= 'ooop' " ) , chapters_ ) . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testLessThanEquals3
void testLessThanEquals4 ( )
{
2007-10-22 19:42:50 +02:00
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number <= 0 " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number[2] <= 0 " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number <= 2 " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number <= 12 " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 0 <= /doc/number " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 0 <= /doc/number[2] " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 1 <= /doc/number " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 7 <= /doc/number " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 12 <= /doc/number " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number[position()<5] <= /doc/number[position()>5] " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number[position()<=5] <= /doc/number[position()>4] " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number[position()>5] <= /doc/number[position()<5] " ) , numbers_ ) . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testLessThanEquals4
void testGreaterThan1 ( )
{
2007-10-22 19:42:50 +02:00
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " true() > true() " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " true() > false() " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " false() > false() " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " false() > true() " ) , chapters_ ) . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testGreaterThan1
void testGreaterThan2 ( )
{
2007-10-22 19:42:50 +02:00
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 1 > 1 " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 3.0 > 2.0 " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 2.0 > 3.0 " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " -1 > 1 " ) , chapters_ ) . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testGreaterThan2
void testGreaterThan3 ( )
{
2007-10-22 19:42:50 +02:00
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " '1' > '1' " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " '3.0' > '2.0' " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " '2.0' > '3.0' " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " '-1' > '1' " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " -1 > 'ooop' " ) , chapters_ ) . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testGreaterThan3
void testGreaterThan4 ( )
{
2007-10-22 19:42:50 +02:00
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 3 > 2 > 1 " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " (3>2)>1 " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 3 > (2 > 1) " ) , chapters_ ) . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testGreaterThan4
void testGreaterThan5 ( )
{
2007-10-22 19:42:50 +02:00
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number > 0 " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number[2] > 0 " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number > 1 " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number > 12 " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 0 > /doc/number " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 0 > /doc/number[2] " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 1 > /doc/number " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 7 > /doc/number " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 12 > /doc/number " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number[position()<5] > /doc/number[position()>5] " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number[position()<=5] > /doc/number[position()>4] " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number[position()>5] > /doc/number[position()<5] " ) , numbers_ ) . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testGreaterThan4
void testGreaterThanEquals1 ( )
{
2007-10-22 19:42:50 +02:00
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " true() >= true() " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " true() >= false() " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " false() >= false() " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " false() >= true() " ) , chapters_ ) . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testGreaterThanEquals1
void testGreaterThanEquals2 ( )
{
2007-10-22 19:42:50 +02:00
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 1 >= 1 " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 3.0 >= 2.0 " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 2.0 >= 3.0 " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " -1 >= 1 " ) , chapters_ ) . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testGreaterThanEquals2
void testGreaterThanEquals3 ( )
{
2007-10-22 19:42:50 +02:00
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " '1' >= '1' " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " '3.0' >= '2.0' " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " '2.0' >= '3.0' " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " '-1' >= '1' " ) , chapters_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " -1 >= 'ooop' " ) , chapters_ ) . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testGreaterThanEquals3
void testGreaterThanEquals4 ( )
{
2007-10-22 19:42:50 +02:00
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number >= 0 " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number[2] >= 0 " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number >= 1 " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number >= 12 " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 0 >= /doc/number " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 0 >= /doc/number[2] " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 1 >= /doc/number " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 7 >= /doc/number " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " 12 >= /doc/number " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( false , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number[position()<5] >= /doc/number[position()>5] " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number[position()<=5] >= /doc/number[position()>4] " ) , numbers_ ) . asBool ( ) ) ;
assertValuesEqual ( true , parser . evaluate_expr ( SA : : construct_from_utf8 ( " /doc/number[position()>5] >= /doc/number[position()<5] " ) , numbers_ ) . asBool ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testGreaterThanEquals4
void testNodeSetVars1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-16 00:45:24 +02:00
NodeSetVariableResolver < string_type , string_adaptor > svr ;
2007-09-08 01:52:30 +02:00
NodeSet < string_type , string_adaptor > ns ;
2005-10-16 00:45:24 +02:00
ns . push_back ( element1_ ) ;
ns . push_back ( element2_ ) ;
ns . push_back ( element3_ ) ;
svr . setVariable ( SA : : construct_from_utf8 ( " fruit " ) , ns ) ;
parser . setVariableResolver ( svr ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " $fruit " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertTrue ( element1_ = = result . asNodeSet ( ) [ 0 ] ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 1 ] ) ;
assertTrue ( element3_ = = result . asNodeSet ( ) [ 2 ] ) ;
2005-10-16 00:45:24 +02:00
} // testNodeSetVars1
void testNodeSetVars2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-16 00:45:24 +02:00
NodeSetVariableResolver < string_type , string_adaptor > svr ;
2007-09-08 01:52:30 +02:00
NodeSet < string_type , string_adaptor > ns ;
2005-10-16 00:45:24 +02:00
ns . push_back ( element1_ ) ;
ns . push_back ( element2_ ) ;
ns . push_back ( element3_ ) ;
svr . setVariable ( SA : : construct_from_utf8 ( " fruit " ) , ns ) ;
parser . setVariableResolver ( svr ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " $fruit/spinkle " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertTrue ( spinkle_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // testNodeSetVars2
void testNodeSetVars3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-16 00:45:24 +02:00
NodeSetVariableResolver < string_type , string_adaptor > svr ;
2007-09-08 01:52:30 +02:00
NodeSet < string_type , string_adaptor > ns ;
2005-10-16 00:45:24 +02:00
ns . push_back ( element1_ ) ;
ns . push_back ( element2_ ) ;
ns . push_back ( element3_ ) ;
svr . setVariable ( SA : : construct_from_utf8 ( " fruit " ) , ns ) ;
parser . setVariableResolver ( svr ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " $fruit[2]/* " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertTrue ( spinkle_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // testNodeSetVars3
void testNodeSetVars4 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-16 00:45:24 +02:00
NodeSetVariableResolver < string_type , string_adaptor > svr ;
2007-09-08 01:52:30 +02:00
NodeSet < string_type , string_adaptor > ns ;
2005-10-16 00:45:24 +02:00
ns . push_back ( element1_ ) ;
ns . push_back ( element2_ ) ;
ns . push_back ( element3_ ) ;
svr . setVariable ( SA : : construct_from_utf8 ( " fruit " ) , ns ) ;
parser . setVariableResolver ( svr ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " $fruit[true()][2] " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // testNodeSetVars4
void testNodeSetVars5 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-16 00:45:24 +02:00
NodeSetVariableResolver < string_type , string_adaptor > svr ;
2007-09-08 01:52:30 +02:00
NodeSet < string_type , string_adaptor > ns ;
2005-10-16 00:45:24 +02:00
ns . push_back ( element1_ ) ;
ns . push_back ( element2_ ) ;
ns . push_back ( element3_ ) ;
svr . setVariable ( SA : : construct_from_utf8 ( " fruit " ) , ns ) ;
parser . setVariableResolver ( svr ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " $fruit[@two] " ) , document_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertTrue ( element2_ = = result . asNodeSet ( ) [ 0 ] ) ;
2005-10-16 00:45:24 +02:00
} // testNodeSetVars5
void namespaceAxisTest1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " namespace::* " ) , root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 1 , result . asNodeSet ( ) . size ( ) ) ;
2005-10-16 00:45:24 +02:00
} // namespaceAxisTest1()
void namespaceAxisTest2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-16 00:45:24 +02:00
root_ . setAttributeNS ( SA : : construct_from_utf8 ( " http://www.w3.org/2000/xmlns/ " ) ,
SA : : construct_from_utf8 ( " xmlns:poop " ) ,
SA : : construct_from_utf8 ( " urn:test " ) ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " namespace::* " ) , root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 2 , result . asNodeSet ( ) . size ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " xml " ) = = result . asNodeSet ( ) [ 0 ] . getLocalName ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " poop " ) = = result . asNodeSet ( ) [ 1 ] . getLocalName ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " urn:test " ) = = result . asNodeSet ( ) [ 1 ] . getNodeValue ( ) ) ;
2005-10-16 00:45:24 +02:00
} // namespaceAxisTest2
void namespaceAxisTest3 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-16 00:45:24 +02:00
root_ . setAttributeNS ( SA : : construct_from_utf8 ( " http://www.w3.org/2000/xmlns/ " ) ,
SA : : construct_from_utf8 ( " xmlns:poop " ) ,
SA : : construct_from_utf8 ( " urn:test " ) ) ;
element2_ . setAttributeNS ( SA : : construct_from_utf8 ( " http://www.w3.org/2000/xmlns/ " ) ,
SA : : construct_from_utf8 ( " xmlns:test " ) ,
SA : : construct_from_utf8 ( " urn:another-test " ) ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " namespace::* " ) , element2_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( NODE_SET , result . type ( ) ) ;
assertValuesEqual ( 3 , result . asNodeSet ( ) . size ( ) ) ;
2005-10-16 00:45:24 +02:00
} // namespaceAxisTest3
void testFunctionResolver1 ( )
{
try {
parser . compile_expr ( SA : : construct_from_utf8 ( " test-function() " ) ) ;
assertTrue ( false ) ;
}
catch ( . . . ) { }
} // testFunctionResolver1
void testFunctionResolver2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2005-10-16 00:45:24 +02:00
TestFunctionResolver < string_type , string_adaptor > tfr ;
parser . setFunctionResolver ( tfr ) ;
2007-10-22 19:42:50 +02:00
XPathValue < string_type , string_adaptor > result = parser . evaluate_expr ( SA : : construct_from_utf8 ( " test-function() " ) , root_ ) ;
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 23:59:24 +02:00
assertValuesEqual ( STRING , result . type ( ) ) ;
assertTrue ( SA : : construct_from_utf8 ( " test-root " ) = = result . asString ( ) ) ;
2005-10-16 00:45:24 +02:00
} // testFunctionResolver2
void testSort1 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-09-08 01:52:30 +02:00
NodeSet < string_type , string_adaptor > ns ;
2005-10-16 00:45:24 +02:00
ns . push_back ( element1_ ) ;
ns . push_back ( element2_ ) ;
ns . push_back ( element3_ ) ;
ns . to_document_order ( ) ;
assertTrue ( element1_ = = ns [ 0 ] ) ;
assertTrue ( element2_ = = ns [ 1 ] ) ;
assertTrue ( element3_ = = ns [ 2 ] ) ;
} // testSort1
void testSort2 ( )
{
2005-10-17 13:48:44 +02:00
using namespace Arabica : : XPath ;
2007-09-08 01:52:30 +02:00
NodeSet < string_type , string_adaptor > ns ;
2005-10-16 00:45:24 +02:00
ns . push_back ( element3_ ) ;
ns . push_back ( element2_ ) ;
ns . push_back ( element1_ ) ;
ns . to_document_order ( ) ;
assertTrue ( element1_ = = ns [ 0 ] ) ;
assertTrue ( element2_ = = ns [ 1 ] ) ;
assertTrue ( element3_ = = ns [ 2 ] ) ;
} // testSort2
} ; // class ExecuteTest
template < class string_type , class string_adaptor >
TestSuite * ExecuteTest_suite ( )
{
TestSuite * suiteOfTests = new TestSuite ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test1 " , & ExecuteTest < string_type , string_adaptor > : : test1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test2 " , & ExecuteTest < string_type , string_adaptor > : : test2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test3 " , & ExecuteTest < string_type , string_adaptor > : : test3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test4 " , & ExecuteTest < string_type , string_adaptor > : : test4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test5 " , & ExecuteTest < string_type , string_adaptor > : : test5 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test6 " , & ExecuteTest < string_type , string_adaptor > : : test6 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test7 " , & ExecuteTest < string_type , string_adaptor > : : test7 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test8 " , & ExecuteTest < string_type , string_adaptor > : : test8 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test9 " , & ExecuteTest < string_type , string_adaptor > : : test9 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test10 " , & ExecuteTest < string_type , string_adaptor > : : test10 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test11 " , & ExecuteTest < string_type , string_adaptor > : : test11 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test12 " , & ExecuteTest < string_type , string_adaptor > : : test12 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test13 " , & ExecuteTest < string_type , string_adaptor > : : test13 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test14 " , & ExecuteTest < string_type , string_adaptor > : : test14 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test15 " , & ExecuteTest < string_type , string_adaptor > : : test15 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test16 " , & ExecuteTest < string_type , string_adaptor > : : test16 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test17 " , & ExecuteTest < string_type , string_adaptor > : : test17 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test18 " , & ExecuteTest < string_type , string_adaptor > : : test18 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test19 " , & ExecuteTest < string_type , string_adaptor > : : test19 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test20 " , & ExecuteTest < string_type , string_adaptor > : : test20 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test21 " , & ExecuteTest < string_type , string_adaptor > : : test21 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test22 " , & ExecuteTest < string_type , string_adaptor > : : test22 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test23 " , & ExecuteTest < string_type , string_adaptor > : : test23 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test24 " , & ExecuteTest < string_type , string_adaptor > : : test24 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test25 " , & ExecuteTest < string_type , string_adaptor > : : test25 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test26 " , & ExecuteTest < string_type , string_adaptor > : : test26 ) ) ;
2008-04-17 11:54:55 +02:00
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test26a " , & ExecuteTest < string_type , string_adaptor > : : test26a ) ) ;
2005-10-16 00:45:24 +02:00
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test27 " , & ExecuteTest < string_type , string_adaptor > : : test27 ) ) ;
2008-04-17 11:54:55 +02:00
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test27a " , & ExecuteTest < string_type , string_adaptor > : : test27a ) ) ;
2005-10-16 00:45:24 +02:00
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test28 " , & ExecuteTest < string_type , string_adaptor > : : test28 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test29 " , & ExecuteTest < string_type , string_adaptor > : : test29 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test30 " , & ExecuteTest < string_type , string_adaptor > : : test30 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test31 " , & ExecuteTest < string_type , string_adaptor > : : test31 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test32 " , & ExecuteTest < string_type , string_adaptor > : : test32 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test33 " , & ExecuteTest < string_type , string_adaptor > : : test33 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test34 " , & ExecuteTest < string_type , string_adaptor > : : test34 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test35 " , & ExecuteTest < string_type , string_adaptor > : : test35 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test36 " , & ExecuteTest < string_type , string_adaptor > : : test36 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test37 " , & ExecuteTest < string_type , string_adaptor > : : test37 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test38 " , & ExecuteTest < string_type , string_adaptor > : : test38 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test39 " , & ExecuteTest < string_type , string_adaptor > : : test39 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test40 " , & ExecuteTest < string_type , string_adaptor > : : test40 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test41 " , & ExecuteTest < string_type , string_adaptor > : : test41 ) ) ;
2006-06-24 00:53:07 +02:00
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " test42 " , & ExecuteTest < string_type , string_adaptor > : : test42 ) ) ;
2005-10-16 00:45:24 +02:00
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testUnion1 " , & ExecuteTest < string_type , string_adaptor > : : testUnion1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testUnion2 " , & ExecuteTest < string_type , string_adaptor > : : testUnion2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testUnion3 " , & ExecuteTest < string_type , string_adaptor > : : testUnion3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testUnion4 " , & ExecuteTest < string_type , string_adaptor > : : testUnion4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testUnion5 " , & ExecuteTest < string_type , string_adaptor > : : testUnion5 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testUnion6 " , & ExecuteTest < string_type , string_adaptor > : : testUnion6 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testUnion7 " , & ExecuteTest < string_type , string_adaptor > : : testUnion7 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testUnion8 " , & ExecuteTest < string_type , string_adaptor > : : testUnion8 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testUnion9 " , & ExecuteTest < string_type , string_adaptor > : : testUnion9 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testUnion10 " , & ExecuteTest < string_type , string_adaptor > : : testUnion10 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testUnion11 " , & ExecuteTest < string_type , string_adaptor > : : testUnion11 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testUnion12 " , & ExecuteTest < string_type , string_adaptor > : : testUnion12 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testUnion13 " , & ExecuteTest < string_type , string_adaptor > : : testUnion13 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testUnion14 " , & ExecuteTest < string_type , string_adaptor > : : testUnion14 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testPlus1 " , & ExecuteTest < string_type , string_adaptor > : : testPlus1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testPlus2 " , & ExecuteTest < string_type , string_adaptor > : : testPlus2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNodeSetEquality1 " , & ExecuteTest < string_type , string_adaptor > : : testNodeSetEquality1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNodeSetEquality2 " , & ExecuteTest < string_type , string_adaptor > : : testNodeSetEquality2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNodeSetEquality3 " , & ExecuteTest < string_type , string_adaptor > : : testNodeSetEquality3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNodeSetEquality4 " , & ExecuteTest < string_type , string_adaptor > : : testNodeSetEquality4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNodeSetEquality5 " , & ExecuteTest < string_type , string_adaptor > : : testNodeSetEquality5 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNodeSetEquality6 " , & ExecuteTest < string_type , string_adaptor > : : testNodeSetEquality6 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNodeSetEquality7 " , & ExecuteTest < string_type , string_adaptor > : : testNodeSetEquality7 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNodeSetEquality8 " , & ExecuteTest < string_type , string_adaptor > : : testNodeSetEquality8 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNodeSetEquality9 " , & ExecuteTest < string_type , string_adaptor > : : testNodeSetEquality9 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testCountFn1 " , & ExecuteTest < string_type , string_adaptor > : : testCountFn1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testCountFn2 " , & ExecuteTest < string_type , string_adaptor > : : testCountFn2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testCountFn3 " , & ExecuteTest < string_type , string_adaptor > : : testCountFn3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNotFn1 " , & ExecuteTest < string_type , string_adaptor > : : testNotFn1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNotFn2 " , & ExecuteTest < string_type , string_adaptor > : : testNotFn2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testBooleanFn1 " , & ExecuteTest < string_type , string_adaptor > : : testBooleanFn1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testBooleanFn2 " , & ExecuteTest < string_type , string_adaptor > : : testBooleanFn2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNumberFn1 " , & ExecuteTest < string_type , string_adaptor > : : testNumberFn1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNumberFn2 " , & ExecuteTest < string_type , string_adaptor > : : testNumberFn2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNumberFn3 " , & ExecuteTest < string_type , string_adaptor > : : testNumberFn3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNumberFn4 " , & ExecuteTest < string_type , string_adaptor > : : testNumberFn4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNumberFn5 " , & ExecuteTest < string_type , string_adaptor > : : testNumberFn5 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNumberFn6 " , & ExecuteTest < string_type , string_adaptor > : : testNumberFn6 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNumberFn7 " , & ExecuteTest < string_type , string_adaptor > : : testNumberFn7 ) ) ;
2008-11-03 19:29:10 +01:00
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNumberFn8 " , & ExecuteTest < string_type , string_adaptor > : : testNumberFn8 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNumberFn9 " , & ExecuteTest < string_type , string_adaptor > : : testNumberFn9 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNumberFn10 " , & ExecuteTest < string_type , string_adaptor > : : testNumberFn10 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNumberFn11 " , & ExecuteTest < string_type , string_adaptor > : : testNumberFn11 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNumberFn12 " , & ExecuteTest < string_type , string_adaptor > : : testNumberFn12 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNumberFn13 " , & ExecuteTest < string_type , string_adaptor > : : testNumberFn13 ) ) ;
2005-10-16 00:45:24 +02:00
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testFloorFn1 " , & ExecuteTest < string_type , string_adaptor > : : testFloorFn1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testFloorFn2 " , & ExecuteTest < string_type , string_adaptor > : : testFloorFn2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testFloorFn3 " , & ExecuteTest < string_type , string_adaptor > : : testFloorFn3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testFloorFn4 " , & ExecuteTest < string_type , string_adaptor > : : testFloorFn4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testFloorFn5 " , & ExecuteTest < string_type , string_adaptor > : : testFloorFn5 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testFloorFn6 " , & ExecuteTest < string_type , string_adaptor > : : testFloorFn6 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testFloorFn7 " , & ExecuteTest < string_type , string_adaptor > : : testFloorFn7 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testFloorFn8 " , & ExecuteTest < string_type , string_adaptor > : : testFloorFn8 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testFloorFn9 " , & ExecuteTest < string_type , string_adaptor > : : testFloorFn9 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testCeilingFn1 " , & ExecuteTest < string_type , string_adaptor > : : testCeilingFn1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testCeilingFn2 " , & ExecuteTest < string_type , string_adaptor > : : testCeilingFn2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testCeilingFn3 " , & ExecuteTest < string_type , string_adaptor > : : testCeilingFn3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testCeilingFn4 " , & ExecuteTest < string_type , string_adaptor > : : testCeilingFn4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testCeilingFn5 " , & ExecuteTest < string_type , string_adaptor > : : testCeilingFn5 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testCeilingFn6 " , & ExecuteTest < string_type , string_adaptor > : : testCeilingFn6 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testCeilingFn7 " , & ExecuteTest < string_type , string_adaptor > : : testCeilingFn7 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testCeilingFn8 " , & ExecuteTest < string_type , string_adaptor > : : testCeilingFn8 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testCeilingFn9 " , & ExecuteTest < string_type , string_adaptor > : : testCeilingFn9 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testStringFn1 " , & ExecuteTest < string_type , string_adaptor > : : testStringFn1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testStringFn2 " , & ExecuteTest < string_type , string_adaptor > : : testStringFn2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testStringFn3 " , & ExecuteTest < string_type , string_adaptor > : : testStringFn3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testStringFn4 " , & ExecuteTest < string_type , string_adaptor > : : testStringFn4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testStringFn5 " , & ExecuteTest < string_type , string_adaptor > : : testStringFn5 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testRoundFn1 " , & ExecuteTest < string_type , string_adaptor > : : testRoundFn1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testRoundFn2 " , & ExecuteTest < string_type , string_adaptor > : : testRoundFn2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testRoundFn3 " , & ExecuteTest < string_type , string_adaptor > : : testRoundFn3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testRoundFn4 " , & ExecuteTest < string_type , string_adaptor > : : testRoundFn4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testRoundFn5 " , & ExecuteTest < string_type , string_adaptor > : : testRoundFn5 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testRoundFn6 " , & ExecuteTest < string_type , string_adaptor > : : testRoundFn6 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testRoundFn7 " , & ExecuteTest < string_type , string_adaptor > : : testRoundFn7 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testRoundFn8 " , & ExecuteTest < string_type , string_adaptor > : : testRoundFn8 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testRoundFn9 " , & ExecuteTest < string_type , string_adaptor > : : testRoundFn9 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testRoundFn10 " , & ExecuteTest < string_type , string_adaptor > : : testRoundFn10 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSumFn1 " , & ExecuteTest < string_type , string_adaptor > : : testSumFn1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSumFn2 " , & ExecuteTest < string_type , string_adaptor > : : testSumFn2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSumFn3 " , & ExecuteTest < string_type , string_adaptor > : : testSumFn3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSumFn4 " , & ExecuteTest < string_type , string_adaptor > : : testSumFn4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testConcatFn1 " , & ExecuteTest < string_type , string_adaptor > : : testConcatFn1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testConcatFn2 " , & ExecuteTest < string_type , string_adaptor > : : testConcatFn2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testConcatFn3 " , & ExecuteTest < string_type , string_adaptor > : : testConcatFn3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testConcatFn4 " , & ExecuteTest < string_type , string_adaptor > : : testConcatFn4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testConcatFn5 " , & ExecuteTest < string_type , string_adaptor > : : testConcatFn5 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testStartsWithFn1 " , & ExecuteTest < string_type , string_adaptor > : : testStartsWithFn1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testStartsWithFn2 " , & ExecuteTest < string_type , string_adaptor > : : testStartsWithFn2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testStartsWithFn3 " , & ExecuteTest < string_type , string_adaptor > : : testStartsWithFn3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testStartsWithFn4 " , & ExecuteTest < string_type , string_adaptor > : : testStartsWithFn4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testStringLengthFn1 " , & ExecuteTest < string_type , string_adaptor > : : testStringLengthFn1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testStringLengthFn2 " , & ExecuteTest < string_type , string_adaptor > : : testStringLengthFn2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testStringLengthFn3 " , & ExecuteTest < string_type , string_adaptor > : : testStringLengthFn3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testStringLengthFn4 " , & ExecuteTest < string_type , string_adaptor > : : testStringLengthFn4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testStringLengthFn5 " , & ExecuteTest < string_type , string_adaptor > : : testStringLengthFn5 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testStringLengthFn6 " , & ExecuteTest < string_type , string_adaptor > : : testStringLengthFn6 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testContainsFn1 " , & ExecuteTest < string_type , string_adaptor > : : testContainsFn1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testContainsFn2 " , & ExecuteTest < string_type , string_adaptor > : : testContainsFn2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testContainsFn3 " , & ExecuteTest < string_type , string_adaptor > : : testContainsFn3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testContainsFn4 " , & ExecuteTest < string_type , string_adaptor > : : testContainsFn4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testContainsFn5 " , & ExecuteTest < string_type , string_adaptor > : : testContainsFn5 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testContainsFn6 " , & ExecuteTest < string_type , string_adaptor > : : testContainsFn6 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSubstringBeforeFn1 " , & ExecuteTest < string_type , string_adaptor > : : testSubstringBeforeFn1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSubstringBeforeFn2 " , & ExecuteTest < string_type , string_adaptor > : : testSubstringBeforeFn2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSubstringBeforeFn3 " , & ExecuteTest < string_type , string_adaptor > : : testSubstringBeforeFn3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSubstringBeforeFn4 " , & ExecuteTest < string_type , string_adaptor > : : testSubstringBeforeFn4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSubstringAfterFn1 " , & ExecuteTest < string_type , string_adaptor > : : testSubstringAfterFn1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSubstringAfterFn2 " , & ExecuteTest < string_type , string_adaptor > : : testSubstringAfterFn2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSubstringAfterFn3 " , & ExecuteTest < string_type , string_adaptor > : : testSubstringAfterFn3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSubstringAfterFn4 " , & ExecuteTest < string_type , string_adaptor > : : testSubstringAfterFn4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSubstringFn1 " , & ExecuteTest < string_type , string_adaptor > : : testSubstringFn1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSubstringFn2 " , & ExecuteTest < string_type , string_adaptor > : : testSubstringFn2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSubstringFn3 " , & ExecuteTest < string_type , string_adaptor > : : testSubstringFn3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSubstringFn4 " , & ExecuteTest < string_type , string_adaptor > : : testSubstringFn4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSubstringFn5 " , & ExecuteTest < string_type , string_adaptor > : : testSubstringFn5 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSubstringFn6 " , & ExecuteTest < string_type , string_adaptor > : : testSubstringFn6 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSubstringFn7 " , & ExecuteTest < string_type , string_adaptor > : : testSubstringFn7 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSubstringFn8 " , & ExecuteTest < string_type , string_adaptor > : : testSubstringFn8 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSubstringFn9 " , & ExecuteTest < string_type , string_adaptor > : : testSubstringFn9 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSubstringFn10 " , & ExecuteTest < string_type , string_adaptor > : : testSubstringFn10 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSubstringFn11 " , & ExecuteTest < string_type , string_adaptor > : : testSubstringFn11 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNormalizeSpaceFn1 " , & ExecuteTest < string_type , string_adaptor > : : testNormalizeSpaceFn1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNormalizeSpaceFn2 " , & ExecuteTest < string_type , string_adaptor > : : testNormalizeSpaceFn2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNormalizeSpaceFn3 " , & ExecuteTest < string_type , string_adaptor > : : testNormalizeSpaceFn3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNormalizeSpaceFn4 " , & ExecuteTest < string_type , string_adaptor > : : testNormalizeSpaceFn4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNormalizeSpaceFn5 " , & ExecuteTest < string_type , string_adaptor > : : testNormalizeSpaceFn5 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNormalizeSpaceFn6 " , & ExecuteTest < string_type , string_adaptor > : : testNormalizeSpaceFn6 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNormalizeSpaceFn7 " , & ExecuteTest < string_type , string_adaptor > : : testNormalizeSpaceFn7 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNormalizeSpaceFn8 " , & ExecuteTest < string_type , string_adaptor > : : testNormalizeSpaceFn8 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNormalizeSpaceFn9 " , & ExecuteTest < string_type , string_adaptor > : : testNormalizeSpaceFn9 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testTranslateFn1 " , & ExecuteTest < string_type , string_adaptor > : : testTranslateFn1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testTranslateFn2 " , & ExecuteTest < string_type , string_adaptor > : : testTranslateFn2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testLocalNameFn1 " , & ExecuteTest < string_type , string_adaptor > : : testLocalNameFn1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testLocalNameFn2 " , & ExecuteTest < string_type , string_adaptor > : : testLocalNameFn2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testLocalNameFn3 " , & ExecuteTest < string_type , string_adaptor > : : testLocalNameFn3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testLocalNameFn4 " , & ExecuteTest < string_type , string_adaptor > : : testLocalNameFn4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testLocalNameFn5 " , & ExecuteTest < string_type , string_adaptor > : : testLocalNameFn5 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testLocalNameFn6 " , & ExecuteTest < string_type , string_adaptor > : : testLocalNameFn6 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testLocalNameFn7 " , & ExecuteTest < string_type , string_adaptor > : : testLocalNameFn7 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testLocalNameFn8 " , & ExecuteTest < string_type , string_adaptor > : : testLocalNameFn8 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testLocalNameFn9 " , & ExecuteTest < string_type , string_adaptor > : : testLocalNameFn9 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testLocalNameFn10 " , & ExecuteTest < string_type , string_adaptor > : : testLocalNameFn10 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testLocalNameFn11 " , & ExecuteTest < string_type , string_adaptor > : : testLocalNameFn11 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNamespaceURIFn1 " , & ExecuteTest < string_type , string_adaptor > : : testNamespaceURIFn1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNamespaceURIFn2 " , & ExecuteTest < string_type , string_adaptor > : : testNamespaceURIFn2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNamespaceURIFn3 " , & ExecuteTest < string_type , string_adaptor > : : testNamespaceURIFn3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNamespaceURIFn4 " , & ExecuteTest < string_type , string_adaptor > : : testNamespaceURIFn4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNamespaceURIFn5 " , & ExecuteTest < string_type , string_adaptor > : : testNamespaceURIFn5 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNamespaceURIFn6 " , & ExecuteTest < string_type , string_adaptor > : : testNamespaceURIFn6 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNamespaceURIFn7 " , & ExecuteTest < string_type , string_adaptor > : : testNamespaceURIFn7 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNamespaceURIFn8 " , & ExecuteTest < string_type , string_adaptor > : : testNamespaceURIFn8 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNamespaceURIFn9 " , & ExecuteTest < string_type , string_adaptor > : : testNamespaceURIFn9 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNamespaceURIFn10 " , & ExecuteTest < string_type , string_adaptor > : : testNamespaceURIFn10 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNamespaceURIFn11 " , & ExecuteTest < string_type , string_adaptor > : : testNamespaceURIFn11 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNameFn1 " , & ExecuteTest < string_type , string_adaptor > : : testNameFn1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNameFn2 " , & ExecuteTest < string_type , string_adaptor > : : testNameFn2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNameFn3 " , & ExecuteTest < string_type , string_adaptor > : : testNameFn3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNameFn4 " , & ExecuteTest < string_type , string_adaptor > : : testNameFn4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNameFn5 " , & ExecuteTest < string_type , string_adaptor > : : testNameFn5 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNameFn6 " , & ExecuteTest < string_type , string_adaptor > : : testNameFn6 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNameFn7 " , & ExecuteTest < string_type , string_adaptor > : : testNameFn7 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNameFn8 " , & ExecuteTest < string_type , string_adaptor > : : testNameFn8 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNameFn9 " , & ExecuteTest < string_type , string_adaptor > : : testNameFn9 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNameFn10 " , & ExecuteTest < string_type , string_adaptor > : : testNameFn10 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNameFn11 " , & ExecuteTest < string_type , string_adaptor > : : testNameFn11 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testDocumentOrder1 " , & ExecuteTest < string_type , string_adaptor > : : testDocumentOrder1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testDocumentOrder2 " , & ExecuteTest < string_type , string_adaptor > : : testDocumentOrder2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testDocumentOrder3 " , & ExecuteTest < string_type , string_adaptor > : : testDocumentOrder3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testDocumentOrder4 " , & ExecuteTest < string_type , string_adaptor > : : testDocumentOrder4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testDocumentOrder5 " , & ExecuteTest < string_type , string_adaptor > : : testDocumentOrder5 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testLessThan1 " , & ExecuteTest < string_type , string_adaptor > : : testLessThan1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testLessThan2 " , & ExecuteTest < string_type , string_adaptor > : : testLessThan2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testLessThan3 " , & ExecuteTest < string_type , string_adaptor > : : testLessThan3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testLessThan4 " , & ExecuteTest < string_type , string_adaptor > : : testLessThan4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testLessThanEquals1 " , & ExecuteTest < string_type , string_adaptor > : : testLessThanEquals1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testLessThanEquals2 " , & ExecuteTest < string_type , string_adaptor > : : testLessThanEquals2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testLessThanEquals3 " , & ExecuteTest < string_type , string_adaptor > : : testLessThanEquals3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testLessThanEquals4 " , & ExecuteTest < string_type , string_adaptor > : : testLessThanEquals4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testGreaterThan1 " , & ExecuteTest < string_type , string_adaptor > : : testGreaterThan1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testGreaterThan2 " , & ExecuteTest < string_type , string_adaptor > : : testGreaterThan2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testGreaterThan3 " , & ExecuteTest < string_type , string_adaptor > : : testGreaterThan3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testGreaterThan4 " , & ExecuteTest < string_type , string_adaptor > : : testGreaterThan4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testGreaterThan5 " , & ExecuteTest < string_type , string_adaptor > : : testGreaterThan5 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testGreaterThanEquals1 " , & ExecuteTest < string_type , string_adaptor > : : testGreaterThanEquals1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testGreaterThanEquals2 " , & ExecuteTest < string_type , string_adaptor > : : testGreaterThanEquals2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testGreaterThanEquals3 " , & ExecuteTest < string_type , string_adaptor > : : testGreaterThanEquals3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testGreaterThanEquals4 " , & ExecuteTest < string_type , string_adaptor > : : testGreaterThanEquals4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNodeSetVars1 " , & ExecuteTest < string_type , string_adaptor > : : testNodeSetVars1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNodeSetVars2 " , & ExecuteTest < string_type , string_adaptor > : : testNodeSetVars2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNodeSetVars3 " , & ExecuteTest < string_type , string_adaptor > : : testNodeSetVars3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNodeSetVars4 " , & ExecuteTest < string_type , string_adaptor > : : testNodeSetVars4 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testNodeSetVars5 " , & ExecuteTest < string_type , string_adaptor > : : testNodeSetVars5 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " namespaceAxisTest1 " , & ExecuteTest < string_type , string_adaptor > : : namespaceAxisTest1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " namespaceAxisTest2 " , & ExecuteTest < string_type , string_adaptor > : : namespaceAxisTest2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " namespaceAxisTest3 " , & ExecuteTest < string_type , string_adaptor > : : namespaceAxisTest3 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testFunctionResolver1 " , & ExecuteTest < string_type , string_adaptor > : : testFunctionResolver1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testFunctionResolver2 " , & ExecuteTest < string_type , string_adaptor > : : testFunctionResolver2 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSort1 " , & ExecuteTest < string_type , string_adaptor > : : testSort1 ) ) ;
suiteOfTests - > addTest ( new TestCaller < ExecuteTest < string_type , string_adaptor > > ( " testSort2 " , & ExecuteTest < string_type , string_adaptor > : : testSort2 ) ) ;
return suiteOfTests ;
} // ExecuteTest_suite
2005-08-04 23:23:48 +02:00
# endif