On 12/22/20 10:53 AM, Rekel wrote:> On Tuesday, 22 December 2020 at
16:56:18 UTC, Ali Çehreli wrote:
>> >[4]Foo b; /* an array of four Foos */
>>
>> [4] already has a meaning. ;)
>
> It does in that context? Do tell, I'm unaware.
An array literal with a single int element 4:
pragma(msg,
On Tuesday, 22 December 2020 at 16:55:40 UTC, Mike Parker wrote:
On Tuesday, 22 December 2020 at 15:31:06 UTC, Rekel wrote:
Don't take that as a defence of changing pointer syntax by the
way, just noting I think the argument pointers and arrays
should be defined using a similar syntax is
On Tuesday, 22 December 2020 at 16:56:18 UTC, Ali Çehreli wrote:
>[4]Foo b; /* an array of four Foos */
[4] already has a meaning. ;)
It does in that context? Do tell, I'm unaware.
Also, is it possible to move entire thread to a different forum
group?
This feels more like a
On Tuesday, 22 December 2020 at 16:56:18 UTC, Ali Çehreli wrote:
On 12/22/20 6:35 AM, ag0aep6g wrote:
> Flip the pointer syntax, too:
>
> *Foo a; /* a pointer to a Foo */
I am not a language expert but I think that would make D's
parsing complicated (like C++'s < token) because * already
On 12/22/20 8:56 AM, Ali Çehreli wrote:
> * already means "derefence"
"dereference"
> > But now we're no longer C-like, I guess.x
That x seems to be due to my fat Emacs fingers.
Ali
On 12/22/20 6:35 AM, ag0aep6g wrote:
> Flip the pointer syntax, too:
>
> *Foo a; /* a pointer to a Foo */
I am not a language expert but I think that would make D's parsing
complicated (like C++'s < token) because * already means "derefence" in
that position. So, the parser would see
On Tuesday, 22 December 2020 at 15:31:06 UTC, Rekel wrote:
Don't take that as a defence of changing pointer syntax by the
way, just noting I think the argument pointers and arrays
should be defined using a similar syntax is not consistent when
thinking about indexing & dereferencing.
On Tuesday, 22 December 2020 at 15:24:04 UTC, Rekel wrote:
The way C syntax handles pointers isn't very consistent to
begin with imo.
It's strange & and * are prepended to pointer variables for
example, while indexing is postpended. Leads to stuff like;
(*array_of_pointers_to_arrays[2])[1]
vs
On Tuesday, 22 December 2020 at 14:15:12 UTC, Mike Parker wrote:
[][4]Foo is completely backwards from and inconsistent with the
pointer declaration syntax. We shouldn't want to intentionally
introduce inconsistencies.
The way C syntax handles pointers isn't very consistent to begin
with
On 22.12.20 15:15, Mike Parker wrote:
On Tuesday, 22 December 2020 at 13:59:54 UTC, Rekel wrote:
I am curious by the way, what do you think of the [][4]Row suggestion
I gave? In a way you'd have your & could eat it too, i think ^^
(Still a strange saying to me)
Currently, D's variable
On Tuesday, 22 December 2020 at 13:59:54 UTC, Rekel wrote:
I am curious by the way, what do you think of the [][4]Row
suggestion I gave? In a way you'd have your & could eat it
too, i think ^^
(Still a strange saying to me)
Currently, D's variable declaration syntax is consistent and,
On Tuesday, 22 December 2020 at 07:19:49 UTC, Ali Çehreli wrote:
Let me try the history example:
Row[4][] history;
Row array (of 4) array.
Fully disagreed: D's array syntax makes me happy; designed
right. :)
I think i see your point, strange how a change of words makes
some things
On 12/21/20 8:47 PM, Rekel wrote:
> On Monday, 30 January 2017 at 07:33:34 UTC, Ali Çehreli wrote:
>> As others have said, D's array definition is natural because unlike
>> C's inside-out (or is that outside-in?) syntax, it follows from the
>> alias syntax. Replacing History inside main with
On Tue, Dec 22, 2020 at 04:47:13AM +, Rekel via Digitalmars-d-learn wrote:
[...]
> Defending array-notation by giving an example of explicitly not using
> declared aliases makes no sense to me.
> When I define 2d arrays, or index them, I think in row -> column terms
> (often math notation for
Small addition, not out of jest;
If plug and play consistency given aliases is required (which
seems pointless, as they exit to be used), the best solution,
which would avoid indexing inconsistency given regular reading
order, would be the following;
alias Row = [3]int;
[1][2][3]int history;
On Monday, 30 January 2017 at 07:33:34 UTC, Ali Çehreli wrote:
As others have said, D's array definition is natural because
unlike C's inside-out (or is that outside-in?) syntax, it
follows from the alias syntax. Replacing History inside main
with Matrix[], etc.:
History history;//
On 01/25/2017 05:47 PM, Profile Anaysis wrote:
> a 4x4 matrix and have a history of it. Just
> n 4x4 matrices but each matrix is a fixed size but there can be an
> arbitrary(dynamic) number.
I don't think using aliases is recommended yet. It can simplify things a
lot:
import std.stdio;
On Thursday, 26 January 2017 at 05:20:07 UTC, Profile Anaysis
wrote:
(On the contrary, declarations in C or C++ looks rather
unintuitive from this perspective: `T a[4][5][6]` is means
that `a` is an array of 4 arrays of 5 arrays of 6 arrays of
`T`. Note how we have to read left-to-right but
On Thursday, January 26, 2017 05:44:04 Profile Anaysis via Digitalmars-d-
learn wrote:
> I am using static arrays because the size of the matrix is fixed.
> I need to allocate them though because that is what my
> matrix_history contains.
If I understood correctly, you want a dynamic array of
Sorry. I mistyped some of my examples. Obviously dropped some
news:
auto a = new int[](4);
auto b = new int[][](4);
And the static arrays should be:
int[4] c;
int[][4] d;
And I would also like managed to overlook there is no static
array in sight here:
auto y = new int[1][2][][](3,4);
The
On Thursday, 26 January 2017 at 05:50:03 UTC, Profile Anaysis
wrote:
It is inconsistent with dynamic arrays and mixing them creates
a mess in the order of indices.
I best someone was asleep at the wheel when programming the
code for static arrays. (probably someone different than who
On Thursday, 26 January 2017 at 03:02:32 UTC, Jonathan M Davis
wrote:
On Thursday, January 26, 2017 01:47:53 Profile Anaysis via
Digitalmars-d- learn wrote:
[...]
Like in C/C++, types are mostly read outward from the variable
name in D. In both C/C++ and D,
[...]
Actually, I think
On Thursday, 26 January 2017 at 03:02:32 UTC, Jonathan M Davis
wrote:
On Thursday, January 26, 2017 01:47:53 Profile Anaysis via
Digitalmars-d- learn wrote:
[...]
Like in C/C++, types are mostly read outward from the variable
name in D. In both C/C++ and D,
[...]
Thanks. I'll just
On Thursday, 26 January 2017 at 02:29:07 UTC, Ivan Kazmenko wrote:
On Thursday, 26 January 2017 at 01:47:53 UTC, Profile Anaysis
wrote:
does this mean that have
int[][4][4] matrix_history;
backwards?
int[4][4][] matrix_history;
this creates even a more set of problems.
In short,
On Thursday, January 26, 2017 01:47:53 Profile Anaysis via Digitalmars-d-
learn wrote:
> I'm a bit confused by how D does arrays.
>
> I would like to create a array of matrices but I do not seem to
> get the correct behavior:
>
> int[][4][4] matrix_history;
Like in C/C++, types are mostly
On Thursday, 26 January 2017 at 01:47:53 UTC, Profile Anaysis
wrote:
does this mean that have
int[][4][4] matrix_history;
backwards?
int[4][4][] matrix_history;
this creates even a more set of problems.
In short, you are right, `int[4][4][]` is a dynamic array of
`int[4][4]`. In
I'm a bit confused by how D does arrays.
I would like to create a array of matrices but I do not seem to
get the correct behavior:
int[][4][4] matrix_history;
What I would like is to have a 4x4 matrix and have a history of
it. Just n 4x4 matrices but each matrix is a fixed size but
27 matches
Mail list logo
