On 04/10/2013 01:18 AM, Steven Schveighoffer wrote:
> Calling front after empty is not good range policy, once empty, front is
> possibly invalid or points at invalid memory.
It's not necessarily required to actually call front with the range empty: one
could do something like,
for(; !sim
On 04/10/2013 08:22 PM, Jesse Phillips wrote:
> I'm pretty sure he realizes this, his original code shows how he is doing
> this.
> He expects 'output' to hold the final front value, but instead it holds the
> empty "value."
>
> Joseph, I think you will have to profile to decide which is the fast
On Tuesday, 9 April 2013 at 23:18:26 UTC, Steven Schveighoffer
wrote:
On Tue, 09 Apr 2013 18:53:56 -0400, Joseph Rushton Wakeling
wrote:
By the way: the reason that I rejected the temporary-variable
choice was that I
couldn't really see the difference cost-wise between doing
that, versus
retur
On Tue, Apr 09, 2013 at 09:59:42PM -0400, Steven Schveighoffer wrote:
> On Tue, 09 Apr 2013 19:31:59 -0400, H. S. Teoh
> wrote:
>
> >On Tue, Apr 09, 2013 at 07:18:25PM -0400, Steven Schveighoffer wrote:
> >>On Tue, 09 Apr 2013 18:53:56 -0400, Joseph Rushton Wakeling
> >> wrote:
> >>
> >>>On 04/10
On Tue, 09 Apr 2013 19:31:59 -0400, H. S. Teoh
wrote:
On Tue, Apr 09, 2013 at 07:18:25PM -0400, Steven Schveighoffer wrote:
On Tue, 09 Apr 2013 18:53:56 -0400, Joseph Rushton Wakeling
wrote:
>On 04/10/2013 12:50 AM, Joseph Rushton Wakeling wrote:
>>I did consider something like that.
>
>By
On Tue, Apr 09, 2013 at 07:18:25PM -0400, Steven Schveighoffer wrote:
> On Tue, 09 Apr 2013 18:53:56 -0400, Joseph Rushton Wakeling
> wrote:
>
> >On 04/10/2013 12:50 AM, Joseph Rushton Wakeling wrote:
> >>I did consider something like that.
> >
> >By the way: the reason that I rejected the tempor
On Tue, 09 Apr 2013 18:53:56 -0400, Joseph Rushton Wakeling
wrote:
On 04/10/2013 12:50 AM, Joseph Rushton Wakeling wrote:
I did consider something like that.
By the way: the reason that I rejected the temporary-variable choice was
that I
couldn't really see the difference cost-wise betw
On 04/10/2013 12:50 AM, Joseph Rushton Wakeling wrote:
> I did consider something like that.
By the way: the reason that I rejected the temporary-variable choice was that I
couldn't really see the difference cost-wise between doing that, versus
returning var.dup from front(). Especially as it's n
On 04/10/2013 12:33 AM, Steven Schveighoffer wrote:
> Well here is another solution
I did consider something like that. The actual one I have come to after
thinking about it is like this:
struct MySimulation(T)
{
T[] var;
T diff = T.max;
T convergence;
_bool empty
On Tue, 09 Apr 2013 18:09:07 -0400, Joseph Rushton Wakeling
wrote:
On 04/09/2013 11:02 PM, Steven Schveighoffer wrote:
3. For your specific situation, add lastFront():
It's an interesting thought. I don't think it's ultimately the right
way to go
-- yes, my application rests strongly
On 04/09/2013 11:02 PM, Steven Schveighoffer wrote:
> 1. documentation. Make sure the user of the range knows that this data is
> going
> to be re-used.
In this case it's quite unlikely anyone will ever want to use the code apart
from me, but yes, good point. :-)
> 2. Make front() return const
On 04/09/2013 10:37 PM, H. S. Teoh wrote:
> Congratulations! You've created your first transient range. :)
:-)
Well, the problem isn't transience per se. It's acceptable that popFront()
overwrite previous returned values -- the problem is strictly that in deciding
that the range is empty, the 'l
On Tue, 09 Apr 2013 16:03:01 -0400, Joseph Rushton Wakeling
wrote:
Any thoughts? :-)
1. documentation. Make sure the user of the range knows that this data is
going to be re-used.
2. Make front() return const if possible. It is another signal that you
aren't supposed to keep this dat
Ali Çehreli:
Your problem is the exact situation that stdio.ByLine has
faced. There, the choice has been to use an internal buffer
just like your 'var' and leave the .dup call to the user for
when it is needed.
That choice is faster but sometimes causes bugs.
In similar situations I add a
On Tue, Apr 09, 2013 at 01:37:19PM -0700, H. S. Teoh wrote:
[...]
> Some time ago on the main D mailing list, somebody (deadalnix?)
> suggested extending the range interface to have a .transient function
> that returns a transient version of the range. The idea goes something
> like this:
[...]
P.
On Tue, Apr 09, 2013 at 10:03:01PM +0200, Joseph Rushton Wakeling wrote:
> Hello all,
>
> I have a situation in a program I'm writing where it's convenient to
> define a range whose return value is an array. Something like:
Congratulations! You've created your first transient range. :)
[...]
>
On 04/09/2013 01:03 PM, Joseph Rushton Wakeling wrote:
> to return var.dup rather than var from front(), but this is
> undesirable because it will hit performance in a big way.
Your problem is the exact situation that stdio.ByLine has faced. There,
the choice has been to use an internal buffer
Hello all,
I have a situation in a program I'm writing where it's convenient to define a
range whose return value is an array. Something like:
struct MySimulation(T)
{
T[] var;
T diff, convergence;
auto front() @property
{
return var;
}
18 matches
Mail list logo
