Open hahnjo opened 2 weeks ago
As discussed, for std::vector
with a non-default allocator we should likely go through the collection proxy support. For maps and sets, we may already support (via the collection proxies) and it's just a matter of relaxing the partial specializations and maybe the logic in RFieldBase::Create
.
Will the on-disk representation of vectors be the same for all possible allocators? Will it be possible to read back vectors with an allocator which was different than the one used when they were written?
Will the on-disk representation of vectors be the same for all possible allocators? Will it be possible to read back vectors with an allocator which was different than the one used when they were written?
Very relevant questions; IMHO additional template parameters should not change the on-disk representation of STL containers, and it should be possible to transparently read them back with different parameters than at write time. If nothing is specified and the model is reconstructed, the user gets the default STL container as before. I think this would be compatible with the current state of the specification, otherwise we may need to think this through before declaring 1.0.
To be more precise than just a thumbs up: I also think the on-disk representation should not depend on the allocator.
Will the on-disk representation of vectors be the same for all possible allocators? Will it be possible to read back vectors with an allocator which was different than the one used when they were written?
For reference, this is already the case (for both questions, the answer is yes) for TTree
(and thus must be the case for RNTuple
)
As pointed out by ATLAS, it's currently not possible to use a
std::vector
with a non-default allocator in RNTuple:leads to
This is because
RField
is only partially specialized forstd::vector<ItemT>
, so a non-defaultAllocator
falls back to the defaultRField
declaration (which assumes it's a class and checks that it's not instd
namespace).Note that in principle, this affects all STL containers. For many of them, there are other template parameters, for example
Hash
forstd::unordered_set
:leads to