[LLVMbugs] [Bug 19189] New: std::complex::operator*= too restrictive with types it accepts

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Wed Mar 19 08:08:45 PDT 2014


            Bug ID: 19189
           Summary: std::complex::operator*= too restrictive with types it
           Product: libc++
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: d.grellscheid+llvm at gmail.com
                CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
    Classification: Unclassified

Changeset r187529 for <complex> has imposed additional restrictions on the
accepted types in operator*=. An example of the problematic change is below.

Where previously only the existence of

  complex<_Tp> operator*(complex<_Tp>, complex<_Xp>)

was necessary for the implementation of operator*=, 
now a constructor _Tp(_Xp) is required. 

Is this new constraint deliberately there?

An example situation where the new behaviour is problematic is for physical
units types that should never be directly constructed from doubles, but which
can be multiplied by doubles. 

Index: complex
--- complex     (revision 187528)
+++ complex     (revision 187529)
@@ -309,12 +309,12 @@
     template<class _Xp> _LIBCPP_INLINE_VISIBILITY complex& operator*=(const
complex<_Xp>& __c)
-            *this = *this * __c;
+            *this = *this * complex(__c.real(), __c.imag());
             return *this;
     template<class _Xp> _LIBCPP_INLINE_VISIBILITY complex& operator/=(const
complex<_Xp>& __c)
-            *this = *this / __c;
+            *this = *this / complex(__c.real(), __c.imag());
             return *this;

You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140319/233fdbcb/attachment.html>

More information about the llvm-bugs mailing list