[libxml++] sax parser: preserving attributes order

[Murray Cumming Comneon com]

> >If libxml++ does not preserve the order, and libxml does, then I'm 
> >willing to consider this a bug.
> >
> >  
> >
> 
> It looks like SaxParser does not preserve the order of attributes in 
> start_element callback, since it uses an AttributeMap which 
> is defined 
> as std::map<std::string, std::string>.
> Anywhere else it should be ok since we use directly libxml2 API.
> 
> The solution would be to use a std::vector< std::pair<std::string, 
> std::string> > instead of a std::map<std::string, 
> std::string>.

I guess we have no choice. I don't think that the attribute order needs to
be preserved by a specification-compliant parser, but if libxml does it then
people will expect it of libxml++.

> Loops on the container would be almost 
> unchanged, but looking for an 
> attribute by it's name would be a little more change :
> attributes.find('name')
> could becomes something like :
> 
> struct FirstIs {
>     std::string const & s_;
>     FirstIs(std::string const & s): s_(s) {}
>     bool operator()(std::pair<std::string, std::string> const & v) { 
> return v.first == s_; }
> }
> 
> find_if( attribute.begin(), attribute.end(), FirstIs('name'))
> 
> We could eventually provide a helper to make it easy.
> I think the overhead wouldn't be sensible unless we have dozens of 
> attributes

I think it's OK if we provide that FirstIs predicate. Maybe we should call
it SaxParser::FirstAttributeHasName.

Murray Cumming
www.murrayc.com
murrayc usa net