You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Having different storage for values and sequences when it comes to bool is annoying, also from the code complexity point of view.
As of today, our YAML parser stores arrays of bool as std::vector<int>. PR #189 changes that into std::vector<char>, so that we can tell a true array of ints from an array that is used to store bools. This, however, does not solve the asymmetry between "list of supported value types" and "list of supported sequence types".
One solution could be to store arrays as std::deque<T>, which is technically not an array, but it is still indexable via operator[] (which is likely all that a user needs). This would make parsing/writing/storing an array of T implementable as a for loop wrapping the parsing/writing/storing of individual T values.
This would be a NON backward compatible solution, since all p.get<std::vector<T>>(pname) calls will have to be changed. We could hope to implement a deprecated specialization for get<std::vector<T>>, so that old code can still work while the deprecated interface is there. But that interface would require some dark magic hack to provide a (const) ref to a vector without actually storing one.
The text was updated successfully, but these errors were encountered:
Having different storage for values and sequences when it comes to bool is annoying, also from the code complexity point of view.
As of today, our YAML parser stores arrays of bool as
std::vector<int>
. PR #189 changes that intostd::vector<char>
, so that we can tell a true array of ints from an array that is used to store bools. This, however, does not solve the asymmetry between "list of supported value types" and "list of supported sequence types".One solution could be to store arrays as
std::deque<T>
, which is technically not an array, but it is still indexable viaoperator[]
(which is likely all that a user needs). This would make parsing/writing/storing an array of T implementable as a for loop wrapping the parsing/writing/storing of individual T values.This would be a NON backward compatible solution, since all
p.get<std::vector<T>>(pname)
calls will have to be changed. We could hope to implement a deprecated specialization forget<std::vector<T>>
, so that old code can still work while the deprecated interface is there. But that interface would require some dark magic hack to provide a (const) ref to a vector without actually storing one.The text was updated successfully, but these errors were encountered: