www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1989] New: opEquals should return bool

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1989

           Summary: opEquals should return bool
           Product: D
           Version: 1.028
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: larsivar igesund.net


This has been requested many times on the NG (and I apologize if a bugzilla
entry exists, I could not find it), but has been brushed off with bogus and/or
outdated reasoning.

Instead the int return cause confusion and problems, for instance in template
code using bool returning predicates where opEquals won't work although doing
the semantically same thing.


-- 
Apr 12 2008
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1989






 ..but has been brushed off with bogus and/or outdated reasoning.
opEquals returning bool makes sense, performance was given as the reason for not changing things. See, http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html. --
Apr 14 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1989







 ..but has been brushed off with bogus and/or outdated reasoning.
opEquals returning bool makes sense, performance was given as the reason for not changing things. See, http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html.
This was discussed in the main newsgroup at a later date, and it was shown there that the performance reasoning was outdated. Unfortunately I don't have the link handy. --
Apr 14 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1989






here's the link:
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.PDF

:)

int areEqual(int op1, int op2)
{ return op1-op2; }

mov eax, [ebp+8]
sub eax, [ebp+12]
; now eax contains 0 if they're equal, this is not what we want.
; negate it
setz al ; 3 bytes, 1 cycle
and eax, 1 ; 3 bytes, 1 cycle
ret 8

using bool:

mov eax, [ebp+8]
cmp eax, [ebp+12]
sete al ; 3 bytes, 1 cycle
ret 8

I can't see efficiency of int used instead of bool.


-- 
May 22 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1989


matti.niemenmaa+dbugzilla iki.fi changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Platform|Other                       |All
            Version|1.028                       |0.163





-------
Here's a post which further ridicules the performance argument:
http://yarchive.net/comp/fastest_int.html

A quote from the summary: 'the bottom line of all of this, is that
"fastest" is a very slippery metric, and no one should ever expect
that any one size is uniformly faster, because it hardly ever is'.

I set the version to 0.163 based on Issue 288, although maybe this should just
be considered a duplicate of it?


-- 
May 26 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1989








 ..but has been brushed off with bogus and/or outdated reasoning.
opEquals returning bool makes sense, performance was given as the reason for not changing things. See, http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html.
This was discussed in the main newsgroup at a later date, and it was shown there that the performance reasoning was outdated. Unfortunately I don't have the link handy.
Lol, the NG thread where the performance argument was debunked is that very same one Gide posted ;), see this post: http://www.digitalmars.com/d/archives/digitalmars/D/bugs/7933.html#N8005 --
Jun 10 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1989


gide nwawudu.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE







*** This bug has been marked as a duplicate of 288 ***


-- 
Sep 03 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1989


smjg iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg iname.com






 This was discussed in the main newsgroup at a later date, and it was shown
 there that the performance reasoning was outdated. Unfortunately I don't have
 the link handy.
Was there any "performance reasoning" for this particular case that was even valid in the first place?
 int areEqual(int op1, int op2)
 { return op1-op2; }
Uh, that doesn't even work. Try it for yourself and see. Yet more reasons that opEquals should return bool: http://tinyurl.com/6p93a9 --
Sep 03 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1989






this is already fixed since 2.016


-- 
Sep 03 2008
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1989







 int areEqual(int op1, int op2)
 { return op1-op2; }
Uh, that doesn't even work. Try it for yourself and see.
Uh, yeah :) negation was reflected in the assembly code. --
Sep 10 2008