www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - appending newly initialized struct to array

reply maarten van damme <maartenvd1994 gmail.com> writes:
Just for fun I decided to complete some codejam challenges in D. At some
point I wanted to add structs to an array but I got a compiler error. What
am I doing wrong?

code:
struct test{
int x;
int y;
}
void main(){
test[] why;
why~={3,5};
}

error:
wait.d(7): found '}' when expecting ';' following statement
wait.d(8): found 'EOF' when expecting ';' following statement
wait.d(8): found 'EOF' when expecting '}' following compound statement

Is there any reason a why this wouldn't work?
Apr 17 2012
parent reply simendsjo <simendsjo gmail.com> writes:
On Tue, 17 Apr 2012 22:28:31 +0200, maarten van damme  
<maartenvd1994 gmail.com> wrote:


 Just for fun I decided to complete some codejam challenges in D. At some
 point I wanted to add structs to an array but I got a compiler error.  
 What
 am I doing wrong?

 code:
 struct test{
 int x;
 int y;
 }
 void main(){
 test[] why;
 why~={3,5};
 }

 error:
 wait.d(7): found '}' when expecting ';' following statement
 wait.d(8): found 'EOF' when expecting ';' following statement
 wait.d(8): found 'EOF' when expecting '}' following compound statement

 Is there any reason a why this wouldn't work?


Sounds like a bug. C style initializers work in other cases:

struct S { int i; }
void main() {
     S[] arr;
     S s = { 1 };
     arr ~= S(1);
     // But the following barfs
     //arr ~= { 1 };
     //arr ~= { i:1 };
     //arr[0] = { 1 };
}
Apr 17 2012
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
simendsjo:


 Sounds like a bug. C style initializers work in other cases:


D language is so much irregular, so many special cases that don't 
work :-)

Bye,
bearophile
Apr 17 2012
prev sibling next sibling parent "Kenji Hara" <k.hara.pg gmail.com> writes:
On Tuesday, 17 April 2012 at 21:00:55 UTC, simendsjo wrote:

 On Tue, 17 Apr 2012 22:28:31 +0200, maarten van damme 
 <maartenvd1994 gmail.com> wrote:


 Just for fun I decided to complete some codejam challenges in 
 D. At some
 point I wanted to add structs to an array but I got a compiler 
 error. What
 am I doing wrong?

 code:
 struct test{
 int x;
 int y;
 }
 void main(){
 test[] why;
 why~={3,5};
 }

 error:
 wait.d(7): found '}' when expecting ';' following statement
 wait.d(8): found 'EOF' when expecting ';' following statement
 wait.d(8): found 'EOF' when expecting '}' following compound 
 statement

 Is there any reason a why this wouldn't work?


 Sounds like a bug. C style initializers work in other cases:

 struct S { int i; }
 void main() {
     S[] arr;
     S s = { 1 };
     arr ~= S(1);
     // But the following barfs
     //arr ~= { 1 };
     //arr ~= { i:1 };
     //arr[0] = { 1 };
 }


No, it is designed. {3,5} is struct initializer:
http://dlang.org/declaration.html#StructInitializer
And it is only allowed in initializer of variable declarations.


 why~={3,5};


This is concat assign expression, so you should use test(3,5)
instead of {3,5}. That is StructLiteral:
http://dlang.org/struct.html#StructLiteral
and it is an expression.

Bye.

Kenji Hara
Apr 17 2012
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 04/17/2012 02:00 PM, simendsjo wrote:


 Sounds like a bug. C style initializers work in other cases:


I try not to use them. I think they have this 'feature' of leaving 
unspecified members uninitialized:

struct S
{
     int i;
     double d;
}

void main()
{
     S s = { 42 };               // <-- no initializer for S.d
     assert(s.i == 42);
     assert(s.d == double.nan);  // <-- fails (may work for you)
}

Is that a bug or a feature? I might have opened it but I don't remember 
now. :)

Ali
Apr 17 2012
parent reply "Kenji Hara" <k.hara.pg gmail.com> writes:
On Wednesday, 18 April 2012 at 04:55:23 UTC, Ali Çehreli wrote:

 On 04/17/2012 02:00 PM, simendsjo wrote:


 Sounds like a bug. C style initializers work in other cases:


 I try not to use them. I think they have this 'feature' of 
 leaving unspecified members uninitialized:

 struct S
 {
     int i;
     double d;
 }

 void main()
 {
     S s = { 42 };               // <-- no initializer for S.d
     assert(s.i == 42);
     assert(s.d == double.nan);  // <-- fails (may work for you)


You should use std.math.isNaN whether a floating point value is 
NaN.

       assert(isNaN(s.d));  // <-- success


 }

 Is that a bug or a feature? I might have opened it but I don't 
 remember now. :)

 Ali


Bye.

Kenji Hara
Apr 18 2012
next sibling parent reply maarten van damme <maartenvd1994 gmail.com> writes:
That's a very odd design. Making it work when instantiating a new struct of
that type but not inline. Anyway, test(3,5) works perfect, thank you.
Apr 18 2012
parent Somedude <lovelydear mailmetrash.com> writes:
Le 18/04/2012 12:41, maarten van damme a écrit :

 That's a very odd design. Making it work when instantiating a new struct
 of that type but not inline. Anyway, test(3,5) works perfect, thank you.


It's not odd at all. You append a structure, not an array.
{3,5} is for array initialization, it's the same syntax as in C, C++,


What if you want to append an array of structures ?

    why~=[test(3,5), test(3,6)];
Apr 18 2012
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 04/18/2012 12:16 AM, Kenji Hara wrote:

 On Wednesday, 18 April 2012 at 04:55:23 UTC, Ali Çehreli wrote:



 assert(s.d == double.nan); // <-- fails (may work for you)


 You should use std.math.isNaN whether a floating point value is NaN.

 assert(isNaN(s.d)); // <-- success


That a thousandth time I have made that mistake and still have not 
learned. :( Yes, .nan may not be compared with any other value, 
including .nan.

Ali
Apr 18 2012
parent reply bearophile <bearophileHUGS lycos.com> writes:
Ali: 

 That a thousandth time I have made that mistake and still have not 
 learned. :( Yes, .nan may not be compared with any other value, 
 including .nan.


Today I'll present an enhancement request to remove this problem from D.

Hugs,
bearophile
Apr 18 2012
parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Wednesday, 18 April 2012 at 16:36:39 UTC, bearophile wrote:

 Ali:

 That a thousandth time I have made that mistake and still have 
 not learned. :( Yes, .nan may not be compared with any other 
 value, including .nan.


 Today I'll present an enhancement request to remove this 
 problem from D.

 Hugs,
 bearophile


I don't see how this could be enhanced.
Apr 18 2012
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, April 18, 2012 19:04:12 SomeDude wrote:

 On Wednesday, 18 April 2012 at 16:36:39 UTC, bearophile wrote:

 Ali:

 That a thousandth time I have made that mistake and still have
 not learned. :( Yes, .nan may not be compared with any other
 value, including .nan.


 
 Today I'll present an enhancement request to remove this
 problem from D.
 
 Hugs,
 bearophile


 
 I don't see how this could be enhanced.


It's by design. An enhancement request is a waste of time. Comparisons with 
NaN _always_ return false regardless of what they're compared against - even 
NaN. It's not going to change.

- Jonathan M Davis
Apr 18 2012
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 04/18/2012 10:13 AM, Jonathan M Davis wrote:

 On Wednesday, April 18, 2012 19:04:12 SomeDude wrote:

 On Wednesday, 18 April 2012 at 16:36:39 UTC, bearophile wrote:

 Ali:

 That a thousandth time I have made that mistake and still have
 not learned. :( Yes, .nan may not be compared with any other
 value, including .nan.


 Today I'll present an enhancement request to remove this
 problem from D.

 Hugs,
 bearophile


 I don't see how this could be enhanced.


 It's by design. An enhancement request is a waste of time. 


Comparisons with

 NaN _always_ return false regardless of what they're compared against 


- even

 NaN. It's not going to change.

 - Jonathan M Davis


It shouldn't be a problem to detect comparisons against literal .nan 
values. The compiler can warn with "comparison is always false".

Ali
Apr 18 2012
next sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Wednesday, 18 April 2012 at 18:18:44 UTC, Ali Çehreli wrote:

 On 04/18/2012 10:13 AM, Jonathan M Davis wrote:

 It's by design. An enhancement request is a waste of time.


 Comparisons with

 NaN _always_ return false regardless of what they're compared


 against - even

 NaN. It's not going to change.

 - Jonathan M Davis


 It shouldn't be a problem to detect comparisons against literal 
 .nan values. The compiler can warn with "comparison is always 
 false".

 Ali


Now THAT makes sense.
Apr 18 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Apr 18, 2012 at 08:50:10PM +0200, SomeDude wrote:

 On Wednesday, 18 April 2012 at 18:18:44 UTC, Ali Çehreli wrote:

On 04/18/2012 10:13 AM, Jonathan M Davis wrote:

 It's by design. An enhancement request is a waste of time.
 Comparisons with NaN _always_ return false regardless of what
 they're compared against - even NaN. It's not going to change.

 - Jonathan M Davis


It shouldn't be a problem to detect comparisons against literal .nan
values. The compiler can warn with "comparison is always false".

Ali


 
 Now THAT makes sense.


+1.


T

-- 
"Computer Science is no more about computers than astronomy is about
telescopes." -- E.W. Dijkstra
Apr 18 2012
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
SomeDude:


 It shouldn't be a problem to detect comparisons against 
 literal .nan values. The compiler can warn with "comparison is 
 always false".

 Ali


 Now THAT makes sense.


That's what my proposal is going to be, with small refinements 
:-) (And it think it's not the first time someone proposes it).

Bye,
bearophile
Apr 18 2012
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, April 18, 2012 11:18:44 Ali Çehreli wrote:

 On 04/18/2012 10:13 AM, Jonathan M Davis wrote:

 On Wednesday, April 18, 2012 19:04:12 SomeDude wrote:

 On Wednesday, 18 April 2012 at 16:36:39 UTC, bearophile wrote:

 Ali:

 That a thousandth time I have made that mistake and still have
 not learned. :( Yes, .nan may not be compared with any other
 value, including .nan.


 
 Today I'll present an enhancement request to remove this
 problem from D.
 
 Hugs,
 bearophile


 
 I don't see how this could be enhanced.


 
 It's by design. An enhancement request is a waste of time.


 
 Comparisons with
 

 NaN _always_ return false regardless of what they're compared against


 
 - even
 

 NaN. It's not going to change.
 
 - Jonathan M Davis


 
 It shouldn't be a problem to detect comparisons against literal .nan
 values. The compiler can warn with "comparison is always false".


Yes, that would make sense. Heck, I'd be tempted to argue that using == with 
floating point values in general should be a warning, since that's pretty much 
never what you actually want, but that's probably not going to fly.

But the behavior itself isn't going to change.

- Jonathan M Davis
Apr 18 2012
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
SomeDude:


 Today I'll present an enhancement request to remove this 
 problem from D.

 Hugs,
 bearophile


 I don't see how this could be enhanced.


Take a look here:
http://forum.dlang.org/thread/undjpdewiqmghmhndedw forum.dlang.org

Bye,
bearophile
Apr 18 2012