www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Static initializers for dynamic arrays

reply Shammah Chancellor <Shammah_member pathlink.com> writes:
Why must we do this still:




Is there a reason why:

int[] foo = [1,2,3,4]; is disallowed? or is it just not working right yet?

Also on a side note:

I propose this syntax for AA initilizers:

int[char[]] foo = ["Sally":10, "George":5];
Jul 27 2005
next sibling parent MicroWizard <MicroWizard_member pathlink.com> writes:
In article <dc8tb6$mbg$1 digitaldaemon.com>, Shammah Chancellor says...

Why must we do this still:




Is there a reason why:

int[] foo = [1,2,3,4]; is disallowed? or is it just not working right yet?

Also on a side note:

I propose this syntax for AA initilizers:

int[char[]] foo = ["Sally":10, "George":5];


You're completely right. These things are already mentioned
but they are not implemented yet.

I hope Walter hears our prayers...

Tamas Nagy
Jul 28 2005
prev sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Shammah Chancellor <Shammah_member pathlink.com> wrote:

[...]

 Is there a reason why:
 int[] foo = [1,2,3,4];
 is disallowed?


[...]

To me there is a clear reason for this:

such a construct would hide the time and space requirements needed to 
execute this statement, because the compiler can do nothing else than 
generate code like

  static int[] __foo= [1,2,3,4];
  int[] foo= __foo;

Then the counter question is:
what are the benefits of hiding this requirements?

-manfred
Jul 28 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Thu, 28 Jul 2005 21:22:46 +0000 (UTC), Manfred Nowak wrote:


 Shammah Chancellor <Shammah_member pathlink.com> wrote:
 
 [...]

 Is there a reason why:
 int[] foo = [1,2,3,4];
 is disallowed?


 [...]
 
 To me there is a clear reason for this:
 
 such a construct would hide the time and space requirements needed to 
 execute this statement, because the compiler can do nothing else than 
 generate code like
 
   static int[] __foo= [1,2,3,4];
   int[] foo= __foo;
 
 Then the counter question is:
 what are the benefits of hiding this requirements?


I believe that depends on what the purpose of the compiler is. As I think
that the primary purpose of a compiler is to make creating, reading and
maintaining code easier for people, then idioms and constructs that
increase clarity assist in that primary goal. I would say that ...

  int[] foo = [1,2,3,4];

is clearer and more cost effective from a human point of view than ...

  static int[] __foo = [1,2,3,4];
  int[] foo = __foo;

Another reason to have this construct is to increase consistency in the
syntax. Already we can do ...

  char[] foo = "qwerty";

rather than having to do ...

  static char[] __foo = "qwerty";
  char[] foo = __foo;

so why not extend this idiom to dynamic arrays of types other than
character?

The compiler already hides the implementation details of other constructs
for us, so this would not break any embargo on that concept.

-- 
Derek Parnell
Melbourne, Australia
29/07/2005 7:37:28 AM
Jul 28 2005
parent Manfred Nowak <svv1999 hotmail.com> writes:
Derek Parnell <derek psych.ward> wrote:

[...]

 Another reason to have this construct is to increase consistency
 in the syntax.


[...]

Agreed.

-manfred
Jul 28 2005
prev sibling parent reply Shammah Chancellor <Shammah_member pathlink.com> writes:
In article <dcbib6$2ud3$1 digitaldaemon.com>, Manfred Nowak says...

Shammah Chancellor <Shammah_member pathlink.com> wrote:

[...]

 Is there a reason why:
 int[] foo = [1,2,3,4];
 is disallowed?


[...]

To me there is a clear reason for this:

such a construct would hide the time and space requirements needed to 
execute this statement, because the compiler can do nothing else than 
generate code like

  static int[] __foo= [1,2,3,4];
  int[] foo= __foo;

Then the counter question is:
what are the benefits of hiding this requirements?

-manfred 


I might ask you the opposite.  Is some benefit to munging up my code and making
me type more when what I want to do is inavoidable regardless of time and space
requirements.  If for some reason I _want_ a named static for it,  I can still
do exactly what you have there.
Jul 28 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Shammah Chancellor <Shammah_member pathlink.com> wrote:

[...]

 Is some benefit to munging up my
 code and making me type more when what I want to do


I understand your purpose and assist it by suggesting a new keyword:

FlyThisPlaneIntoTheWTC

because I am also not interested in typing more than I need to. And 
because I am at it I suggest to make D a real easy language to 
program in: throw away my suggestion above, because I really really 
do not want to type more than I need:

SolveMyProblem

is the only thing I want to type. Then D should solve it. 

-manfred
Jul 28 2005
next sibling parent reply Shammah Chancellor <Shammah_member pathlink.com> writes:
Thank you for taking my quote out of context and replying to it sarcastically.
However, That doesn't 
change the fact that C, C++, and every other language allows static assignments
to dynamic arrays.  
This should give you some hint as to what other people think.  If you want your
language to be obtuse 
for the sake of performance, feel free to use assembly.

I do however think there is a nice balance that a language needs to maintain
between programmer 
exposure to implementation details and ease of use.  Some pretty stupid things
can happen 
performance wise when people don't know that a one line function call actually
does a very complex 
operation for them.  However, static initializers on dynamic arrays is not one
of these things.

-Sha

In article <dcbtcj$8q3$1 digitaldaemon.com>, Manfred Nowak says...

Shammah Chancellor <Shammah_member pathlink.com> wrote:

[...]

 Is some benefit to munging up my
 code and making me type more when what I want to do


I understand your purpose and assist it by suggesting a new keyword:

FlyThisPlaneIntoTheWTC

because I am also not interested in typing more than I need to. And 
because I am at it I suggest to make D a real easy language to 
program in: throw away my suggestion above, because I really really 
do not want to type more than I need:

SolveMyProblem

is the only thing I want to type. Then D should solve it. 

-manfred
Jul 28 2005
parent Manfred Nowak <svv1999 hotmail.com> writes:
Shammah Chancellor <Shammah_member pathlink.com> wrote:

[...]

 I do however think there is a nice balance that a language needs
 to maintain between programmer exposure to implementation
 details and ease of use.


[...]

Agreed. And to assure you of nonsarcasm: as Derek showed up with a 
consistency argument I assist your demand, because

  foo= __foo;

is already hiding time complexity.

-manfred
Jul 28 2005
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Manfred Nowak wrote:
<snip>

 because I am also not interested in typing more than I need to. And 
 because I am at it I suggest to make D a real easy language to 
 program in: throw away my suggestion above, because I really really 
 do not want to type more than I need:
 
 SolveMyProblem


Maybe in some future version, the D inline assembler could add RPM to 
its repertoire of supported opcodes.  :-)

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- a->--- UB  P+ L E  W++  N+++ o K- w++  O? M V? PS- PE- Y? 
PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
Aug 23 2005