Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
Although functions/components that require minimal pre-existing state are nice,
these allocate memory and could potentially share resources. So, give them a
pointer to a world which can be used to configure such things. In particular,
this is working towards supporting custom allocators everywhere.
|
|
More or less the same rationale as the previous commit, but for reading. This
makes for nice symmetry with writing, at the cost of a slightly more annoying
reader interface since the source doesn't know its block size or name.
|
|
This makes the paging mechanism an internal detail once again. While it's
conceptually elegant to simply have a single write interface and have the block
dumper just be another implementation of that, unfortunately it is not
practical. The inlining of serd_block_dumper_write() is a significant
performance boost, because it avoids a non-inlinable function call of overhead
per character.
Compared to the SerdByteSink approach, this removes the burden and overhead of
needing to dynamically allocate the structure itself.
|
|
Although the "verbatim" idea is nice and simple, more fine-grained control is
necessary since these features (relative URI preservation and blank node label
clash avoidance) are useful in different situations.
|
|
|
|
This simplifies everything by replacing special cases with a more general close
function. A type is no longer stored in the structure, so the other
constructors are now essentially syntactic sugar for the universal
serd_byte_sink_new_function().
|
|
|
|
Clang issues warnings at build time based on the SERD_NONNULL annotations,
which is a much better approach in general. However, it does not cover cases
where the API is being used with another compiler, or without a compiler that
can statically check things at all (such as Python or other dynamic language
bindings).
In those situations, getting a clear assertion message is a lot less confusing
than a random crash somewhere in serd, and it makes it clear that the bug is in
the caller, so I think it's worth the tedious verbosity.
|
|
|