Florent Rougon
e59f8eda74
Add the EmbeddedResourceManager class as well as AbstractEmbeddedResource and two derived concrete classes: RawEmbeddedResource and ZlibEmbeddedResource. The purpose of this is to provide a way for FlightGear to use data from files without relying on FG_ROOT to be set. The whole system (SimGear and FlightGear parts) was described in detail at [1]. I'll probably include a copy in $FG_ROOT/Docs too for fear of the link becoming dead one day. Basically, classes derived from AbstractEmbeddedResource provide access to some data---the source of which is a priori of static storage class---and handle the conversion from whatever format it is stored in to allow convenient use of said data. At the very least, they allow obtaining ready-to-use data as an std::string, as well as reading it incrementally via an std::streambuf or an std::istream interface. ZlibEmbeddedResource instances also provide access to the compressed size of the data (i.e., as stored in static memory) as well as its uncompressed size, without requiring any prior decompression. EmbeddedResourceManager is a class which FlightGear will normally instantiate exactly once---it has createInstance() and instance() static methods for this. It maintains a map between resource paths and instances of concrete classes derived from AbstractEmbeddedResource. It also provides convenience methods allowing to access a resource data in one step (not requiring to manually fetch the AbstractEmbeddedResource-derived object corresponding to the given resource path before calling the appropriate method of this object). From the EmbeddedResourceManager's point of view, resource paths (keys of the map) are just plain std::string instances in the current implementation. However, unless there is a good reason not to, I think it's a good idea to only use values obtained with SGPath::utf8Str()[2]. This is precisely what fgrcc, the resource compiler in the FlightGear repository, does; so, unless you register resources manually, your resource paths will automatically comply with this suggestion. [1] https://sourceforge.net/p/flightgear/mailman/message/35870025/ [2] This allows later addition of methods listing all resources under a given virtual path, as well as optimized resource lookup using a tree-like data structure instead of an std::unordered_map (not justified now IMO).
15 lines
524 B
CMake
15 lines
524 B
CMake
include (SimGearComponent)
|
|
|
|
set(HEADERS EmbeddedResource.hxx EmbeddedResourceManager.hxx)
|
|
set(SOURCES EmbeddedResource.cxx EmbeddedResourceManager.cxx)
|
|
|
|
simgear_component(embedded_resources embedded_resources
|
|
"${SOURCES}" "${HEADERS}")
|
|
|
|
if(ENABLE_TESTS)
|
|
add_executable(test_embedded_resources embedded_resources_test.cxx)
|
|
target_link_libraries(test_embedded_resources ${TEST_LIBS})
|
|
add_test(embedded_resources
|
|
${EXECUTABLE_OUTPUT_PATH}/test_embedded_resources)
|
|
endif(ENABLE_TESTS)
|