diff options
author | Adrian Kummerländer | 2014-05-11 20:09:34 +0200 |
---|---|---|
committer | Adrian Kummerländer | 2014-05-11 20:09:34 +0200 |
commit | 20fca5978b55606062cdaf4c94dec82f5318a62a (patch) | |
tree | 3bd7752f8d914525620ff65a9f0235824f07f1da /test/read_xml_file | |
parent | 0cd17b0afde7fc97584af31dfdfc376ef6906517 (diff) | |
download | InputXSLT-20fca5978b55606062cdaf4c94dec82f5318a62a.tar InputXSLT-20fca5978b55606062cdaf4c94dec82f5318a62a.tar.gz InputXSLT-20fca5978b55606062cdaf4c94dec82f5318a62a.tar.bz2 InputXSLT-20fca5978b55606062cdaf4c94dec82f5318a62a.tar.lz InputXSLT-20fca5978b55606062cdaf4c94dec82f5318a62a.tar.xz InputXSLT-20fca5978b55606062cdaf4c94dec82f5318a62a.tar.zst InputXSLT-20fca5978b55606062cdaf4c94dec82f5318a62a.zip |
Switched internal DomDocumentCache structure to std::stack
* using std::unordered_map for named cache lookups was a nice idea but is not useful when one keeps in mind that:
** we don't want cached external function responses in a situation where we are able to execute transformations inside transformations
** cached responses mean that we can not read a xml file, overwrite it using another transformation and then read it again
* the currently available InputXSLT frontend only processes a single transformation anyway, so increased memory requirements should not pose a problem
** if a future frontend should offer batch processing of transformation tasks, one could implement a cache reset method to free memory after a transformation has been processed
Diffstat (limited to 'test/read_xml_file')
0 files changed, 0 insertions, 0 deletions