liese

[ləˈiːs]

Grad student in CS. Monotropic nerd who spends way too much time with computers (and books (and computer books)). Likes space.


You must log in to comment.

in reply to @liese's post:

ahh yeah, initializer_lists dont own their data unfortunately. i believe it's because they're intended to work more like a span than a vector. but yeah i agree, it's generally a bad API except for very specific circumstances, like containers.

it's up to you, but i would give parameter packs a chance; they're one of the things C++ has over most other languages of its type, and they're quite powerful if you can wrangle them. the inference rules are kind of a pain, though, yeah :c

I was using parameter packs before, and I like them a lot in principle! Unfortunately, for what I'm trying to do, I kept getting errors about parameter inference failures

More or less, I'm trying to define a labeled tree structure that can have a type T at the leaves, and I want to be able to construct those trees with minimal boilerplate:

my_tree_thing<outputs> get_outputs() const override {
  return {
    {"foo", this->foo},
    {"bar", {
      {"baz", this->baz},
    }},
  };
}

This already works just fine in my current setup; but I'm trying to switch from std::shared_ptr to std::unique_ptr for storing childen, and I'm running straight into this initializer_list issue.

Honestly, I'd love to use template parameter packs here, regardless of the shared_ptr issues. But for the above syntax to work out, it seems like I have to give enough concrete type information in the constructor for the compiler to decide "ah, these brackets are an initializer for this type". Parameter packs don't leave enough type information at either the caller or the callee to resolve the type.

Yes, I'm being stubborn about not having to decorate the syntax above with type names. But it works now, darn it! 😅

that's totally fair! yeah, the "only functions are allowed to do full template type inference" thing is pretty annoying. typically, i make auxiliary make_foo functions for each templated type foo so i can get inference to work, but that's also some boilerplate compared to the {} syntax, yeah.

one thing you could possibly do is make the initializer_list out of shared_ptrs, then release() them into your final unique_ptrs? i'm pretty sure shared_ptr provides interior mutability. just a thought, you've nerd-sniped me with this problem hehe c:

i'm really curious what your eventual solution will be!

one thing you could possibly do is make the initializer_list out of shared_ptrs, then release() them into your final unique_ptrs? i'm pretty sure shared_ptr provides interior mutability.

hmmmm! I may have to try this! Thank you for your thoughts ^_^