How about using the binary format of the VM itself? It’s a tested format that gives you instant compatibility with Pharo. I guess the VM people have documentation for it and could give you some pointers.
-- Does this mail seem too brief? Sorry for that, I don’t mean to be rude! Please see http://emailcharter.org <http://emailcharter.org/> . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On 09 Nov 2016, at 17:27, Dimitris Chloupis <kilon.al...@gmail.com> wrote: > > So now that CPPBridge at least basic are sort out I have to figure out a > binary file format > > The idea here is to implement an image format which will be part of the > memory of the Pharo process but will live outside the memory of the Pharo VM. > Lets call this CPPMemory will be stored to an image file, lets call it > CPPImage, like we do with the Pharo image and will store a shared state among > all other processes (Pharo or not) that connect to this shared memory > (CPPMemory) via accessing the file (CPPImage). So basically it will act as an > extension to the Pharo image. > > In the image file , objects will be stored obviously not in a byte-code > format but definitely in a byte format that will basically store the data of > this object using very basic primitives like character , integers and of > course bytes. > > Obviously each object will have to have an id as a header and also its size > in bytes and the size of each of its instance variables. > > There will be also a global headers for the entire file with the list of the > objects included and probably a references to other CPP images that they will > be able to interconnect with each other like lego blocks. > > Thats my vague idea, but I am open to suggestions and even links to articles > and documentation about what a binary format must have to be considered well > architectured. Obviously I dont expect perfection because this is my first > binary file format but at least I am looking for advise for avoiding common > pitfalls.
