maybe i got a bug

[monarch_dodra]

On Friday, 1 February 2013 at 09:09:10 UTC, bioinfornatics wrote:
> As i use a memory mapped file i won't copy my struct for able to
> loop as i do not want map the file twice that is rather a big
> problem for a big file this a perf issue. memory mapped file is
> used to read fastly a file so is a nonsense

In a word, the problem is that your "FastqReader" is both 
container and range. Those are complettly different notions that 
should not be confused.

The fastqreader should be a container, that holds your binary 
payload. You should be able to extract a range from the 
container, and iterate on the container, without modifying the 
container.

Currently, iterating on your fastqreader will mutate it. This is 
very bad. The only cases I know of where this happens are with 
pure input ranges, but in those cases, you virtually never have 
access to the underlying container (which usually doesn't exist 
anyways).

--------
The easy workaround is to start by renaming your "popFront" into 
"removeFront": popFront is an iteration primitive. removeFront is 
a container primitive. By changing this name, you fastqreader 
will cease to adhere to any range interface, protecting you from 
wrong usage.

Once there, you need to define a Range, or just have "opSlice()" 
and "opSlice(size_t, size_t)" return said range.

Ideally, I'd avoid defining an actual "Range" type, and simply 
return the string (as you are doing).

However, given you seem to be doing something with dna, and 
require random access, I'm not sure "string" is the best (string 
is unicode aware, so doesn't actually adhere to RA). I'd stick to 
just returning a "const(ubyte)[]".