XmlElement hasTagName ignores case


#1

As the title says the hasTagName method of XmlElement ignores the case, even when not in debug mode, equalsIgnoreCase is also dramatically slower then a case senstive compare.

#ifdef JUCE_DEBUG // if debugging, check that the case is actually the same, because // valid xml is case-sensitive, and although this lets it pass, it's // better not to.. if (tagName.equalsIgnoreCase (tagNameWanted)) { jassert (tagName == tagNameWanted); return true; } else { return false; } #else return tagName.equalsIgnoreCase (tagNameWanted); #endif [/code]


#2

Is that really causing performance issues for you?


#3

Well, we are using a lot Xml parsing, and i had the idea that compareIgnoreCase is much slower.
It is slower, twice, but luckily is still very fast (tested in OSX).
But because hasTagName is called quite a few times in our application i though i could gain some performance.
Anyway, you probably not have to worry about performance but still the compareIgnoreCase should be replaced by a normal compare or not?


#4

I made it insensitive because it’s very, very unlikely you’d ever need a case-sensitive comparison to correctly parse your document. It’d be a very strange schema if you did! And people are often very lax about case when writing it by hand, so it’ll help rescue a lot of situations where the input data is sloppily written.

You don’t need to call hasTagName though - why not just get the tag name and do your own comparison?


#5

I could do my own comparison but of course i already used hasTagName all over my project and was just wondering wether the compareIgnoreCase was used. Your comments in the method sort of implied that you only should use compareIgnoreCase in debug mode. I understand your point and this way it makes it less error prone.

In my experience though most people actually don’t write XML manually, in our case all XML is generated by our own application to store settings and read them again. But there is no issue anymore as the compareIgnoreCase is not as slow as i though (hoped :wink: ), otherwise i could do a search replace.