This time it is a terrible implementation of a even worse API to do pseudo-XML. I spare you the details - only this: If you want to use XML use it correctly, and if you can’t: Don’t try using standard-conformant XML-libraries like Xerces.
Why doing such a thing at all? Actually this is more a comparision between C++ and Java design problems. On the Java side you can also get into problems like that, for example when you want to wrap XML-handling so that a J# implementation can use its beloved MSXML.
The C++ code was a bright example what happens to your code if you think you don’t have time for refactoring. Originally it had been something to access a proprietary text-format. Then some bright mind seemed to have the idea that use of XML is imperative. He handed this over to some Windows-programmer that cranked out an equivalent interface using MSXML. Eventually the got got ported to UNIX and Xerces as a parser, as cheese topping Unicode support had been added. Remember: No Refactoring!
Something had to be done. But actually it got more complicated as I thought. I specified some getters:
Stop, my colleage said: “Writing
gives much faster code”. I could relate to his argument, but I simply don’t like out-parameters, our C++ architect was with me, but my colleague insisted on benchmarking, and the benchmark show an overhead of about 15%…
I felt that I had to give in. Well, he was outnumbered and showed that he would trash the implementation, if he was forced to continue implementing this API. The remedy was that we settled for:
operator int() const;
operator string() const;
Of course as slow as the get, but a bit more obscure - list-access we get in groovy-style via operator(int) - so the developer is happy, he traded performance for something else.
So we will waste some time at runtime…
In Java we wouldn’t have a had a choice. And this is gooood! Really. No irony attached.
I implemented something similar in Java in about an afternoon and it was all straightforward. Two minor bugs which got corrected in seconds.
The whole discussion above took actually two days with three engineers involved. That is a waste of time. As this all came up shortly before I wanted to leave for vacation, I got sometimes a bit impatient by stating that this all wouldn’t even be a topic in a Java implementation. The response from the C++ folk was: “Well, C++ programmers have to be smarter to avoid stupid code”.
Well, I think using a more development efficient language is at least as smart because it avoids wasting time on stupid little problems.
A final word for the performance obsessed: The code in question will be used to access a remote interface, on both ends there will be heavy database-access. No profiler will ever list one of the functions mentioned above.