digitalmars.D.bugs - [Issue 3789] New: comparing a struct with an array member does a bitwise compare
- d-bugmail puremagic.com (33/33) Feb 09 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (10/10) Feb 09 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (20/20) Feb 09 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (14/15) Feb 09 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (10/10) Feb 03 2011 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (13/13) Feb 03 2011 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (25/25) Feb 03 2011 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (10/10) Feb 04 2011 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (6/6) Feb 04 2011 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (6/6) Oct 13 2011 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (8/16) Oct 13 2011 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (50/50) Oct 14 2011 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (10/10) Oct 15 2011 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (6/6) Dec 10 2011 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (6/6) Jan 22 2012 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (33/35) Mar 26 2012 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (36/44) Mar 26 2012 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (25/25) Mar 26 2012 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (7/7) Mar 26 2012 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (12/14) Oct 24 2012 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (19/20) Oct 24 2012 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (32/32) Oct 27 2012 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (12/12) Mar 08 2013 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (13/13) Mar 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (12/12) Mar 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (9/11) Apr 23 2013 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (12/15) Apr 23 2013 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (11/18) Apr 24 2013 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (20/30) Apr 24 2013 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (11/15) Apr 24 2013 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (8/10) Apr 25 2013 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (9/12) May 07 2013 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (31/33) May 07 2013 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (7/14) May 07 2013 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (15/15) May 07 2013 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (6/6) May 12 2013 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (12/13) May 12 2013 http://d.puremagic.com/issues/show_bug.cgi?id=3789
- d-bugmail puremagic.com (6/6) Aug 30 2013 http://d.puremagic.com/issues/show_bug.cgi?id=3789
http://d.puremagic.com/issues/show_bug.cgi?id=3789 Summary: comparing a struct with an array member does a bitwise compare Product: D Version: 2.040 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: schveiguy yahoo.com 12:08:23 PST --- If you have a struct that does not define opEquals, but which contains a member that defines opEquals, that member's opEquals is called when comparing the struct. However, arrays are still bitwise compared. Example: struct String { char[] data; } void main () { auto foo = String("foo".dup); auto bar = String("foo".dup); assert(bar.data == foo.data); assert(bar == foo, "oops structs aren't equal"); } results in the second assert failing. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 09 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3789 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clugdbug yahoo.com.au Arrays don't have a an opEquals overloaded operator. What's the bug? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 09 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3789 14:37:33 PST --- that is an unimportant technical difference. The semantic meaning of the feature is that if you have a type T, and a struct S fully defined as: struct S { T member; } Then this assert should always pass: S s1, s2; ... // initialize s1 and s2 to whatever you want assert((s1 == s2) is (s1.member == s2.member)); Bitwise compare happens to be the comparison operator for all builtins except for floating point and arrays. Although opEquals isn't defined, they certainly have special comparison operators, and those should be invoked when comparing containing structs. This is the principle of least surprise, especially when arrays back types like strings. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 09 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3789 iorlas <denis.tomilin gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |denis.tomilin gmail.comArrays don't have a an opEquals overloaded operator. What's the bug?Not a bug, only not implemented part of comparison. Ofc it must be. Throws error or comparison each element through opEqual of elements type. Maybe now its not a critical, but in future it can block some code. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 09 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3789 Simen Kjaeraas <simen.kjaras gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dsimcha yahoo.com PST --- *** Issue 5313 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 03 2011
http://d.puremagic.com/issues/show_bug.cgi?id=3789 Simen Kjaeraas <simen.kjaras gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dsimcha yahoo.com CC| |simen.kjaras gmail.com PST --- *** Issue 5313 has been marked as a duplicate of this issue. *** PST --- *** Issue 4988 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 03 2011
http://d.puremagic.com/issues/show_bug.cgi?id=3789 Simen Kjaeraas <simen.kjaras gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |wrong-code Version|2.040 |D2 Summary|comparing a struct with an |Structs members that |array member does a bitwise |require non-bitwise |compare |comparison not correctly | |compared Severity|normal |major PST --- Making this the main bug for erroneous bitwise comparison of structs. There were at least 4 in total. List of things that do not work: floating-point members array members (including strings) List of things that do work: any member that uses bitwise comparison member structs that have overloaded opEquals The latter suggests that this should work for floating point numbers and arrays too. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 03 2011
http://d.puremagic.com/issues/show_bug.cgi?id=3789 bearophile_hugs eml.cc changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bearophile_hugs eml.cc Maybe issue 5519 should be merged with this one. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 04 2011
http://d.puremagic.com/issues/show_bug.cgi?id=3789 PST --- *** Issue 5519 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Feb 04 2011
http://d.puremagic.com/issues/show_bug.cgi?id=3789 *** Issue 6812 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 13 2011
http://d.puremagic.com/issues/show_bug.cgi?id=3789 --- From bug 6812:List of things that do not work: floating-point members array members (including strings)+ member classes that have overloaded opEqualsList of things that do work: any member that uses bitwise comparison member structs that have overloaded opEquals-- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 13 2011
http://d.puremagic.com/issues/show_bug.cgi?id=3789 Kenji Hara <k.hara.pg gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Platform|Other |All Depends on| |1824 --- Test case. void main() { static struct Float { double x; } Float f; assert(f.x != f.x); // NaN != NaN assert(f != f); // Fails, should pass static struct Array { int[] x; } Array a1 = Array([1,2,3].dup); Array a2 = Array([1,2,3].dup); assert(a1.x !is a2.x); assert(a1.x == a2.x); assert(a1 == a2); // Fails, should pass static struct Class { Object x; } static class X { bool opEquals(Object o){ return true; } } Class c1a = Class(new Object()); Class c2a = Class(new Object()); assert(c1a.x !is c2a.x); assert(c1a.x != c2a.x); assert(c1a != c2a); // Pass, Object.opEquals works like bitwise compare Class c1b = Class(new X()); Class c2b = Class(new X()); assert(c1b.x !is c2b.x); assert(c1b.x == c2b.x); assert(c1b == c2b); // Fails, should pass } To fix the comparison behavior of a struct that has classes as members, we need to fix the bug 1824 first. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 14 2011
http://d.puremagic.com/issues/show_bug.cgi?id=3789 Kenji Hara <k.hara.pg gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch --- https://github.com/D-Programming-Language/dmd/pull/387 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 15 2011
http://d.puremagic.com/issues/show_bug.cgi?id=3789 *** Issue 7089 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 10 2011
http://d.puremagic.com/issues/show_bug.cgi?id=3789 --- *** Issue 7342 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 22 2012
http://d.puremagic.com/issues/show_bug.cgi?id=3789 This is an answer to Walter to Bug 7783 :In the absense of a user-defined opEquals for the struct, equality is defined as a bitwise compare. This is working as expected. Not a bug.I agree, it's not a DMD implementation bug because here it's working as designed. But I have voted bug 3789 time ago because I consider this in top 15 of the design decisions to fix/change, because this is a large source of bugs, it's unnatural. D is designed to be safe on default. Not comparing the strings as strings in the following code breaks the Principle of least astonishment: struct Foo { string name; bool b; } void main() { auto a = Foo("foobar".idup, true); auto b = Foo("foobar".idup, true); assert(a == b); } For me the only acceptable alternative to fixing Bug 3789 is statically disallowing the equal operator (==) in such cases. D language has the "is" for the situations where you want to perform bitwise comparison of structs too. This is OK. For the other situations where I use "==" among struts, I want it do the right thing, like comparing its contained strings correctly instead of arbitrarily choosing bitwise comparison of the sub-struct that represents the string. Making "==" work as "is" for structs means using an operator for the purpose of the other operator, and it has caused some bugs in my code. And it will cause bugs in future D code. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 26 2012
http://d.puremagic.com/issues/show_bug.cgi?id=3789 04:46:26 PDT ---This is an answer to Walter to Bug 7783 :The statement above is not completely true: struct S { string x; bool opEquals(const ref S other) const { return x == x; } } struct T { S s; // no user-defined opEquals } void main() { T t1, t2; t1.s.x = "foobar".idup; t2.s.x = "foobar".idup; assert(t1 == t2); } This passes in 2.058. Essentially, bitwise comparison is done unless a member requires special case opEquals, in which case a generated opEquals function is made for that struct. I contend that for the compiler to defer to user-defined structs, but not to builtin types on how to compare themselves is not only inconsistent, but leads to endless boilerplate code. It does not help anyone. We have 'is', which does a bitwise compare. There is no reason to make == duplicate that functionality. For the rare cases where you actually *need* bitwise comparison on arrays or floats, you can define a special opEquals. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------In the absense of a user-defined opEquals for the struct, equality is defined as a bitwise compare. This is working as expected. Not a bug.I agree, it's not a DMD implementation bug because here it's working as designed.
Mar 26 2012
http://d.puremagic.com/issues/show_bug.cgi?id=3789 08:07:29 PDT --- To further underline this point: struct S { string x; bool opEquals(const ref S other) const { return x == x; } } struct T { S s; string r; } void main() { T t1, t2; t1.s.x = "foobar".idup; t1.r = "foobaz".idup; t2.s.x = "foobar".idup; t2.r = "foobaz".idup; assert(t1 == t2); } Yes, the string values in r are compared not bitwise, but for content. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 26 2012
http://d.puremagic.com/issues/show_bug.cgi?id=3789 See also the thread: http://forum.dlang.org/thread/jkpllu$1hss$1 digitalmars.com -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 26 2012
http://d.puremagic.com/issues/show_bug.cgi?id=3789 Andrej Mitrovic <andrej.mitrovich gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrej.mitrovich gmail.com 12:36:15 PDT ---For the rare cases where you actually *need* bitwise comparison on arrays or floats, you can define a special opEquals.Also hashes suffer from this problem as well. They're compared via 'is' instead of '==' in struct fields, just like arrays. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 24 2012
http://d.puremagic.com/issues/show_bug.cgi?id=3789 jens.k.mueller gmx.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jens.k.mueller gmx.deArrays don't have a an opEquals overloaded operator. What's the bug?I don't understand. How can arrays have no opEquals yet this assert(bar.data == foo.data); compiles? Syntactically there is opEquals and it checks whether each element is equal to the corresponding other element. And the opEquals generated by default should for each member call opEquals if it exists. Otherwise it falls back to bit-wise equality. Why should it be different from this? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 24 2012
http://d.puremagic.com/issues/show_bug.cgi?id=3789 Jonathan M Davis <jmdavisProg gmx.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jmdavisProg gmx.com PDT --- I just thought that I should point out that the correct behavior for comparing structs is explained in section of 7.1.5.2 of TDPL (p. 258 - 259). It doesn't explicitly discuss what happens with built-ins (it says that opEquals is called on each of the members), but I would think that calling opEquals on each of the members would mean using == on built-in types and _not_ bitwise comparison. So, I think that it's pretty clear that the correct behavior is that the default behavior of opEquals for a struct like struct S { T t; U u; } mean that the compiler generates an opEquals like (ignoring the issues with the refness or constness of the argument or opEquals itself): bool opEquals(S rhs) { return t == rhs.t && u == rhs.u; } and that the types of T and U are completely irrelevant. If the compiler wants to optimize it to being a bitwise comparison when that would result in exactly the same behavior (save for performance differences), then great, but it should _never_ do bitwise comparison when that would result in different semantics from using == on each of the members. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 27 2012
http://d.puremagic.com/issues/show_bug.cgi?id=3789 Denis Shelomovskij <verylonglogin.reg gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |verylonglogin.reg gmail.com 2013-03-08 16:53:23 MSK --- Just want to note the compiler often can't optimize a comparison to be bitwise because of align gaps which also should be ignored to conform `opEquals` behavior. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 08 2013
http://d.puremagic.com/issues/show_bug.cgi?id=3789 Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/3eecfd2b1e6d7b57affbe175ac252149371623e3 fix Issue 3789 - Structs members that require non-bitwise comparison not correctly compared https://github.com/D-Programming-Language/phobos/commit/b4f5c4f6dd8ec65b68528a246e17c1c46c346e29 Issue 3789 - Structs members that require non-bitwise comparison not correctly compared -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 09 2013
http://d.puremagic.com/issues/show_bug.cgi?id=3789 Kenji Hara <k.hara.pg gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |pull Depends on|9671 | --- Partial fix for floating point, array, and union field comparison. https://github.com/D-Programming-Language/dmd/pull/1731 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 09 2013
http://d.puremagic.com/issues/show_bug.cgi?id=3789Partial fix for floating point, array, and union field comparison. https://github.com/D-Programming-Language/dmd/pull/1731Associative arrays too? (The change log of the release should list exactly what parts of this bug are fixed and what is not yet fixed.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 23 2013
http://d.puremagic.com/issues/show_bug.cgi?id=3789 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla digitalmars.com 10:47:33 PDT ---Just want to note the compiler often can't optimize a comparison to be bitwise because of align gaps which also should be ignored to conform `opEquals` behavior.The holes must be initialized to zero, by definition, so that a bitwise comparison can be done. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 23 2013
http://d.puremagic.com/issues/show_bug.cgi?id=3789 2013-04-24 12:55:27 MSD ---Nop. Holes are holes, that's all. I'd be happy if it will be documented that padding holes must be zero-initialized. As for now we has the situation even worse than underdocumented (as always) C11, which partially defines it in "6.7.9 Initialization", para 10. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------Just want to note the compiler often can't optimize a comparison to be bitwise because of align gaps which also should be ignored to conform `opEquals` behavior.The holes must be initialized to zero, by definition, so that a bitwise comparison can be done.
Apr 24 2013
http://d.puremagic.com/issues/show_bug.cgi?id=3789 monarchdodra gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |monarchdodra gmail.comTechnically, D initializes all variables by first blitting T.init over them, which contains implementation defined values for the holes. "Thanks" to this, the implementation may make optimizations that makes assumptions on the values in the gaps. So even if you've initialized all the variables in a struct, if don't first blit the struct itself, your struct will be in a globally "not fully initialized" state. From there, an opEqual may fails, which would be legitimate undefined behavior. So even if "holes are holes", D's intialization mechanics mean they have defined values. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------Nop. Holes are holes, that's all.Just want to note the compiler often can't optimize a comparison to be bitwise because of align gaps which also should be ignored to conform `opEquals` behavior.The holes must be initialized to zero, by definition, so that a bitwise comparison can be done.
Apr 24 2013
http://d.puremagic.com/issues/show_bug.cgi?id=3789So even if you've initialized all the variables in a struct, if don't first blit the struct itself, your struct will be in a globally "not fully initialized" state. From there, an opEqual may fails, which would be legitimate undefined behavior.All D programmers need to keep this in account. The usage of std.array.minimallyInitializedArray is one of such cases. In D there is enough static introspection to statically tell if a struct has holes or not. So you can use this information to tell when it's safer to use uninitialized structs. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 24 2013
http://d.puremagic.com/issues/show_bug.cgi?id=3789 2013-04-25 12:00:28 MSD ---So even if "holes are holes", D's intialization mechanics mean they have defined values.I don't see a fundamental difference between D and C here. D just initialize more stuff by default. IMO, it must be documented. Opened Issue 9988. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 25 2013
http://d.puremagic.com/issues/show_bug.cgi?id=3789 ---https://github.com/D-Programming-Language/dmd/pull/387Partial fix for floating point, array, and union field comparison. https://github.com/D-Programming-Language/dmd/pull/1731The third try and fully fix this issue. https://github.com/D-Programming-Language/dmd/pull/1972 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 07 2013
http://d.puremagic.com/issues/show_bug.cgi?id=3789 ---The holes must be initialized to zero, by definition, so that a bitwise comparison can be done.I think '==' operation should test structural comparison, not bitwise comparison. Only when structural comparison is equal to bitwise one, it can be optimized to the latter. By fixing issue 9873, struct objects comparison `s1 == s2` is rewritable to `s1.tupleof == s2.tupleof` for member-wise structural comparison. Compiler can apply this expansion recursively. struct S { int num; int[] arr; } struct T { S s; int[int] aa; } void main() { T t1, t2; t1 == t2; // is rewritable to: // t1.tupleof == t2.tupleof // t1.tupoelf[0] == t2.tupoelf[0] && t1.tupoelf[1] == t2.tupoelf[1] // t1.s == t2.s && t1.aa == t2.aa // t1.s.tupleof == t2.s.tupleof && t1.aa == t2.aa // t1.s.num == t2.s.num && t1.s.arr == t2.s.arr && t1.aa == t2.aa } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 07 2013
http://d.puremagic.com/issues/show_bug.cgi?id=3789 ---I've supported AA member comparison in my third pull request. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------Partial fix for floating point, array, and union field comparison. https://github.com/D-Programming-Language/dmd/pull/1731Associative arrays too? (The change log of the release should list exactly what parts of this bug are fixed and what is not yet fixed.)
May 07 2013
http://d.puremagic.com/issues/show_bug.cgi?id=3789 Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/42e929a12c4df7a68e7bc721479a36697abce67b fix Issue 3789 - Structs members that require non-bitwise comparison not correctly compared Additionally fix interpret3.d tests, because class object equality is currently not yet supported in CTFE. https://github.com/D-Programming-Language/dmd/commit/596c1128f4de2b246d339497e1bcec70d93ffd78 Issue 3789 and 10037 - [TDPL] Structs members that require non-bitwise comparison not correctly compared -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 07 2013
http://d.puremagic.com/issues/show_bug.cgi?id=3789 07:03:51 PDT --- Is this fixed now, and should I put it in the changelog? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 12 2013
http://d.puremagic.com/issues/show_bug.cgi?id=3789 Kenji Hara <k.hara.pg gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ---Is this fixed now, and should I put it in the changelog?Yes I can say it is fixed, so close this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 12 2013
http://d.puremagic.com/issues/show_bug.cgi?id=3789 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 30 2013