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
right now, we represent std::set<T> and std::map<K,V> (and their multiX and unordered_X equivalents) as map[T]struct{} and map[K]V.
however, e.g.std::set<std::vector<T>> breaks this conversion: map[[]T]struct{} isn't a valid Go type ([]T isn't hashable).
same issue for, say, std::map<std::vector<T>, V>.
there are 2 use cases:
read a ROOT file produced with C++/pyroot and thus generate equivalent Go types to hold these data
write a ROOT file from groot (so with hopefully already valid Go types)
obviously, the latter isn't impacted by this issue.
to tackle the former, a possible avenue would be to implement dedicated types mimicking C++ semantics:
right now, we represent
std::set<T>
andstd::map<K,V>
(and theirmultiX
andunordered_X
equivalents) asmap[T]struct{}
andmap[K]V
.however, e.g.
std::set<std::vector<T>>
breaks this conversion:map[[]T]struct{}
isn't a valid Go type ([]T
isn't hashable).same issue for, say,
std::map<std::vector<T>, V>
.there are 2 use cases:
groot
(so with hopefully already valid Go types)obviously, the latter isn't impacted by this issue.
to tackle the former, a possible avenue would be to implement dedicated types mimicking C++ semantics:
ultimately, this might be better resolved by implementing on-the-fly conversions between on-disk and in-memory representations:
set<T>
to/from[]T
map<K,V>
to/from[]pair[K,V]
The text was updated successfully, but these errors were encountered: