This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

### 388. Use of `complex` as a key in associative containers

Section: 26.4 [complex.numbers] Status: NAD Submitter: Gabriel Dos Reis Opened: 2002-11-08 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [complex.numbers].

View all issues with NAD status.

Discussion:

Practice with `std::complex<>` and the associative containers occasionally reveals artificial and distracting issues with constructs resembling: `std::set<std::complex<double> > s;`

The main reason for the above to fail is the absence of an appropriate definition for `std::less<std::complex<T> >`. That in turn comes from the definition of the primary template `std::less<>` in terms of `operator<`.

The usual argument goes as follows: Since there is no ordering over the complex field compatible with field operations it makes little sense to define a function `operator<` operating on the datatype `std::complex<T>`. That is fine. However, that reasoning does not carry over to `std::less<T>` which is used, among other things, by associative containers as an ordering useful to meet complexity requirements.

Related issue: 348.

[ Pre Bellevue: Reopened at the request of Alisdair. ]

[ Bellevue: ]

> This is a request for a design change, and not a defect in the standard. It is in scope to consider, but the group feels that it is not a change that we need to do. Is there a total ordering for floating point values, including NaN? There is not a clear enough solution or big enough problem for us to solve. Solving this problem would require solving the problem for floating point, which is equally unclear. The LWG noted that users who want to put objects into an associative container for which `operator<` isn't defined can simply provide their own comparison function object. NAD

Proposed resolution:

Informally: Add a specialization of `std::less` for `std::complex`.

Rationale:

Discussed in Santa Cruz. An overwhelming majority of the LWG believes this should not be treated a DR: it's a request for a design change, not a defect in the existing standard. Most people (10-3) believed that we probably don't want this change, period: as with issue 348, it's hard to know where to draw the line. The LWG noted that users who want to put objects into an associative container for which `operator<` isn't defined can simply provide their own comparison function object.