These are chat archives for boostorg/hana

20th
Feb 2017
Jason Rice
@ricejasonf
Feb 20 2017 00:10
I'm not sure what you mean. Do you have a code snippet to show?
Hana functions do not necessarily run at compile-time, but the length of a hana::Foldable is known at compile-time. You shouldn't need to put it in a run-time list.
Scott Santucci
@ScottFreeCode
Feb 20 2017 00:13
Let me see if any of my half-baked attempts is still in the undo history over here...
Scott Santucci
@ScottFreeCode
Feb 20 2017 00:43
So, I expect this to fail on line 36, but it fails on line 29. http://melpon.org/wandbox/permlink/NGxu6Xcs3LjwiBut
Scott Santucci
@ScottFreeCode
Feb 20 2017 00:58
(Of course, I really can't tell what the error message means. So it's entirely conceivable that I'm just doing something wrong C++-wise?)
(Now, the fact that I can't use the optional result this way, I'm well aware of; I just didn't want to hold up the example figuring out how to adequately code "continue parsing only if the field is valid, otherwise stop with an error". So I put in a bad, un-functional placeholder.)
(But that's a moot point unless I can search for the field by runtime data in the first place.)
Jason Rice
@ricejasonf
Feb 20 2017 01:16
I'm pretty sure the predicate to find_if must return a compile-time bool. The std::stringvalue is only known at run-time.
Scott Santucci
@ScottFreeCode
Feb 20 2017 01:33
Right, that's why I was trying to think of a way to search the list at runtime...
Jason Rice
@ricejasonf
Feb 20 2017 03:26
Ah yeah, using jsoncpp I guess I didn't have to deal with that. Mapping run-time stuff to compile-time stuff can be tricky. I made a variant type that maps a sequential index to each of its types. You could possibly do the same thing except use a hash of the field name to map to each field. Since each field would potentially be of different types, you couldn't simply return it from a lookup function. I believe the only way to get around this is to provide a function that takes the result as a parameter.
Scott Santucci
@ScottFreeCode
Feb 20 2017 13:55
Since my use case is just reversing Hana's excellent serialization abilities, I don't think I need to worry too much about different types as long as I can come up with something that will convert the value string to whichever field's type it finds (probably like visiting a variant, yeah, except that the list is more like a std::tuple with a std::map-like search ability and no dynamic allocation since the keys and the values' types are both known at compile-time)... And converting Hana's struct accessor lists to such a type should be entirely doable as well, using Hana's compile-time computation abilities. So I just have to work through implementing that type. Yeah, this is gonna be more work than I originally assumed but it should be entirely doable.
I will take a look at jsoncpp and see how much I can learn from your case; thanks!
And thanks for helping me work through the ideas involved.
(If anybody knows of an already-existing compile-time-generated runtime-searchable homogenous-keyed heterogenous-valued object, let me know, because I'd love to be able to just borrow another existing library. Although optimizing it for the case of searching on C strings would be pretty cool too [e.g. start by sorting into buckets by string length so the rest of the search has a significantly smaller space, as finding the bucket with matching length should be quick in and of itself]...)