-1

Seeing the documentation of XmlDocument::parse(Ch*) in RapidXml, i'm left wondering about the character buffer being 'non const'. I'm not sure how this is going to work in general when the buffer needs to grow by any such modifications of the parser. Will the library do the growing? if i am asking it to parse, it should just parse right? otherwise it ought to be called ParseAndPossibleModifyButLetMeKnowIfYouHadToRegrowTheBufferInWhichCaseHeyCheckThisFlagAndCopyThisPointer or something like that.

Am i missing something? I want to understand this library because i want something that is simple to use to open and append / edit xml files on the fly from C++, but if there are simpler / better alternatives do not hesitate to make such suggestions as answers!!

Nicol Bolas
  • 378,677
  • 53
  • 635
  • 829
lurscher
  • 23,085
  • 26
  • 113
  • 178
  • As for alternatives, [we have a question for that](http://stackoverflow.com/questions/9387610/what-xml-parser-should-i-use-in-c). – Nicol Bolas Feb 23 '12 at 04:49

2 Answers2

1

Rapidxml never needs to grow the buffer. By a lucky coincidence UTF8-encoded XML always has enough space around strings to insert terminating null characters and expand built-in character entities in place.

So the only modification made will be to the contents of the buffer, never its size.

kaalus
  • 3,728
  • 3
  • 24
  • 34
1

RapidXML tries its best to be an in-place parser. When it can't, it will allocate memory (linked to the lifetime of the xml_document<>), but only when necessary. It's fairly rare for a string to have to actually grow due to XML reading.

It will modify the contents of the string (unless you set the non-modifying flag), and its objects will keep references to that string around. So you need to make sure that the buffer survives for long enough. But other than that, there's not much to worry about.

Nicol Bolas
  • 378,677
  • 53
  • 635
  • 829
  • what does it mean only when necessary? a buffer grow might actually allocate to a new address, so the old pointer might be invalidated; how does rapidXml gives me the pointer to the new buffer when that happens? – lurscher Feb 23 '12 at 17:38
  • @lurscher: The buffer *can't* grow. However, RapidXML's string conversions might, in some cases, want to make the string bigger than it's location in place. Therefore, it allocates *new* memory internally to store that string, since that string can no longer be modified in place. The new memory is associated with the `xml_document<>`. – Nicol Bolas Feb 23 '12 at 18:02
  • oh! ok, so if a append some xml nodes at the end of the document for example, the xml_document::print() might return a new buffer? is there a way to make it print directly to a file? – lurscher Feb 23 '12 at 18:06
  • @lurscher: The documentation shows very clearly how to print to an output iterator. Which can be an `ostreambuf_iterator` constructed from an `ofstream`. – Nicol Bolas Feb 23 '12 at 18:13