Re: Merging Iterator Design
Sebastian Redl wrote:
I'm working on an iterator that encodes and decodes endianness on the fly.
The basic idea is very simple: there is a base iterator whose value_type
is some octet type (e.g. uint8_t). The endian iterator wraps this base
iterator and, upon reading, takes the appropriate number of octets and
merges them into its own value type (typically uint16_t or uint32_t). Upon
writing, the iterator splits the value up and writes the individual octets
to the correct position.
There are some issues with this.
[...]
The second issue is that of range size. To work correctly, the size of the
underlying range must be a multiple of the number of octets in the endian
iterator's value type.
[...]
One way to solve this issue is to simply make proper size a requirement
and declare everything else undefined behaviour.
I'd go for this solution. In practice, any such faulty use would be detected
by the underlying iterator, assuming it uses a checked implementation. All
major C++ standardlibraries have such a mode.
I'd also do it this way because it is hard to handle otherwise. Should the
sequence end when the last input element or when the last output element
are consumed? One will leave elements in the input sequence, the other will
use an incomplete output element. Both are conditions that should be
checked before. This is also mostly in the spirit of the STL to not
sacrifice performance (i.e. additional checks) when they aren't necessary.
Uli
--
Sator Laser GmbH
Gesch??ftsf??hrer: Ronald Boers Steuernummer: 02/858/00757
Amtsgericht Hamburg HR B62 932 USt-Id.Nr.: DE183047360
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]