Subject: Re: [Boost-bugs] [Boost C++ Libraries] #11600: boost property_tree exponential newline growth
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2016-02-11 09:51:54
#11600: boost property_tree exponential newline growth
------------------------------------------+---------------------------
Reporter: Timo Strunk <Timo.Strunk@â¦> | Owner: cornedbee
Type: Bugs | Status: closed
Milestone: To Be Determined | Component: property_tree
Version: Boost 1.59.0 | Severity: Problem
Resolution: invalid | Keywords:
------------------------------------------+---------------------------
Comment (by Timo Strunk <timo.strunk@â¦>):
Without my code you currently cannot round-trip the following XML using
Property Tree:
<XML>
<Text>AB CD</Text>
</XML>
There are two protected spaces in between AB and CD. I need those two
spaces.
Using the previous boost 1.59 code you end up with:
<?xml version="1.0" encoding="utf-8"?>
<XML>
<Text>AB CD</Text>
</XML>
This is good, because the text is not broken, but if the XML is rewritten
several million times you end up with a GB of ' ' (or actual newlines
in case of pull request #18).
Using trim_whitespace you end up with:
<?xml version="1.0" encoding="utf-8"?>
<XML>
<Text>AB CD</Text>
</XML>
which makes everything look nice, but the double whitespace in the middle
is gone.
The problem here is that property_tree::trim_whitespace is converted to
rapidxml::normalize_whitespace. The trim_whitespace option of rapidxml is
not exposed.
My change (incorrectly, you are right) trims whitespace, even if
trim_whitespace is not enabled.
Therefore my suggestion would be: I send a third Pull request in which I
integrate a new option
boost::property_tree::xml_parser::trim_but_dont_normalize_whitespace,
which enables rapidxml::trim_whitespace but not
rapidxml::normalize_whitespace.
Would this be acceptable for you?
-- Ticket URL: <https://svn.boost.org/trac/boost/ticket/11600#comment:5> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.
This archive was generated by hypermail 2.1.7 : 2017-02-16 18:50:19 UTC