Yes, we still have to deal with C, but I can’t see a way in the VSS docs to get a C array of the UTF8 string without going through multiple long string copies. Is there a way to do this I’ve not seen yet?
Also, what’s an IRI?
Oh, and why aren’t the streams derived from the Ada stream types? By not deriving from the standard Ada streams, network streams can’t be used.
So, I’ve tried to add vss_text and then build to get:
proj.gpr:3:09: shared library project "proj" cannot import project "vss_text" that is not a shared library project
proj.gpr:3:09: shared library project "proj" cannot import project "vss_json" that is not a shared library project
Note, everything below applicable to vss-text only, and not for old VSS.
Interfacing with C is not implemented yet. There are few know issue to implement efficient C interface:
C char* ownership management:
pointer can be managed at C side
pointer can be passed to Ada and need to be managed at Ada side
appropriate allocator/deallocator should be used for each char*
Virtual_String’s Storage_Address can be converted to char* (data is null-terminated) and passed to C, but it is valid till Ada object is not modified or destroyed
when data comes from C it should be validated to be well formed UTF-8
You can take a look how Python string object is managed by Virtual_String without unnecessary copy of the data
IRI is internationalized resource identifier. It is mostly placeholder to add parsing/composing subprograms in the future.
VSS provides “high level” unidirectional text streams. They do encoding/decoding of the text on the fly. Ada’s streams are binary non-typed bi-directional streams. It is meaningless to write Virtual_String to Ada stream, as well as to read it from the stream.
You need to set LIBRARY_TYPE/VSS_LIBRARY_TYPE scenario variable to relocatable to build VSS’s libraries as shared libraries.