On 7/11/07, Phil Endecott <spam_from_boost_dev@chezphil.org> wrote:
Felipe Magno de Almeida wrote:
[snipped]
But you lose locality
Not with literal strings, e.g.
element("<author>" "<firstname>Joe</firstname>" "<surname>Random</surname>" "</author>");
But no syntax checking whatsoever.
and sometimes performance.
[snip]
Well if you're generating an XML fragment with an <author> tag, it should mean something to you. If you prefer, try author_element or element("author").
then
a.push_back() a.push_back() ai.push_back()
I hope that push_back() is familiar to all C++ users.
Have you noted that the first two are a, and the firth is ai ? It is from your own code.
It doesnt strike to you that this code is very error-prone?
The main types of error are creating an element and then forgetting to add it to its parent, and stuff like that. Yes, this happens. But it's fairly easy to debug.
I believe that it is not only very recurring, but there are a lot of other errors that compiles and fails. Debugging xml generation is a PITA when the xml logic is quite complex. Some may never be tested. [snip]
What is the advantage of not resorting to operator overloading? What exactly anybody wins not using it?
The advantage of not using operator overloading is that it is easier to see what is going on; the code is less magical. We all know what "OBJECT.METHOD(PARAMETER)" does, but what does X [ Y , Z ] do? It looks like 2D array indexing to me. The overloading of operator[] and operator, that David presented would be justified if it made a substantial saving in LOC and increase in clarity compared to what you could achieve using conventional syntax. But my feeling (and I'm happy to see counter-examples) is that the syntax that I presented gets close to the LOC and clarity (see below), and that in some cases you can use inline string literals for maximum clarity.
With fear of sounding too hasty, IMO, boost is way beyond this abstraction prejudice. [snip]
Phil.
-- Felipe Magno de Almeida