View mode: basic / threaded / horizontal-split · Log in · Help
August 26, 2012
Re: RefRange
On 08/26/2012 02:46 PM, David wrote:
> Sorry, dmd 2.060

Hmmm. I use 2.060 as well.

Ali
August 27, 2012
Re: Forward Range(s)
On Sunday, August 26, 2012 23:20:49 Era Scarecrow wrote:
> On Sunday, 26 August 2012 at 18:07:27 UTC, Jonathan M Davis wrote:
> > But it would be better IMHO to just fix it so that your range
> > is a forward range, since there's no reason for it not to be.
> 
> That brings up my own question. I'm writing an application that
> will end up using an output range (likely an appender, so
> semi-dynamic). How will I be sure that what's passed to other
> functions will append to the range? And more importantly, if I
> use save and then rewrite an earlier section (due to updated
> information) would that also be correct assuming memory didn't
> change on it? Can you give an example?
> 
> Currently my code goes something like this:
> 
> struct ... {
> innerType[] someInnerType;
> 
> void write(T)(T outputRange)
> if(isForwardRange!(T)){
> 
> auto firstBlock = outputRange.save;
> //write to outputRange, first output will be re-written
> writeFirstBlock(outputRange);
> 
> foreach(ref i; someInnerType) {
> i.write(outputRange);
> }
> 
> //updated information for first block
> writeFirstBlock(save);
> }
> }

I don't think that I really understand the question, but I'd be worried about 
intermixing save with operating on a range as an output range. It _should_ 
work, but save was designed with reading in mind, not writing. An output range 
doesn't have to have save or even front or popFront. All it needs is to work 
with put. Output ranges are a very different beast from input ranges, even if 
input ranges can be output ranges.

That being said, I'd expect that save would save the current state, and any 
writing to the original would not affect the saved range.

- Jonathan M Davis
August 28, 2012
Re: Forward Range(s)
On Monday, 27 August 2012 at 20:46:18 UTC, Jonathan M Davis wrote:
> I don't think that I really understand the question, but I'd be 
> worried about intermixing save with operating on a range as an 
> output range. It _should_ work, but save was designed with 
> reading in mind, not writing. An output range doesn't have to 
> have save or even front or popFront. All it needs is to work 
> with put. Output ranges are a very different beast from input 
> ranges, even if input ranges can be output ranges.
>
> That being said, I'd expect that save would save the current 
> state, and any writing to the original would not affect the 
> saved range.

 Well the first block actually holds size information and the 
information it holds is the old information, stuff may have been 
added or taken away, so hopefully not to have to do two passes (a 
dummy pass and then a real one) I was hoping save would save the 
location. If it doesn't reference the previous location using the 
current data then I'll need to figure something out.

 It's this that's been holding off one of my projects for a while 
as I'm not sure how to best approach it.
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home