opened
Carter12s
username_0
I am attempting to use Sol2 with some existing data structures that make heavy use of boost::property_tree to store general data within them. I'm hoping to find an easy way to inter-operate between Lua tables and boost::poroperty_tree which are very similar. However, I can't seem to get a working example. It appears as thou the is_container specialization is not working.

Here is a basic example:
```
#include<sol.hpp>
#include<boost/property_tree/ptree.hpp>

namespace sol{
template<>
struct is_container<boost::property_tree::ptree> : std::false_type {};
}

class hasP{
public:
  boost::property_tree::ptree data;
};

int main()
{
  sol::state lua;
  lua.new_usertype<hasP>("hasP", "data", &hasP::data);
  return 0;
}
```

This will not compile, throwing:

sol.hpp:15603:36: error: no match for ‘operator+’ (operand types are ‘sol::container_detail::container_traits_default<sol::as_container_t<boost::property_tree::basic_ptree<std::__cxx11::basic_string<char>, std::__cxx11::basic_string<char> > >, void>::K {aka std::pair<const std::__cxx11::basic_string<char>, boost::property_tree::basic_ptree<std::__cxx11::basic_string<char>, std::__cxx11::basic_string<char> > >}’ and ‘int’)
     p = stack::push_reference(L, k + 1);

I'm new to using sol, so I might just be going about this the wrong way, but it seems like the is_container specialization is failing...
Using Sol with Boost::property_tree: issues with is_container
issue
created
ThePhD
username_1
I'm a bit confused. The reason you do

```
namespace sol{
template<>
struct is_container<boost::property_tree::ptree> : std::false_type {};
}
```

Is because you *don't* want `boost::property_tree` to have the container specializations applied to it (that is, you explicitly specialize it to `std::false_type`). ... But, from your issue request, you kind of do want it to behave like a container/table in Lua?

Either way, this code shouldn't fail to compile, but I'm still confused as to your intent here. I'll look into the compiler error, but in the meantime please give me a little example lua code so I can understand what's you're going for...
comment
closed
ThePhD
username_1
issue
created
Carter12s
username_0
Sorry if that was confusing. I am attempting to somehow interface boost::property_tree with Lua. Originally, I had hoped to directly use a ptree as a table in Lua, but I have since realized that there are differences in their definitions that will make that impossible. So now, I want to define my own usertype for ptree and expose its api in a simplified way to Lua. However, I cannot get any usertype for ptree to compile as the automatic container code seems to kick in no matter what. Here is a more direct example:

```
#include <LuaPlanning/sol.hpp>
#include <boost/property_tree/ptree.hpp>

namespace sol {
template<>
struct is_container<boost::property_tree::ptree> : std::false_type {};
}

int main()
{
    sol::state lua;

    lua.new_usertype<boost::property_tree::ptree>("Ptree");

}
```

That will fail to compile with the same error as above. Any ideas?
comment
created
FetusGod
username_2
You could get a very basic system only dealing with getting keys, and setting keys, with simple tables, but no ability to manipulate arrays. I suppose anything is possible in programming, but to deal with setting/getting, children/parents, emulating a FOR_EACH loop, and other complexities, that will take a bit of work and I have no idea how to deal with it. 

But carrying on, since the property tree's >basic< function is almost like a std::map, you could use [this example](https://github.com/username_1/sol2/blob/develop/examples/dynamic_object.cpp), and simply modify the get and set, with ptree's "get()", and "put()"(or add()?). And these functions can use periods to access tables.
comment
created
ThePhD
username_1
Pull from the latest and your problem should be solved.

The issue was that `boost::property_tree::basic_ptree<...>` doesn't exactly obey the standard container methods. Even if you mark it as "not a container", we still access the container meta-table information so we can automatically generate `begin()`/`end()` pairs on it that map to Lua's `pairs(my_container)` calls and similar. It was erroring because the key type we identified for the type was not exactly what we were looking for.

The latest should fix your problems, but I can't really write tests against boost right now, not until I finish working on my CMake harness to have a third class of tests against 3rd-party libraries. I did confirm it builds on my machine, but that doesn't guarantee its type will work out.

If you want to create a custom container around `boost::property_tree::ptree`, then I urge you to look at [the container documentation](http://sol2.readthedocs.io/en/latest/containers.html). It includes a detailed description of how you would override the operations for a single container type, and thus make it behave as you would like it to. This is probably the best way to get the "full experience", but you can also do what the dynamic_object examples and similar linked earlier do as well.
comment
created
Carter12s
username_0
Awesome! Thank you, I'll take a look. I appreciate the support. I'll let you know what I get working.
comment