Wrapup: I am going to go for the original approach of index
conversion, and leaving the offset-pointer approach for what it
is.
Reasons:
1) uncertain efficiency gain/loss,
2) theoretically it may fail,
3) .sizeof does not include the payload,
4) analysis of the assembler generated by our
On 02/07/2017 02:04 PM, Bastiaan Veelo wrote:
>> This optimization cannot work if the array is a static array inside
>> the same struct. It would work with a dynamic array but then it would
>> probably be slower than applying the *(ptr+index) technique.
>
> You mean slower than the
On Tuesday, 7 February 2017 at 20:33:35 UTC, Ali Çehreli wrote:
On 02/07/2017 02:11 AM, Bastiaan Veelo wrote:
> We do not need to take measures against the GC?
Of course we have to and the struct that I wrote is illegal
because it is self-referencing through the _ptr member. (D has
the right
On Tuesday, 7 February 2017 at 20:28:30 UTC, Ali Çehreli wrote:
You forgot to call that most important function. ;)
Hah of course. I assumed the name would give it some special
meaning, like postblit.
1) I don't understand the first assert there, which does not
pass for me, so I commented
Pressed send too soon, before considering your GC question.
On 02/07/2017 02:11 AM, Bastiaan Veelo wrote:
> We do not need to take measures against the GC?
Of course we have to and the struct that I wrote is illegal because it
is self-referencing through the _ptr member. (D has the right to
On 02/07/2017 02:11 AM, Bastiaan Veelo wrote:
> void init() {
> assert( first < cast(size_t)_payload.ptr); //
> Address space underrun.
> assert(-first < size_t.max - cast(size_t)_payload.ptr); //
> Address space overrun.
> this._ptr = _payload.ptr -
On Monday, 6 February 2017 at 23:42:55 UTC, Ali Çehreli wrote:
Then you use _ptr when indexing:
// Support e = arr[5];
ref T opIndex(ptrdiff_t index) {
assert(index >= first);
assert(index <= last);
return *(_ptr + index);
}
Ali
Thank you very much for
On Saturday, 1 August 2015 at 09:35:53 UTC, DLearner wrote:
Does the D language set in stone that the first element of an
array _has_ to be index zero?
Wouldn't starting array elements at one avoid the common
'off-by-one' logic error, it does
seem more natural to begin a count at 1.
Actually,
On Monday, 6 February 2017 at 18:55:19 UTC, pineapple wrote:
One reason for zero-based indexes that isn't "it's what we're
all used to" is that if you used one-based indexes, you would
be able to represent one fewer index than zero-based, since one
of the representable values - zero - could no
On 02/06/2017 03:00 PM, Bastiaan Veelo wrote:
> In "Numerical Recipes in C", section 1.2, Press et al. propose an easy
> solution using an offset pointer:
>
> float b[4], *bb;
> bb = b - 1;
>
> Thus bb[1] through bb[4] all exist, no space is wasted nor is there a
> run-time overhead.
>
> I have
(There is an honest question in the end, please read on.)
All good reasons set aside, both in favour and against 0-based
arrays, the only reason that is relevant to me right now is that
we are seriously looking into translating close to a million
lines of foreign code to D, from a language
On Monday, 6 February 2017 at 18:55:19 UTC, pineapple wrote:
One reason for zero-based indexes that isn't "it's what we're
all used to" is that if you used one-based indexes, you would
be able to represent one fewer index than zero-based, since one
of the representable values - zero - could no
One reason for zero-based indexes that isn't "it's what we're all
used to" is that if you used one-based indexes, you would be able
to represent one fewer index than zero-based, since one of the
representable values - zero - could no longer be used to
represent any index.
Also, it's what
On Monday, 6 February 2017 at 14:26:35 UTC, Bastiaan Veelo wrote:
The unit test didn't detect this because it was ambiguous.
Sorry for that misinformation. I should have said that
opIndexAssign wasn't tested. Here is a better test.
unittest {
OneBasedArray!int arr;
arr =
On Tuesday, 4 August 2015 at 08:18:50 UTC, Marc Schütz wrote:
void opIndexAssign(U : T)(size_t index, auto ref U
value) {
Careful here, you've got the arguments reversed. The unit test
didn't detect this because it was ambiguous. This one isn't:
unittest {
On Monday, 3 August 2015 at 21:32:05 UTC, DLearner wrote:
Looks like 0-base is fixed, to avoid problems with existing
code.
But nothing stops _adding_ to the language by allowing
int[x:y] foo to mean valid symbols are foo[x], foo[x+1],...,
foo[y].
Plus rule that int[:y] means valid symbols
On Saturday, 1 August 2015 at 09:35:53 UTC, DLearner wrote:
Does the D language set in stone that the first element of an
array _has_ to be index zero?
Wouldn't starting array elements at one avoid the common
'off-by-one' logic error, it does
seem more natural to begin a count at 1.
I, too,
On Monday, August 03, 2015 21:32:03 DLearner via Digitalmars-d-learn wrote:
On Monday, 3 August 2015 at 13:45:01 UTC, bachmeier wrote:
On Sunday, 2 August 2015 at 21:58:48 UTC, QAston wrote:
Adding 1-indexed arrays to the language fixes nothing. Just
write your 1-indexed array type and if
On Monday, 3 August 2015 at 13:45:01 UTC, bachmeier wrote:
On Sunday, 2 August 2015 at 21:58:48 UTC, QAston wrote:
Adding 1-indexed arrays to the language fixes nothing. Just
write your 1-indexed array type and if you enjoy using it,
publish it as a library. Who knows, if demand is high it
On Saturday, 1 August 2015 at 09:35:53 UTC, DLearner wrote:
Does the D language set in stone that the first element of an
array _has_ to be index zero?
Wouldn't starting array elements at one avoid the common
'off-by-one' logic error, it does
seem more natural to begin a count at 1.
Actually,
On Sunday, 2 August 2015 at 21:58:48 UTC, QAston wrote:
Adding 1-indexed arrays to the language fixes nothing. Just
write your 1-indexed array type and if you enjoy using it,
publish it as a library. Who knows, if demand is high it may
even end up in phobos.
Oh, I don't think that's a good
On Saturday, 1 August 2015 at 09:35:53 UTC, DLearner wrote:
Does the D language set in stone that the first element of an
array _has_ to be index zero?
Wouldn't starting array elements at one avoid the common
'off-by-one' logic error, it does
seem more natural to begin a count at 1.
Actually,
On Saturday, 1 August 2015 at 23:02:51 UTC, bachmeier wrote:
But what type of programming are you doing? Even after decades
of programming and trying out dozens of languages, zero-based
indexing still gets me at times when the arrays I work with
represent vectors and matrices. Especially when
On Saturday, 1 August 2015 at 09:35:53 UTC, DLearner wrote:
Does the D language set in stone that the first element of an
array _has_ to be index zero?
For the builtin slice types? Yes, set in stone.
Wouldn't starting array elements at one avoid the common
'off-by-one' logic error, it does
On Saturday, 1 August 2015 at 09:35:53 UTC, DLearner wrote:
Does the D language set in stone that the first element of an
array _has_ to be index zero?
Wouldn't starting array elements at one avoid the common
'off-by-one' logic error, it does
seem more natural to begin a count at 1.
Actually,
On Saturday, 1 August 2015 at 17:55:06 UTC, John Colvin wrote:
On Saturday, 1 August 2015 at 09:35:53 UTC, DLearner wrote:
Does the D language set in stone that the first element of an
array _has_ to be index zero?
For the builtin slice types? Yes, set in stone.
Wouldn't starting array
On 8/1/15, DLearner via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
D is a C derivative, so it seems a shame not to identify causes
of bugs in C,
and design them out in D.
This has already been done! D defines an array to be a struct with a
pointer and a length. See this
On Saturday, 1 August 2015 at 19:04:10 UTC, Andrej Mitrovic wrote:
On 8/1/15, DLearner via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
D is a C derivative, so it seems a shame not to identify causes
of bugs in C,
and design them out in D.
This has already been done! D defines
On 1/08/2015 9:35 p.m., DLearner wrote:
Does the D language set in stone that the first element of an array
_has_ to be index zero?
Wouldn't starting array elements at one avoid the common 'off-by-one'
logic error, it does
seem more natural to begin a count at 1.
Actually, maybe even better to
29 matches
Mail list logo
