Hi Georg, Georg Baum wrote:
Even if you ignore the InsetInclude problem for a moment, there will be more performance problems caused by the current FileName implementation. The reason is simple: FileName once was a lightweight wrapper around a string, and it is still used in many places like that. Of course you could introduce a cache every time you encounter a performance problem, but why is that better than separating FileName::operator==() and FileName::equivalent()? Those two operations serve two different purposes and should not be mixed IMHO.
I agree that we need two comparison methods. I am not sure though that the operator==() should be lighter one. I 'd rather look at the all the cases where it is used and replace them on a case by case with equivalent() or isSimilarTo() as I suggested earlier. I fear that we will introduce some bugs if we make the light comparison the default.
Abdel.
