Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix casters of STL containers with char* #2303

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

YannickJadoul
Copy link
Collaborator

@YannickJadoul YannickJadoul commented Jul 16, 2020

This cóuld fix #2245, I believe. Would you mind testing, if it does, @codypiersall?

If it does, the question is if this is a price we're willing to pay for it?

On the one hand, the casters for tuple, pair, etc, also hold on to their subcasters. On the other hand, it might be a heavy price to "just" solve the issue with char *? Maybe there is a better way to keep the things char* point to alive?

Closes #2245 (if we'd decide to merge it).

@@ -342,6 +369,7 @@ struct variant_caster<V<Ts...>> {
auto caster = make_caster<U>();
if (caster.load(src, convert)) {
value = cast_op<U>(caster);
subcaster = std::move(caster);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, are casters movable?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are.

@YannickJadoul
Copy link
Collaborator Author

An alterantive to solve #2245 would be to just disallow type_caster<char*> as a nested type, btw (either by extending type_casters to tell whether they can be used a subcasters, or by ad-hoc not allowing char* to be nested in these stl.h casters).

Copy link
Collaborator

@bstaletic bstaletic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This does look really expensive from here. Like we discussed, it would also need tests and there's a problem of memory and types like vector<vector<vector<...<T>>>>.

@@ -287,6 +311,9 @@ template<typename T> struct optional_caster {
}

PYBIND11_TYPE_CASTER(T, _("Optional[") + value_conv::name + _("]"));

private:
value_conv inner_caster;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Call it subcaster, for consistency's sake.

@@ -342,6 +369,7 @@ struct variant_caster<V<Ts...>> {
auto caster = make_caster<U>();
if (caster.load(src, convert)) {
value = cast_op<U>(caster);
subcaster = std::move(caster);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are.

@YannickJadoul
Copy link
Collaborator Author

OK, this still has a major problem, actually. For types that aren't movable or aren't empty when moved out (like std::array), this will take more memory (linear in the depth of the nesting), since: e.g. a type_caster for std::vector<T> now contains std::vector<T> value; as well as std::vector<type_caster<T>>, where type_caster<T> possibly has the same duplication again.

So array<array<array<array<array<int>>>>> will contain 6 times the amount of memory actually needed before. So we still need to find a better solution.

@EricCousineau-TRI
Copy link
Collaborator

EricCousineau-TRI commented Oct 8, 2020

I think the following things are at play here:

I don't think you can get around "all the things need to stay alive", at least for the above cases.

The only two solutions I see:

  1. Expressly forbid it. Make an explicit error for py::cast<container<char*>>(...) that says this is a a bad idea.
  2. Specialize container casters to have the parallel caster containers only when necessary. Thus, vector<vector<...<int>...>> isn't affected.
    • This works for loading in a very constrained scope (e.g. immediate function calls). Outside of that, say for .def_readwrite, it gets sketchy real fast.

Do you imagine other possibilities?

@EricCousineau-TRI
Copy link
Collaborator

EricCousineau-TRI commented Oct 8, 2020

Er, also, is it linear or exponential? I think it may be exponential, like O(N^depth)? (so 2^5 => 32 times the amount of memory?)

@EricCousineau-TRI
Copy link
Collaborator

EricCousineau-TRI commented Oct 8, 2020

And looking at @kenoslund-google's overview in #2527, yeah, I think that's what they're implying -- the specialization approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

passing containers of char * (e.g. std::vector<char *>) does not work
3 participants