Hello C++ developers,
I’ve been experimenting with orthogonal persistence of various C++ data structures in canisters on the Internet Computer (IC) and would like to share my findings with the community.
TL;DR
It works great!
Here are the key points:
- Data structures fully living in the global/static section of the stack are correctly persisted. This includes regular data types like
int
,float
,uint64_t
, etc. and the special STL containerstd::array
, which keeps all its data on the stack. - Self-managed dynamic data structures are correctly persisted too. This is when the data lives on the Heap, but the pointer to the data is in the global/static section of the stack. This was tested for both
new/delete
andcalloc/free
style memory management. - Self-managed pointers to STL containers that use dynamic heap memory, like
std::vector
,std:string
&std::unordered_map
also work. As long as you self manage a pointer in the global/static memory, and then use new/delete on them inside your functions. - Defining STL containers that use dynamic heap memory directly in global/static section is not working. Not only are they not persisted, just adding these to the global/static section corrupts the canister memory, even if you’re not using them at all… The tests show that the metadata for the
std::vector
(like its size and the Heap address pointed to by the vector) is persisted, but the actual values aren’t. I would love to get the perspective from the DFINITY team if they have any idea why adding STL containers likestd::vector
directly to the global/static section is not possible. Is this a bug in the Orthogonal Persistence code for canisters, or if not, can I enter a feature request to get it supported? It is not a blocker by any means, because options 1,2,3 all work perfect, but it would be good to support it.