I am using VS 2017 15.9.5, Boost 1.69.0.

Code that compiles and works correctly using VS 2015 now causes a compile error with VS 2017.
Unable to find resolution or workaround.

The error is this :

boost\property_tree\detail\ptree_implementation.hpp(500): error C2440: '': cannot convert from '_Ty1' to 'boost::property_tree::basic_ptree<std::wstring,std::wstring,std::less>::assoc_iterator'
with
[
_Ty1=boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::null_augment_policy,boost::multi_index::detail::index_node_base<std::pair<const std::wstring,boost::property_tree::basic_ptree<std::wstring,std::wstring,std::lessstd::wstring>>,std::allocator<std::pair<const std::wstring,boost::property_tree::basic_ptree<std::wstring,std::wstring,std::lessstd::wstring>>>>>>
]
and
[
Key=std::wstring
]
boost\property_tree\detail\ptree_implementation.hpp(500): note: No constructor could take the source type, or constructor overload resolution was ambiguous (compiling source file BPropertyTree.cpp)

With this code

#include <boost/property_tree/ptree.hpp>

int main()
{
    boost::property_tree::ptree ptr;
    ptr.put("name", "toto");
    return 0;
}

I get the error boost-1_82\boost/core/swap.hpp(81,5): fatal error C1202: recursive type or function dependency context too complex for Visual 2022.

There are a bunch of small fixes that haven't been released to master in ages.
Most of them are about removing annoying warnings.

Could those get released please?

While parsing an empty attribute, function parse_node_attributes() correctly creates a new attribute with value of length 0 but it sets the pointer into the buffer instead of to nullptr.
This does not harm in usual circumstances. But in case of cloning, it does. Then allocate_attribute() in clone_node() sets the value as value(val, internal::measure(val)) with length to the end of the buffer which is wrong.

Could you please check?

Similar to this issue but less ambitious, I would like to suggest to provide minimum support for char16_t and char32_t to read XML, basically an extension of a previous BOM support issue. For example, the following code snippet does currently not compile:

#include <boost/property_tree/ptree.hpp>
#include <boost/property_tree/xml_parser.hpp>

int main()
{
  boost::property_tree::basic_ptree<std::u16string, std::u16string> pt;
  std::string filename("utf16.xml"); 
  read_xml(filename, pt);
}

producing the following compile error:

1>c:\projects\thirdparty\boost_1_68_0\boost\property_tree\detail\rapidxml.hpp(1374): error C2664: 'void boost::property_tree::detail::rapidxml::xml_document<Ch>::parse_bom<3072>(wchar_t *&)': cannot convert argument 1 from 'Ch *' to 'char *&'
1>        with
1>        [
1>            Ch=Ch
1>        ]
1>c:\projects\thirdparty\boost_1_68_0\boost\property_tree\detail\xml_parser_read_rapidxml.hpp(116): note: see reference to function template instantiation 'void boost::property_tree::detail::rapidxml::xml_document<Ch>::parse<3072>(Ch *)' being compiled
1>        with
1>        [
1>            Ch=Ch
1>        ]
1>c:\projects\thirdparty\boost_1_68_0\boost\property_tree\detail\xml_parser_read_rapidxml.hpp(116): note: see reference to function template instantiation 'void boost::property_tree::detail::rapidxml::xml_document<Ch>::parse<3072>(Ch *)' being compiled
1>        with
1>        [
1>            Ch=Ch
1>        ]
1>c:\projects\thirdparty\boost_1_68_0\boost\property_tree\xml_parser.hpp(85): note: see reference to function template instantiation 'void boost::property_tree::xml_parser::read_xml_internal<Ptree>(std::basic_istream<char16_t,std::char_traits<char16_t>> &,Ptree &,int,const std::string &)' being compiled
1>        with
1>        [
1>            Ptree=boost::property_tree::basic_ptree<std::u16string,std::u16string,std::less<std::u16string>>
1>        ]
[...]
1>Done building project "bdal-playground.vcxproj" -- FAILED.

First inspection indicates that there are only missing specializations of the parse_bom member template for types char16_t and char_32_t.

I'm willing to make a corresponding pull request, but opened this issue first to get feedback on this idea.

My use case is to inject xml snippets into comment blocks as templates for users to modify and un-comment as desired. Because the comment marker tag only accepts a comment string (subnodes not supported), I generate the xml snippets separately and write them to a stringstream then inject the string into the xml comment tag. Each time a snippet xml is generated the <?xml version="1.0" encoding="utf-8"?> processing instruction is automatically inserted.

I want to be able to suppress emitting this instruction. I suggest that if the encoding attribute in xml_writer_settings is explicitly set to an "empty" string then automatic insertion of the version/encoding instruction be skipped.

So, will there be support for the yaml parser just like json parser. The requirement I am using json parser for reading purpose by reading json file and after reading I think it interally converts it into ptree. So, is it possible to do same with yaml

In test/CMakeLists.txt line 12, a Regex pattern is being constructed from a variable that holds a system-dependent file path. If that path contains characters that are special in a Regex pattern, a failure results.

Example: A path containing plus signs '+'

Bottom line: Don't construct a Regex pattern from unknown text.

json_parser/detail/parser.hpp includes <boost/bind.hpp> which causes a deprecation warning with boost 1.73.0.

..\boost\boost/bind.hpp(41): note: The practice of declaring the Bind placeholders (_1, _2, ...)
in the global namespace is deprecated. Please use <boost/bind/bind.hpp> + using
namespace boost::placeholders, or define BOOST_BIND_GLOBAL_PLACEHOLDERS to
retain the current behavior.

This could for example be resolved by using #include <boost/bind/bind.hpp> and adding a using namespace boost::placeholders in the methods that use boost::bind with _1, etc.

We are in the process of making B2 build changes to all of the B2 build files
to support "modular" consumption of the Boost Libraries by users. See this list
post for some details: https://lists.boost.org/Archives/boost/2024/01/255704.php

The process requires making a variety of changes to make each Boost library
independent of the super-project structure. But the changes do not remove the
super-project structure or the comprehensive Boost release. The changes make
solely make it possible, optionally, for users, like package manages, to easily
consume libraries individually.

Generally the changes include:

• Adding a libroot/build.jam.
• Porting any functionality from libroot/jamfile to libroot/build.jam.
• Moving boost-install declaration from libroot/build/jamfile is applicable.
• Adjusting other B2 build files in the library, like test/jamfile, as needed.
• Possible changes to C++ source files to remove includes relative to the
  super-project boostroot location.

Some examples of such changes:

• boostorg/interval#38
• boostorg/ublas#189
• boostorg/local_function#10
• boostorg/preprocessor#57
• boostorg/callable_traits#194
• boostorg/compatibility#4
• boostorg/hof#228
• boostorg/preprocessor#56

We are asking how you would like us to handle the changes. We would prefer if
you allow the owners of the Boost.org GitHub project to make changes to B2
build files, as needed, to accomplish the changes. But understand
that you may want to manage the proposed changes yourself.

We previously sent emails to all known maintainers to fill out a form with their
preference. We are contacting you in this issue as we have not gotten a response
to that email. You can see the ongoing responses for that form and the responses
to these issues here https://github.com/users/grafikrobot/projects/1/views/6

We are now asking if you can reply directly to this issue to indicate your
preference of handling the changes. Please supply a response to this question
and close the issue (so that we can verify you are a maintainer).

How would you like the build changes to be processed?

1. Pull request, reviewed and merged by a BOOSTORG OWNER.
2. Pull request, reviewed and merged by YOU.
3. Other. (please specify details in the reply)

Also please indicate any special instructions you want us to consider. Or other
information you want us to be aware of.

Thanks you, René

Consider following example

#include <iostream>
#include <sstream>
#include <boost/property_tree/ptree.hpp>
#include <boost/property_tree/json_parser.hpp>

int main()
{
	using namespace boost::property_tree;
	
	std::stringstream ss;
	ss << "{\"someRandomNode\":false}";

	ptree json;
	read_json(ss, json);

	const auto &node = json.get_child("otherNode", ptree{});
	std::cout << node.size() << " " << (node.begin() == node.end()) << std::endl;

	for (const auto &[k, v] : node)
		std::cout << "Why did i get here?" << std::endl;

	return 0;
}

Output:

0 0
Why did i get here?
Segmentation fault

Obviously get_child returns broken reference leading to undefined behaviour.
Tested with g++ (Gentoo 8.3.0-r1 p1.1) 8.3.0 and boost 1.70.0.

“ · ” is garbled after write_json

If there is interest I would like to contribute the following:

• change m_children to be a boost/std any instead of a void* - We can the default the move and copy constructors assignment operators, and pretty sure the destructor. It at least works on the version I have been playing with.

• implement rvalue references (issue:42 ) - Its mostly pretty straightforward overloads, except for where we are deducing Type, in these cases we need to add an enable_if<is_rvalue_reference<Type&&> ,Type> or similar to prevent the universal forwarding references (Type&&) from being too greedy.

• pass path by value - a copy is made immediately in most cases anyway

• add a string_view constructor to string_path

• use other boost config helper macros to do things like add const or constexpr and noexcept where appropriate

• use macros to use std library versions of type traits, any, optional, string_view as appropriate.

• create a boost::lexical_cast based translator instead of stringstream. maybe make a macro flag to switch between them.

• find other opportunities to use string_view

• then in the far off future, a YAML parser.

• [[unlikely]] i may update the unit testing. i think its set up to use the minimal implementation of test which is deprecated and took a lot of fiddling with

If there is any real interest, I can work on the pull requests for review.

typeid() is used in some exception macros in detail/ptree_implementation.hpp

There are currently two signatures available:

• read_json(std::string const&, ...)
• read_json(std::basic_istream<...> const&, ...)

In case of Windows and a file name with non-standard characters I cannot rely on read_json(std::string const&, ...).

I therefore use this workaround:
boost::filesystem::path const filename(L"Some foreign language file name");
boost::filesystem::ifstream ifs(filename);
read_json(ifs, ...);

In case of an error, the exception thrown does not contain the filename and I have to construct a message of my own.

I would like to request these additions:

• read_json(boost::filesystem::path const&, ...)
• read_json(std::wstring const&, ...)

Warning when Boost 1.72 is built with GCC 7.5 with -Wsuggest-override added to cxxflags:

./boost/property_tree/detail/rapidxml.hpp:61:29: warning: ‘virtual const char* boost::property_tree::detail::rapidxml::parse_error::what() const’ can be marked override [-Wsuggest-override]

BOOST_OVERRIDE was introduced in boostorg/config@ffe4e0f.

Both write_xml(...) and write_json(...) overloads accepting const std::string &filename look the following way:

    {
        std::basic_ofstream<typename Ptree::key_type::value_type>
            stream(filename.c_str());
...
        write_{xml, json}_internal(stream, pt, filename, settings);
    }

where write_{xml, json}_internal(...) writes data to the stream and in the end checks that no errors happened:

        if (!stream)
            BOOST_PROPERTY_TREE_THROW(xml_parser_error("write error", filename, 0));

The problem is that the actual write on disk (or at least part of it, depending on property_tree size) will be performed in stream's dtor, when internal buffers will be flushed. Any error possibly happening there is silently ignored.

Minimal reproducing example is this:

    pt::ptree tree;
    tree.put("foo", "bar");
    tree.put("bar", "baz");
    try {
        errno = 0;
        pt::write_xml("dev_dir/ptee.xml", tree, std::locale(),
                pt::xml_parser::xml_writer_settings<pt::ptree::key_type>(' ', 2));
    } catch (pt::ptree_error & e) {
        const int err = errno;
        std::cerr << "write failed with " << e.what() << ", errno: " << err << std::endl;
        return 2;
    }
    std::cout << "success" << std::endl;

If you execute this code on a disk partition where there is no space left, you'll see "success" in the stdout, but on disk there'll be empty file without any data.

Explicitly doing stream.flush() and checking for errors afterwards should help.

Hi,

I've noticed some strange behaviour when reading out values into a boost::container::string.
Where a value begins with leading spaces it is not present when retrieved with get().
This behaves the same on 1.68.0 and 1.71.0.

For the program below, I expect the output to be the same for both std::string and boost::container::string. However std::string correctly preserves the leading space (" value") where as boost:container::string does not ("value").

Output

### boost::container::string ###
{
    "key": "       value"
}

"value"

### std::string ###
{
    "key": "       value"
}

"       value"

Program

#include <boost/container/string.hpp>
#include <boost/property_tree/json_parser.hpp>
#include <boost/property_tree/ptree.hpp>
#include <iostream>

#define LEADING_WS "       value"

void print_ptree(boost::property_tree::ptree const & pt)
{
    std::stringstream stream;
    boost::property_tree::write_json(stream, pt);
    std::cout << stream.str() << std::endl;
}

void boost_container_string(void)
{
    boost::container::string const value(LEADING_WS);

    boost::property_tree::ptree pt;
    pt.put<boost::container::string>("key", value);

    boost::container::string read_back = pt.get<boost::container::string>("key");

    std::cout << "### boost::container::string ###" << std::endl;
    print_ptree(pt);
    std::cout << "\"" << read_back << "\"" << std::endl;
    std::cout << std::endl;
}

void std_string(void)
{
    std::string const value(LEADING_WS);

    boost::property_tree::ptree pt;
    pt.put<std::string>("key", value);

    std::string read_back = pt.get<std::string>("key");

    std::cout << "### std::string ###" << std::endl;
    print_ptree(pt);
    std::cout << "\"" << read_back << "\"" << std::endl;
    std::cout << std::endl;
}

int main()
{
    boost_container_string();
    std_string();

    return 0;
}

Hi,
I want to parse below JSON data and get the "netconf-clients" available. Can someone help me on how to do it.

('{"o-ran-dhcp:dhcp": {"interfaces": [{"interface": "mPlaneVlan295", "dhcpv4": ' '{"client-id": "53148/473966A.101/L1174115125", "dhcp-server-identifier": ''"192.168.100.1", "interface-mtu": 1500, "domain-name": "nokia.com", ' '"domain-name-servers": ["192.168.1.1", "192.168.1.2"], "default-gateways": ''["192.168.100.1"], **"netconf-clients": [{"client": "192.168.100.1", ''"optional-port": 4334}, {"client": "xyz.com", "optional-port": 4334}], '** '"ca-ra-servers": [{"servers": "192.168.100.1", "port-number": 99, ' '"ca-ra-path": "var/opt/z", "subject-name": "radio", "protocol": "HTTPS"}], ' '"segw": [{"gateways": "1.2.3.4"}], "local-ip": "192.168.100.3"}, "dhcpv6": ''{}}], "m-plane-dhcp": {"private-enterprise-num": 53148, "vendor-class-data": ' '"o-ran/No125"}}}')

Br,
Neeraj

This XML:

<?xml version="1.0" encoding="UTF-8"?>
<tag>
  Text1
  <tag1>a</tag1>
  Text2
  <tag2>b</tag2>
  Text3
</tag>

parse result has all texts (Text1, Text2, Text3) combined into a single string that is available as the output of the data() function:

data="
  Text1
  
  Text2
  
  Text3
"

and boost leaves no way to determine that <tag1> and <tag2> are in the middle of this text. tag1 and tag2 are available as separate keys, but this loses information about their location.

A larger practical example:
The line <param len="4">const <ptype>GLfloat</ptype> *<name>v</name></param> in https://raw.githubusercontent.com/KhronosGroup/OpenGL-Registry/master/xml/gl.xml can't be parsed using property_tree/xml_parser because the <ptype> tag is between two text elements.

Here's the second clang-modules issue I found (with this and #99 addressed, I could build ptree_serialization as a submodule).

It refers to some archive/basic_archive details.

'''
-- a/1.77.0/src/boost_1_77_0/boost/property_tree/ptree_serialization.hpp
+++ b/1.77.0/src/boost_1_77_0/boost/property_tree/ptree_serialization.hpp
@@ -10,8 +10,8 @@
#ifndef BOOST_PROPERTY_TREE_PTREE_SERIALIZATION_HPP_INCLUDED
#define BOOST_PROPERTY_TREE_PTREE_SERIALIZATION_HPP_INCLUDED

+#include <boost/archive/basic_archive.hpp>
#include <boost/property_tree/ptree.hpp>

#include <boost/serialization/nvp.hpp>
#include <boost/serialization/collections_save_imp.hpp>
#include <boost/serialization/detail/stack_constructor.hpp>
'''

Good morning,

I was working on a project, I would like to use basic_ptree with strings of non standard type (see T1.cpp attached toy example).

While read_json works smootly, write_json fails (see compiler output T1.error.txt).

I checked the code and, apparently, an easy fix could enable this feature (see write.hpp which I revised for your convenience, original lines of code are commented, those inserted are marked with an eol comment "suggested").

Thank you for your time,
Marco.

write.hpp.txt
T1.cpp.txt
T1.error.txt

When parsing a faulty file or stream, exceptions are often thrown with an empty file names, which are then replaced with in the file_parser_error() constructor. It would help our project a lot, if there was a way to pass the name of the file or a symbolic name of the input stream to the parser functions, so that this field would be filled in in the exception and shown to the user.

We are facing a weird issue on Windows, where a file move operation is not atomic: It seems to copy the file and sometimes it produces files that start normally, but then end filled with NULL characters. It looks as if a buffer was prepared, possibly memory mapped and then never filled.

Unfortunately the property_tree ini parser parses such files in many cases. Would it be possible to throw an exception on NULL characters, possibly as an option? Other characters below ASCII 32 excluding CR, LF, TAB may possibly be refused as well.

Example code:

#include <iostream>
#include <boost/property_tree/info_parser.hpp>
#include <boost/property_tree/ptree.hpp>
#include <boost/version.hpp>
#include <string>
#include <limits>


int main() {
  std::cout << "Boost Version: " << BOOST_VERSION << std::endl;
  boost::property_tree::ptree tree;

  tree.put("number", std::numeric_limits<double>::infinity());

  for (auto &[key, value] : tree)
    std::cout << key << " : " << value.get_value<std::string>() << std::endl;

  auto number = tree.get_optional<double>("number").get();
  std::cout << "number optional : " << number << std::endl;
}

Example output:

Boost Version: 107400
number : inf
test: /usr/include/boost/boost/optional/optional.hpp:1212: boost::optional<T>::reference_type boost::optional<T>::get() [with T = double; boost::optional<T>::reference_type = double&]: Assertion `this->is_initialized()' failed.
Aborted

Expected output:

Boost Version: 107400
number : inf
number optional: inf

Changing the std::string in the get_value to double results in:

terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::property_tree::ptree_bad_data> >'
  what():  conversion of data to type "d" failed

Problem also applies to float and long double types.

Tested in https://hub.docker.com/r/zouzias/boost/
and https://tio.run/##hVDRSsMwFH3vV1wqSAtze89qHwY@@OLAyV5EStbezWCahDQZFPHb603aqZuCL2lz7jkn59zamJtacnUYhiuhaukbhELozlnkbZl8YztN4MJYbdC6vqI5LoTa68pw26GdvxrzH92E82/iEW0ntLocUgyhDj8RKVrhujJJEqEctFyoLIf3BKBzDWO19g6KAtJVcIXt6MogDeBqvd48Vdu7x839@iEAUYKqkUvSxxyMnSWma/hAOJYJkWIB412WKt/u0Kaz0YRuaEVdjemKRvudxJIxWpBQwvVZnkf9XlvIuHcarp/fsJ/BkUuPL8Cic06MiyJEin1g6hD58wO6Kv4VkTxtiRZxXors4ltjVrgd4wexNo72wuUp6VefPIyzfPlroZPHSXjKM8Hn734Mwyc
and a system running boost 1.60

I have been trying to compile a program package called Bagel (https://nubakery.org/quickstart/installation_guide.html) requiring boost as a dependency. Unfortunately, I ran into the following error when making bagel:

make  all-recursive
make[1]: Entering directory '/home/rketka/src/bagel-1.2.2/obj'
Making all in src
make[2]: Entering directory '/home/rketka/src/bagel-1.2.2/obj/src'
Making all in util
make[3]: Entering directory '/home/rketka/src/bagel-1.2.2/obj/src/util'
Making all in parallel
make[4]: Entering directory '/home/rketka/src/bagel-1.2.2/obj/src/util/parallel'
/bin/bash ../../../libtool  --tag=CXX   --mode=compile mpicxx -DHAVE_CONFIG_H -I. -I../../../../src/util/parallel -I../../..   -I/home/rketka/src/boost/include -I../../../.. -DNDEBUG -O3 -mavx -MT process.lo -MD -MP -MF .deps/process.Tpo -c -o process.lo ../../../../src/util/parallel/process.cc
/bin/bash ../../../libtool  --tag=CXX   --mode=compile mpicxx -DHAVE_CONFIG_H -I. -I../../../../src/util/parallel -I../../..   -I/home/rketka/src/boost/include -I../../../.. -DNDEBUG -O3 -mavx -MT mpi_interface.lo -MD -MP -MF .deps/mpi_interface.Tpo -c -o mpi_interface.lo ../../../../src/util/parallel/mpi_interface.cc
/bin/bash ../../../libtool  --tag=CXX   --mode=compile mpicxx -DHAVE_CONFIG_H -I. -I../../../../src/util/parallel -I../../..   -I/home/rketka/src/boost/include -I../../../.. -DNDEBUG -O3 -mavx -MT rmawindow.lo -MD -MP -MF .deps/rmawindow.Tpo -c -o rmawindow.lo ../../../../src/util/parallel/rmawindow.cc
/bin/bash ../../../libtool  --tag=CXX   --mode=compile mpicxx -DHAVE_CONFIG_H -I. -I../../../../src/util/parallel -I../../..   -I/home/rketka/src/boost/include -I../../../.. -DNDEBUG -O3 -mavx -MT resources.lo -MD -MP -MF .deps/resources.Tpo -c -o resources.lo ../../../../src/util/parallel/resources.cc
libtool: compile:  mpicxx -DHAVE_CONFIG_H -I. -I../../../../src/util/parallel -I../../.. -I/home/rketka/src/boost/include -I../../../.. -DNDEBUG -O3 -mavx -MT mpi_interface.lo -MD -MP -MF .deps/mpi_interface.Tpo -c ../../../../src/util/parallel/mpi_interface.cc  -fPIC -DPIC -o .libs/mpi_interface.o
libtool: compile:  mpicxx -DHAVE_CONFIG_H -I. -I../../../../src/util/parallel -I../../.. -I/home/rketka/src/boost/include -I../../../.. -DNDEBUG -O3 -mavx -MT rmawindow.lo -MD -MP -MF .deps/rmawindow.Tpo -c ../../../../src/util/parallel/rmawindow.cc  -fPIC -DPIC -o .libs/rmawindow.o
libtool: compile:  mpicxx -DHAVE_CONFIG_H -I. -I../../../../src/util/parallel -I../../.. -I/home/rketka/src/boost/include -I../../../.. -DNDEBUG -O3 -mavx -MT process.lo -MD -MP -MF .deps/process.Tpo -c ../../../../src/util/parallel/process.cc  -fPIC -DPIC -o .libs/process.o
libtool: compile:  mpicxx -DHAVE_CONFIG_H -I. -I../../../../src/util/parallel -I../../.. -I/home/rketka/src/boost/include -I../../../.. -DNDEBUG -O3 -mavx -MT resources.lo -MD -MP -MF .deps/resources.Tpo -c ../../../../src/util/parallel/resources.cc  -fPIC -DPIC -o .libs/resources.o
mv -f .deps/resources.Tpo .deps/resources.Plo
mv -f .deps/process.Tpo .deps/process.Plo
mv -f .deps/rmawindow.Tpo .deps/rmawindow.Plo
mv -f .deps/mpi_interface.Tpo .deps/mpi_interface.Plo
/bin/bash ../../../libtool  --tag=CXX   --mode=link mpicxx -I../../../.. -DNDEBUG -O3 -mavx  -L/home/rketka/src/boost/lib  -o libbagel_parallel.la  process.lo mpi_interface.lo rmawindow.lo resources.lo  -lmkl_scalapack_lp64 -lmkl_blacs_intelmpi_lp64 -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm -lboost_regex -lboost_unit_test_framework -lboost_serialization  
libtool: link: ar cru .libs/libbagel_parallel.a .libs/process.o .libs/mpi_interface.o .libs/rmawindow.o .libs/resources.o 
ar: `u' modifier ignored since `D' is the default (see `U')
libtool: link: ranlib .libs/libbagel_parallel.a
libtool: link: ( cd ".libs" && rm -f "libbagel_parallel.la" && ln -s "../libbagel_parallel.la" "libbagel_parallel.la" )
make[4]: Leaving directory '/home/rketka/src/bagel-1.2.2/obj/src/util/parallel'
Making all in io
make[4]: Entering directory '/home/rketka/src/bagel-1.2.2/obj/src/util/io'
/bin/bash ../../../libtool  --tag=CXX   --mode=compile mpicxx -DHAVE_CONFIG_H -I. -I../../../../src/util/io -I../../..   -I/home/rketka/src/boost/include -I../../../.. -DNDEBUG -O3 -mavx -MT moldenin.lo -MD -MP -MF .deps/moldenin.Tpo -c -o moldenin.lo ../../../../src/util/io/moldenin.cc
/bin/bash ../../../libtool  --tag=CXX   --mode=compile mpicxx -DHAVE_CONFIG_H -I. -I../../../../src/util/io -I../../..   -I/home/rketka/src/boost/include -I../../../.. -DNDEBUG -O3 -mavx -MT moldenout.lo -MD -MP -MF .deps/moldenout.Tpo -c -o moldenout.lo ../../../../src/util/io/moldenout.cc
/bin/bash ../../../libtool  --tag=CXX   --mode=compile mpicxx -DHAVE_CONFIG_H -I. -I../../../../src/util/io -I../../..   -I/home/rketka/src/boost/include -I../../../.. -DNDEBUG -O3 -mavx -MT moldenio.lo -MD -MP -MF .deps/moldenio.Tpo -c -o moldenio.lo ../../../../src/util/io/moldenio.cc
/bin/bash ../../../libtool  --tag=CXX   --mode=compile mpicxx -DHAVE_CONFIG_H -I. -I../../../../src/util/io -I../../..   -I/home/rketka/src/boost/include -I../../../.. -DNDEBUG -O3 -mavx -MT molden_transforms.lo -MD -MP -MF .deps/molden_transforms.Tpo -c -o molden_transforms.lo ../../../../src/util/io/molden_transforms.cc
/bin/bash ../../../libtool  --tag=CXX   --mode=compile mpicxx -DHAVE_CONFIG_H -I. -I../../../../src/util/io -I../../..   -I/home/rketka/src/boost/include -I../../../.. -DNDEBUG -O3 -mavx -MT dfpcmo.lo -MD -MP -MF .deps/dfpcmo.Tpo -c -o dfpcmo.lo ../../../../src/util/io/dfpcmo.cc
libtool: compile:  mpicxx -DHAVE_CONFIG_H -I. -I../../../../src/util/io -I../../.. -I/home/rketka/src/boost/include -I../../../.. -DNDEBUG -O3 -mavx -MT molden_transforms.lo -MD -MP -MF .deps/molden_transforms.Tpo -c ../../../../src/util/io/molden_transforms.cc  -fPIC -DPIC -o .libs/molden_transforms.o
libtool: compile:  mpicxx -DHAVE_CONFIG_H -I. -I../../../../src/util/io -I../../.. -I/home/rketka/src/boost/include -I../../../.. -DNDEBUG -O3 -mavx -MT moldenin.lo -MD -MP -MF .deps/moldenin.Tpo -c ../../../../src/util/io/moldenin.cc  -fPIC -DPIC -o .libs/moldenin.o
libtool: compile:  mpicxx -DHAVE_CONFIG_H -I. -I../../../../src/util/io -I../../.. -I/home/rketka/src/boost/include -I../../../.. -DNDEBUG -O3 -mavx -MT dfpcmo.lo -MD -MP -MF .deps/dfpcmo.Tpo -c ../../../../src/util/io/dfpcmo.cc  -fPIC -DPIC -o .libs/dfpcmo.o
libtool: compile:  mpicxx -DHAVE_CONFIG_H -I. -I../../../../src/util/io -I../../.. -I/home/rketka/src/boost/include -I../../../.. -DNDEBUG -O3 -mavx -MT moldenio.lo -MD -MP -MF .deps/moldenio.Tpo -c ../../../../src/util/io/moldenio.cc  -fPIC -DPIC -o .libs/moldenio.o
libtool: compile:  mpicxx -DHAVE_CONFIG_H -I. -I../../../../src/util/io -I../../.. -I/home/rketka/src/boost/include -I../../../.. -DNDEBUG -O3 -mavx -MT moldenout.lo -MD -MP -MF .deps/moldenout.Tpo -c ../../../../src/util/io/moldenout.cc  -fPIC -DPIC -o .libs/moldenout.o
mv -f .deps/dfpcmo.Tpo .deps/dfpcmo.Plo
mv -f .deps/moldenio.Tpo .deps/moldenio.Plo
mv -f .deps/moldenout.Tpo .deps/moldenout.Plo
mv -f .deps/molden_transforms.Tpo .deps/molden_transforms.Plo
mv -f .deps/moldenin.Tpo .deps/moldenin.Plo
/bin/bash ../../../libtool  --tag=CXX   --mode=link mpicxx -I../../../.. -DNDEBUG -O3 -mavx  -L/home/rketka/src/boost/lib  -o libbagel_io.la  moldenin.lo moldenout.lo moldenio.lo molden_transforms.lo dfpcmo.lo  -lmkl_scalapack_lp64 -lmkl_blacs_intelmpi_lp64 -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm -lboost_regex -lboost_unit_test_framework -lboost_serialization  
libtool: link: ar cru .libs/libbagel_io.a .libs/moldenin.o .libs/moldenout.o .libs/moldenio.o .libs/molden_transforms.o .libs/dfpcmo.o 
ar: `u' modifier ignored since `D' is the default (see `U')
libtool: link: ranlib .libs/libbagel_io.a
libtool: link: ( cd ".libs" && rm -f "libbagel_io.la" && ln -s "../libbagel_io.la" "libbagel_io.la" )
make[4]: Leaving directory '/home/rketka/src/bagel-1.2.2/obj/src/util/io'
Making all in input
make[4]: Entering directory '/home/rketka/src/bagel-1.2.2/obj/src/util/input'
/bin/bash ../../../libtool  --tag=CXX   --mode=compile mpicxx -DHAVE_CONFIG_H -I. -I../../../../src/util/input -I../../..   -I/home/rketka/src/boost/include -I../../../.. -DBASIS_DIR=\"/usr/local/bagel/share\" -DNDEBUG -O3 -mavx -MT libbagel_input_la-input.lo -MD -MP -MF .deps/libbagel_input_la-input.Tpo -c -o libbagel_input_la-input.lo `test -f 'input.cc' || echo '../../../../src/util/input/'`input.cc
libtool: compile:  mpicxx -DHAVE_CONFIG_H -I. -I../../../../src/util/input -I../../.. -I/home/rketka/src/boost/include -I../../../.. -DBASIS_DIR=\"/usr/local/bagel/share\" -DNDEBUG -O3 -mavx -MT libbagel_input_la-input.lo -MD -MP -MF .deps/libbagel_input_la-input.Tpo -c ../../../../src/util/input/input.cc  -fPIC -DPIC -o .libs/libbagel_input_la-input.o
In file included from ../../../../src/util/serialization.h:46,
                 from ../../../../src/util/input/input.h:31,
                 from ../../../../src/util/input/input.cc:27:
/home/rketka/src/boost/include/boost/property_tree/ptree_serialization.hpp: In function ‘void boost::property_tree::detail::load_children(Archive&, boost::property_tree::basic_ptree<K, D, C>&)’:
/home/rketka/src/boost/include/boost/property_tree/ptree_serialization.hpp:66:24: error: ‘library_version_type’ in namespace ‘bsa’ does not name a type
   66 |             const bsa::library_version_type library_version(
      |                        ^~~~~~~~~~~~~~~~~~~~
/home/rketka/src/boost/include/boost/property_tree/ptree_serialization.hpp:69:21: error: ‘library_version_type’ is not a member of ‘bsa’; did you mean ‘boost::serialization::library_version_type’?
   69 |             if(bsa::library_version_type(3) < library_version){
      |                     ^~~~~~~~~~~~~~~~~~~~
In file included from /home/rketka/src/boost/include/boost/serialization/vector.hpp:28,
                 from ../../../../src/util/serialization.h:39,
                 from ../../../../src/util/input/input.h:31,
                 from ../../../../src/util/input/input.cc:27:
/home/rketka/src/boost/include/boost/serialization/library_version_type.hpp:36:7: note: ‘boost::serialization::library_version_type’ declared here
   36 | class library_version_type {
      |       ^~~~~~~~~~~~~~~~~~~~
In file included from ../../../../src/util/serialization.h:46,
                 from ../../../../src/util/input/input.h:31,
                 from ../../../../src/util/input/input.cc:27:
/home/rketka/src/boost/include/boost/property_tree/ptree_serialization.hpp:69:47: error: ‘library_version’ was not declared in this scope
   69 |             if(bsa::library_version_type(3) < library_version){
      |                                               ^~~~~~~~~~~~~~~
make[4]: *** [Makefile:409: libbagel_input_la-input.lo] Error 1
make[4]: Leaving directory '/home/rketka/src/bagel-1.2.2/obj/src/util/input'
make[3]: *** [Makefile:462: all-recursive] Error 1
make[3]: Leaving directory '/home/rketka/src/bagel-1.2.2/obj/src/util'
make[2]: *** [Makefile:625: all-recursive] Error 1
make[2]: Leaving directory '/home/rketka/src/bagel-1.2.2/obj/src'
make[1]: *** [Makefile:424: all-recursive] Error 1
make[1]: Leaving directory '/home/rketka/src/bagel-1.2.2/obj'
make: *** [Makefile:356: all] Error 2

I am using boost v.1.78.0 (latest stable release) which was compiled via bootstrap + b2 (g++ 10.3 default compiler) on Ubuntu 20.04. Not sure if this is a bug in boost or version incompatibility between bagel and boost. Any ideas to solve this issue?

parse xml file:

c++ code:

std::locale utf8Locale(std::locale(), new std::codecvt_utf8<wchar_t>());
std::wifstream f(*path);
f.imbue(utf8Locale);
wptree tree;
read_xml(f, tree);

xml file content:

<?xml version="1.0" encoding="UTF-8"?>
<data>
<content>你好&#128549;</content>
</data>

result is:
"你好ð��¥"

other info:
boost property tree v 1.68.0
VS 2017 15.9.4
Windows 10 17763.195

As of now ptree will not complain about a negative value and will happily cast it to unsigned type. If that's expected then I think it's highly unintuitive.

    boost::property_tree::ptree pt;
    pt.put("foo", "-1");
    std::cout << pt.get<unsigned>("foo") << std::endl; // 4294967295

multi_index_container provide typename Allocator, but basic_ptree doesn't provide it.
How i can use custom allocator for basic_ptree?

I already use custom allocator for key and values.

It has some important fixes for placeholder warnings, e.g. d1c8825

repo: https://github.com/boostorg/property_tree

This was discovered when enabling clang implicit modules (and by implication will affect C++20 header-units). property_tree/detail/file_parser_error.hpp uses stringstream without #including , and therefore is not self contained. Fixed thusly:

--- c/1.77.0/src/boost_1_77_0/boost/property_tree/detail/file_parser_error.hpp
+++ w/1.77.0/src/boost_1_77_0/boost/property_tree/detail/file_parser_error.hpp
@@ -12,6 +12,7 @@
 
 #include <boost/property_tree/ptree.hpp>
 #include <string>
+#include <sstream>
 
 namespace boost { namespace property_tree
 {

boost1.56.0 boost::property_tree::read_json takes a long time 16ms, and occasionally takes a short time 0ms

/*CODE_1*/
boost::beast::http::response<boost::beast::http::string_body> &&res
...
std::stringstream ss;
ss << res.body();
boost::property_tree::ptree tree{};
boost::property_tree::read_json(ss, tree);

CODE_1 is fine.

/*CODE_2*/
boost::beast::http::response<boost::beast::http::string_body> &&res
...
std::stringstream ss;
ss << res.body();
std::string msg;
msg << ss.str();
ss.clear();
ss << msg;
boost::property_tree::ptree tree{};
boost::property_tree::read_json(ss, tree);

CODE_2 throws exception("garbage after data").

Variable "ss" is encoded utf-8.
Why does read_json(..) throw exception for utf-8 stringstream from string?

/cc @madmongo1

Minimal Working Example

https://godbolt.org/z/x4zx388h6

#include <boost/property_tree/detail/rapidxml.hpp>
int main() {}

Use latest Boost 1.76 and compile with any compiler of your choice.
I can not reproduce the problem with Boost 1.75.

Compilation Error

• msvc

error C3646: 'BOOST_OVERRIDE': unknown override specifier

• clang

/opt/compiler-explorer/libs/boost_1_76_0/boost/property_tree/detail/rapidxml.hpp:61:41: error: expected ';' at end of declaration list
        const char *what() const throw() BOOST_OVERRIDE
                                        ^

• gcc

/opt/compiler-explorer/libs/boost_1_76_0/boost/property_tree/detail/rapidxml.hpp:61:40: error: expected ';' at end of member declaration
   61 |         const char *what() const throw() BOOST_OVERRIDE
      |                                        ^
      |                                         ;
/opt/compiler-explorer/libs/boost_1_76_0/boost/property_tree/detail/rapidxml.hpp:61:42: error: 'BOOST_OVERRIDE' does not name a type; did you mean 'BOOST_VERIFY'?
   61 |         const char *what() const throw() BOOST_OVERRIDE
      |                                          ^~~~~~~~~~~~~~
      |                                          BOOST_VERIFY

References

It looks like PR #53 from @EugeneZelenko introduced this bug - likely, missing #include <boost/config.hpp>.
There seem to be no related test case to check headers are self-contained.

Only two lines in the whole code use typeid, just to show an error message. This can be circumvented by using boost::typeindex::type_id when compiling with -DBOOST_NO_TYPEID in order to succeed with the compilation.

I'm using the property_tree to parse an XML with

std::wstringstream responseStream(response);
boost::property_tree::wptree responseTree;
boost::property_tree::read_xml(responseStream, responseTree);

and the stack-overflow error occurs in void boost::property_tree::xml_parser::read_xml_node when trying to parse considerably deep XMLs.

AddressSanitizer's trace:
boost_property_tree_stack_overflow_AddressSanitizer.txt

Boost version: 1.66.0

boost::property_tree is able to read the XML attribute values it writes, however it seems to not implement XML attribute normalization:
https://www.w3.org/TR/REC-xml/#AVNormalize

Namely, if a XML attribute value contains newlines or tabs, these newlines or tabs are replaced by libexpat by spaces after parsing and before passing to an application due to the mandatory normalization as shown by the following table from the XML norm:

Please note that an attribute type is considered CDATA by default.

And by the way, none of the XML parsers / writers that I checked (boost serialization, tinyxml, lib3mf) seem to implement normalization.

This issue is similar to 3MFConsortium/lib3mf#288

The error handling of parsing JSON is not expressive enough in order to solve related problems.

Looking at https://www.boost.org/doc/libs/1_59_0/boost/property_tree/detail/json_parser/parser.hpp
void parse_escape(), we fail the function with parse_error("invalid escape sequence");

Unfortunately, if all your JSON is on a single line, this tells you that there is a problem on line 1.
To make this message more usable, it would make sense to not only store the line number, though also the column number, so we can check which character is incorrectly escaped. In an ideal world, the exception would even contain that character.

Hi,

the simple example found here, https://www.boost.org/doc/libs/1_78_0/doc/html/property_tree/accessing.html
gives the error below on the full code:

#include <boost/property_tree/xml_parser.hpp>
#include <iostream>

using boost::property_tree::ptree;

int main() {
    ptree pt;
    pt.push_back(ptree::value_type("pi", ptree("3.14159")));
    ptree::const_iterator it = pt.find("pi");
}

C:\Users\tsch\source\repos\ConsoleApplication2\ConsoleApplication2.cpp(10,45): error C2440: "Initialisierung": "boost::property_tree::basic_ptree<std::string,std::string,std::less>::assoc_iterator" kann nicht in "boost::property_tree::basic_ptree<std::string,std::string,std::less>::const_iterator" konvertiert werden
1> with
1> [
1> Key=std::string
1> ]

of course, it works with 'assoc_iterator', but if this is intended, the documentation needs a change.

Thomas