Jump to page: 1 25  
Page
Thread overview
Array literals?
Jun 13, 2004
Antti Sykäri
Jun 13, 2004
The Dr ... who?
Jun 13, 2004
Walter
Jun 13, 2004
Derek
Jun 13, 2004
Matthew
Jun 13, 2004
Derek
Jun 13, 2004
Matthew
Jun 14, 2004
Derek
Jun 14, 2004
Walter
Jun 14, 2004
Russ Lewis
Jun 14, 2004
Matthew
Jun 14, 2004
Walter
Jun 14, 2004
Matthew
Jun 14, 2004
Russ Lewis
Jun 15, 2004
Stewart Gordon
Jun 14, 2004
Russ Lewis
Jun 14, 2004
Norbert Nemec
Jun 14, 2004
Antti Sykäri
Jul 12, 2004
Matthias Becker
Jul 12, 2004
C. Sauls
Jul 12, 2004
Russ Lewis
Jun 13, 2004
Matthew
Jun 13, 2004
Vathix
Jun 14, 2004
Regan Heath
Jun 14, 2004
Walter
Jun 14, 2004
Regan Heath
Jun 14, 2004
Walter
Jun 14, 2004
Matthew
Jun 14, 2004
Walter
Jun 14, 2004
Matthew
Jun 14, 2004
Regan Heath
Jun 14, 2004
Matthew
Jun 14, 2004
Regan Heath
Jun 14, 2004
Matthew
Jun 14, 2004
Regan Heath
Jun 14, 2004
Walter
Jun 15, 2004
Kevin Bealer
Jul 12, 2004
Matthias Becker
Jul 12, 2004
Vathix
Jun 14, 2004
Roberto Mariottini
Jul 12, 2004
Antti Sykäri
Jul 12, 2004
Matthias Becker
Jun 14, 2004
Sam McCall
Jun 14, 2004
Sam McCall
Jun 14, 2004
Ivan Senji
Jun 14, 2004
Derek
Jun 14, 2004
Ivan Senji
Jun 14, 2004
Derek
Jun 14, 2004
Stewart Gordon
June 13, 2004
Is there any way to create arrays easily, using array literals?

--- test.d ---

void f(int[3] a)
{
}

void g(int x)
{
    f([1, 2, 3]); // does not work

    // Does not work either: variable tmp is not static and cannot have
    // a static initializer
    int[3] tmp = [1, 2, 3];
    f(tmp);

    // Works
    const int[3] tmp2 = [1, 2, 3];
    f(tmp2);

    const int[3] tmp3 = [x, 2, 3];
    f(tmp3);
    // Doesn't work either: non-constant expression x

    // Consequently, I have to do this:
    const int[3] tmp4;
    tmp4[0] = x; tmp4[1] = 2; tmp4[2] = 3;
    f(tmp4);

    return 0;
}

-------------

I didn't find any mention of array literals in the documentation. Maybe they were hidden. In any case, I'd find them tremendously useful, even more useful than function literals although the basic idea is pretty much the same.

-Antti

-- 
I will not be using Plan 9 in the creation of weapons of mass destruction to be used by nations other than the US.
June 13, 2004
"Antti Sykäri" <jsykari@gamma.hut.fi> wrote in message news:slrnccp3am.hth.jsykari@pulu.hut.fi...
> Is there any way to create arrays easily, using array literals?
>
> --- test.d ---
>
> void f(int[3] a)
> {
> }
>
> void g(int x)
> {
>     f([1, 2, 3]); // does not work
>
>     // Does not work either: variable tmp is not static and cannot have
>     // a static initializer
>     int[3] tmp = [1, 2, 3];
>     f(tmp);
>
>     // Works
>     const int[3] tmp2 = [1, 2, 3];
>     f(tmp2);
>
>     const int[3] tmp3 = [x, 2, 3];
>     f(tmp3);
>     // Doesn't work either: non-constant expression x
>
>     // Consequently, I have to do this:
>     const int[3] tmp4;
>     tmp4[0] = x; tmp4[1] = 2; tmp4[2] = 3;
>     f(tmp4);
>
>     return 0;
> }
>
> -------------
>
> I didn't find any mention of array literals in the documentation. Maybe they were hidden. In any case, I'd find them tremendously useful, even more useful than function literals although the basic idea is pretty much the same.

Count my vote!


-- 
The Dr.

da-da-da-dum, da-da-da-dum, da-da-da-dum, daaah
da-da-da-dum, da-da-da-dum, da-da-da-dum, daaah
woo-ooooo


June 13, 2004
The fundamental problem with array literals is the bottom-up nature of the typing of expressions in the semantic phase of compilation. Is [0,1,2,3] an array of chars, bytes, ints, longs, floats, ... ?

This is not an easy problem to solve, which is why it'll be deferred to a 2.0 feature.


June 13, 2004
On Sun, 13 Jun 2004 15:35:04 -0700, Walter wrote:

> The fundamental problem with array literals is the bottom-up nature of the typing of expressions in the semantic phase of compilation. Is [0,1,2,3] an array of chars, bytes, ints, longs, floats, ... ?
> 
> This is not an easy problem to solve, which is why it'll be deferred to a 2.0 feature.

char[4] A = [0,1,2,3]; // chars
byte[4] A = [0,1,2,3]; // bytes
int[4] A = [0,1,2,3]; // ints
long[4] A = [0,1,2,3]; // longs
float[4] A = [0,1,2,3]; // floats

What don't I understand about this 'difficult problem'?

-- 
Derek
Melbourne, Australia
June 13, 2004
Why not require some kind of syntactic hint, as in:

    func([cast(int)0, 1, 2, 3]);

or
    func([int: 0, 1, 2, 3]);

or

    func((int[])[0, 1, 2, 3]);

or

    func(int[0, 1, 2, 3]);

?

"Walter" <newshound@digitalmars.com> wrote in message news:caikv2$1bsi$1@digitaldaemon.com...
> The fundamental problem with array literals is the bottom-up nature of the typing of expressions in the semantic phase of compilation. Is [0,1,2,3] an array of chars, bytes, ints, longs, floats, ... ?
>
> This is not an easy problem to solve, which is why it'll be deferred to a 2.0 feature.
>
>


June 13, 2004
"Derek" <derek@psyc.ward> wrote in message news:b5s688p7pf1y.z5e0b4ez9omj.dlg@40tude.net...
> On Sun, 13 Jun 2004 15:35:04 -0700, Walter wrote:
>
> > The fundamental problem with array literals is the bottom-up nature of the typing of expressions in the semantic phase of compilation. Is [0,1,2,3] an array of chars, bytes, ints, longs, floats, ... ?
> >
> > This is not an easy problem to solve, which is why it'll be deferred to a 2.0 feature.
>
> char[4] A = [0,1,2,3]; // chars
> byte[4] A = [0,1,2,3]; // bytes
> int[4] A = [0,1,2,3]; // ints
> long[4] A = [0,1,2,3]; // longs
> float[4] A = [0,1,2,3]; // floats
>
> What don't I understand about this 'difficult problem'?

An array literal is one that is defined in situ, and not a variable. All the above are normal arrays. An array literal would look like:

    void somefunc(int[] ar);

    int main()
    {
        int[]  na = . . . ; // A normal array

        somefunc(na);            // Passing the normal array

        somefunc([0, 1, 2, 3]);    // Passing an array literal, defined just
here!

        return 0;
    }

:)


June 13, 2004
>     func(int[0, 1, 2, 3]);

This one looks pretty cool.


June 13, 2004
On Mon, 14 Jun 2004 09:09:40 +1000, Matthew wrote:

> "Derek" <derek@psyc.ward> wrote in message news:b5s688p7pf1y.z5e0b4ez9omj.dlg@40tude.net...
>> On Sun, 13 Jun 2004 15:35:04 -0700, Walter wrote:
>>
>>> The fundamental problem with array literals is the bottom-up nature of the typing of expressions in the semantic phase of compilation. Is [0,1,2,3] an array of chars, bytes, ints, longs, floats, ... ?
>>>
>>> This is not an easy problem to solve, which is why it'll be deferred to a 2.0 feature.
>>
>> char[4] A = [0,1,2,3]; // chars
>> byte[4] A = [0,1,2,3]; // bytes
>> int[4] A = [0,1,2,3]; // ints
>> long[4] A = [0,1,2,3]; // longs
>> float[4] A = [0,1,2,3]; // floats
>>
>> What don't I understand about this 'difficult problem'?
> 
> An array literal is one that is defined in situ, and not a variable. All the above are normal arrays. An array literal would look like:
> 
>     void somefunc(int[] ar);
> 
>     int main()
>     {
>         int[]  na = . . . ; // A normal array
> 
>         somefunc(na);            // Passing the normal array
> 
>         somefunc([0, 1, 2, 3]);    // Passing an array literal, defined just
> here!
> 
>         return 0;
>     }
> 
> :)

Ok, I didn't make my self clear yet again.

In my examples, I was trying to demostrate that the compiler had enough information to work out what the array literals were meant to be. The info comes from the datatype the array literals was being assigned to.

In your example, the compiler still has enough info. If 'somefunc' requires that an 'int[]' be passed to it, then the array literal needs also to be one of ints.

As an array literal (or any literal for that matter) does not exist outside of some context, it should be able to determine its datatype *in* that context. We don't have problems with numeric literals.

  void anotherfunc(float a);
  . . .

  anotherfunc(4);  // '4' is a float, no?

-- 
Derek
Melbourne, Australia
June 13, 2004
"Derek" <derek@psyc.ward> wrote in message news:1ovbt2dsuadke.1hsc4hq8954kj$.dlg@40tude.net...
> On Mon, 14 Jun 2004 09:09:40 +1000, Matthew wrote:
>
> > "Derek" <derek@psyc.ward> wrote in message news:b5s688p7pf1y.z5e0b4ez9omj.dlg@40tude.net...
> >> On Sun, 13 Jun 2004 15:35:04 -0700, Walter wrote:
> >>
> >>> The fundamental problem with array literals is the bottom-up nature of the typing of expressions in the semantic phase of compilation. Is [0,1,2,3] an array of chars, bytes, ints, longs, floats, ... ?
> >>>
> >>> This is not an easy problem to solve, which is why it'll be deferred to a 2.0 feature.
> >>
> >> char[4] A = [0,1,2,3]; // chars
> >> byte[4] A = [0,1,2,3]; // bytes
> >> int[4] A = [0,1,2,3]; // ints
> >> long[4] A = [0,1,2,3]; // longs
> >> float[4] A = [0,1,2,3]; // floats
> >>
> >> What don't I understand about this 'difficult problem'?
> >
> > An array literal is one that is defined in situ, and not a variable. All the above are normal arrays. An array literal would look like:
> >
> >     void somefunc(int[] ar);
> >
> >     int main()
> >     {
> >         int[]  na = . . . ; // A normal array
> >
> >         somefunc(na);            // Passing the normal array
> >
> >         somefunc([0, 1, 2, 3]);    // Passing an array literal, defined just
> > here!
> >
> >         return 0;
> >     }
> >
> > :)
>
> Ok, I didn't make my self clear yet again.
>
> In my examples, I was trying to demostrate that the compiler had enough information to work out what the array literals were meant to be. The info comes from the datatype the array literals was being assigned to.
>
> In your example, the compiler still has enough info. If 'somefunc' requires that an 'int[]' be passed to it, then the array literal needs also to be one of ints.
>
> As an array literal (or any literal for that matter) does not exist outside of some context, it should be able to determine its datatype *in* that context. We don't have problems with numeric literals.
>
>   void anotherfunc(float a);
>   . . .
>
>   anotherfunc(4);  // '4' is a float, no?

Polymorphism and implicit conversions would scupper this, then, I think.


June 14, 2004
On Mon, 14 Jun 2004 09:43:06 +1000, Matthew wrote:

> "Derek" <derek@psyc.ward> wrote in message news:1ovbt2dsuadke.1hsc4hq8954kj$.dlg@40tude.net...
>> On Mon, 14 Jun 2004 09:09:40 +1000, Matthew wrote:
>>
>>> "Derek" <derek@psyc.ward> wrote in message news:b5s688p7pf1y.z5e0b4ez9omj.dlg@40tude.net...
>>>> On Sun, 13 Jun 2004 15:35:04 -0700, Walter wrote:
>>>>
>>>>> The fundamental problem with array literals is the bottom-up nature of the typing of expressions in the semantic phase of compilation. Is [0,1,2,3] an array of chars, bytes, ints, longs, floats, ... ?
>>>>>
>>>>> This is not an easy problem to solve, which is why it'll be deferred to a 2.0 feature.
>>>>
>>>> char[4] A = [0,1,2,3]; // chars
>>>> byte[4] A = [0,1,2,3]; // bytes
>>>> int[4] A = [0,1,2,3]; // ints
>>>> long[4] A = [0,1,2,3]; // longs
>>>> float[4] A = [0,1,2,3]; // floats
>>>>
>>>> What don't I understand about this 'difficult problem'?
>>>
>>> An array literal is one that is defined in situ, and not a variable. All the above are normal arrays. An array literal would look like:
>>>
>>>     void somefunc(int[] ar);
>>>
>>>     int main()
>>>     {
>>>         int[]  na = . . . ; // A normal array
>>>
>>>         somefunc(na);            // Passing the normal array
>>>
>>>         somefunc([0, 1, 2, 3]);    // Passing an array literal, defined just
>>> here!
>>>
>>>         return 0;
>>>     }
>>>
>>> :)
>>
>> Ok, I didn't make my self clear yet again.
>>
>> In my examples, I was trying to demostrate that the compiler had enough information to work out what the array literals were meant to be. The info comes from the datatype the array literals was being assigned to.
>>
>> In your example, the compiler still has enough info. If 'somefunc' requires that an 'int[]' be passed to it, then the array literal needs also to be one of ints.
>>
>> As an array literal (or any literal for that matter) does not exist outside of some context, it should be able to determine its datatype *in* that context. We don't have problems with numeric literals.
>>
>>   void anotherfunc(float a);
>>   . . .
>>
>>   anotherfunc(4);  // '4' is a float, no?
> 
> Polymorphism and implicit conversions would scupper this, then, I think.

Yep, that'd do it.

-- 
Derek
Melbourne, Australia
« First   ‹ Prev
1 2 3 4 5