Оператор преобразования как автономная функция

Почему С++ требует, чтобы пользовательский оператор преобразования мог быть нестационарным членом? Почему не разрешено использовать автономные функции, как для других унарных операторов? Что-то вроде этого:

operator bool (const std::string& s) { return !s.empty(); }

Ответы

Ответ 1

Единственная причина, по которой я могу думать, - предотвратить неявное преобразование, применяемое к тому, что делается. В вашем примере, если вы сказали:

 bool( "foo" );

то "foo" будет неявно преобразован в строку, которая затем будет иметь явное преобразование bool, которое вы предоставили ему.

Это невозможно, если оператор bool является функцией-членом, поскольку неявные преобразования не применяются к *this. Это значительно уменьшает возможности для двусмысленности - двусмысленности обычно рассматриваются как "плохие вещи".

Ответ 2

Сохраняя оператор преобразования внутри класса, вы даете автору элемента управления классом способ его преобразования (он запрещает пользователям создавать неявные преобразования). Будучи разработчиком, я считаю это преимуществом, поскольку неявные преобразования имеют свои проблемы

Существует разница, заключающаяся в том, что один объект может передаваться другим, и ему нужно пройти через функцию преобразования. Первый сообщает, что объект имеет определенный тип, в то время как последний показывает новым читателям, что существует разница между этими двумя типами и что требуется преобразование.

Ответ 3

Существует группа операторов, которые должны быть перегружены как нестатические функции-члены: назначение, подписка, вызов функции, доступ к членам класса, функции преобразования.

Я полагаю, что стандартный комитет или Страуструп просто чувствовали, что это может быть слишком запутанным, если ему было разрешено вводить эти очень специальные поведения в классы извне.

Я предполагаю, что лучший способ получить ответ - отправить по электронной почте автора.

Ответ 4

Неявные пользовательские преобразования в любом случае не одобряются. Не используйте их. Просто притворись, что их там нет. Не говоря уже о новых способах их внедрения.

В любом случае, я думаю, их там нет, потому что они могут сделать достаточно неожиданные вещи. Включение нового заголовка, который вводит такое преобразование для класса, определенного где-то в другом месте, может привести к еще более запутывающим ошибкам.