연산자 오버로드에 대한 주장을 이해하지 못합니다.

나는 조엘의 기사 중 하나를 읽었습니다 .

일반적으로, 나는 물건을 숨기는 언어 기능이 약간 무섭다는 것을 인정 해야 합니다. 코드가 보이면

i = j * 5;

… C에서는 적어도 j에 5가 곱해지고 i에 저장된 결과가 있다는 것을 알고 있습니다.

그러나 C ++에서 동일한 코드 스 니펫을 보면 아무것도 모릅니다. 아무것도. C ++에서 실제로 무슨 일이 일어나고 있는지 알 수있는 유일한 방법은 i와 j가 어떤 타입인지 알아내는 것입니다. j는 operator*오버로드 된 유형 일 수 있으며 곱하려고 할 때 정말 재치있는 일입니다.

(Emphasis mine.) 사물을 숨기는 언어 기능이 무섭습니까? 당신은 어떻게 그것을 두려워 할 수 있습니까? 객체 지향 프로그래밍의 주요 아이디어 중 하나 ( 추상 이라고도 함)를 숨기지 않습니까? 메소드를 호출 할 때마다 a.foo(b)그 기능이 무엇인지 전혀 모릅니다. 어떤 유형 a과 유형 , b다른 곳에서 선언 될 수 있는 유형을 찾아야합니다 . 프로그래머에게 너무 많은 것을 숨기므로 객체 지향 프로그래밍을 제거해야합니까?

그리고 어떻게 j * 5에서 어떤 다른 j.multiply(5)당신이 연산자 오버로딩을 지원하지 않는 언어로 작성해야 할 수있는? lo, 보라, 재치있는 무언가를 하는 메소드 가있는 유형 일 수 있기 때문에 메소드 j내부 의 유형 과 엿보기 를 다시 찾아야합니다 .multiplyjmultiply

"Muahaha, 나는 방법의 이름을 짓는 사악한 프로그래머 multiply이지만, 실제로하는 것은 완전히 애매하고 비 직관적이며, 곱셈과는 전혀 관계가 없습니다." 프로그래밍 언어를 디자인 할 때 고려해야 할 시나리오입니까? 그런 다음 오해의 소지가있을 수 있으므로 프로그래밍 언어의 식별자를 포기해야합니다!

메소드의 기능을 알고 싶다면 문서를 보거나 구현 내부를 들여다 볼 수 있습니다. 연산자 과부하는 단지 구문 설탕이며, 그것이 게임을 어떻게 변화시키는 지 보지 못합니다.

제발 깨달아 줘

추상화는 코드를 숨겨서 내부 작업에 대해 걱정할 필요가 없으며 종종 변경할 수는 없지만 코드를 보지 못하게하려는 의도는 아닙니다. 우리는 운영자에 대한 가정을하고 Joel이 말했듯이 어디에나있을 수 있습니다. 특정 위치에 모든 과부하 된 운영자를 설정 해야하는 프로그래밍 기능이 있으면 그것을 찾는 데 도움이 될 수 있지만 더 쉽게 사용할 수 있는지 확실하지 않습니다.

데이터를 삭제하는 Get_Some_Data라는 함수보다 곱셈과 닮지 않는 무언가를 만드는 것이 보이지 않습니다.

IMHO, 연산자 과부하와 같은 언어 기능은 프로그래머에게 더 많은 힘을줍니다. 그리고 우리 모두 알다시피, 큰 힘으로 큰 책임이 따릅니다. 더 많은 힘을주는 기능은 또한 발로 자신을 쏠 수있는 더 많은 방법을 제공하며, 분명히 신중하게 사용해야합니다.

예를 들어 +또는에 대한 *연산자 class Matrix또는 연산자에 과부하가 걸리는 것이 좋습니다 class Complex. 모든 사람이 그 의미를 즉시 알 수 있습니다. 반면에, +Java가 언어의 일부로 이것을 수행하고 STL이 std::string연산자 오버로드 를 사용 하더라도 문자열 연결 을 의미 한다는 사실 은 전혀 분명하지 않습니다 .

연산자 오버로딩이 코드를 더 명확하게 만드는 또 다른 좋은 예는 C ++의 스마트 포인터입니다. 스마트 포인터가 가능한 한 일반적인 포인터처럼 작동하기를 원하므로 단항 *및 ->연산자 에 과부하가 걸리는 것이 좋습니다 .

본질적으로 연산자 오버로딩은 함수의 이름을 지정하는 또 다른 방법 일뿐입니다. 함수의 이름을 지정하는 규칙이 있습니다. 이름은 설명 적이어야하며 함수의 기능을 즉시 알 수 있어야합니다. 연산자 오버로드에도 동일한 규칙이 적용됩니다.

Haskell "+", "-", "*", "/"등은 단지 (중위) 기능입니다.

"4 plus 2"에서와 같이 삽입 기능의 이름을 "plus"로 지정해야합니까? 추가가 함수가하는 것이라면 어떨까요? "plus"기능의 이름을 "+"로 지정해야합니까? 왜 안돼?

소위 "연산자"의 문제는 대부분 수학 연산과 유사하며 해석 할 방법이 많지 않기 때문에 이러한 방법 / 함수 / 연산자가 무엇을하는지에 대한 기대가 높다고 생각합니다.

편집 : 내 요지를 더 명확하게 만들었습니다.

내가 본 다른 답변을 바탕으로 운영자 과부하에 대한 실제 이의 제기는 즉각적인 명백한 코드에 대한 요구라고 결론 지을 수 있습니다.

이것은 두 가지 이유로 비극적입니다.

1. 논리적 인 결론에 따르면, 코드가 분명해야한다는 원칙은 우리 모두가 여전히 COBOL로 코딩하게 할 것입니다.
2. 즉시 명백한 코드를 배우지 않습니다. 작동 방식에 대해 생각하는 데 시간이 걸리면 이해하기 쉬운 코드를 통해 배웁니다.

다소 동의합니다.

당신이 작성하는 경우 multiply(j,5), j제작, 스칼라 또는 매트릭스 타입이 될 수 multiply()무엇에 따라 다소 복잡 j하다. 그러나 오버로드라는 아이디어를 완전히 버린다면 함수의 이름을 지정 multiply_scalar()하거나 multiply_matrix()그 아래에서 무슨 일이 일어나고 있는지 분명히 알 수 있습니다.

우리 중 많은 사람들이 편도를 선호하는 코드가 있고 대부분의 사람들이 다른 방향을 선호하는 코드가 있습니다. 그러나 대부분의 코드는이 두 극단 사이의 중간 지점에 속합니다. 당신이 선호하는 것은 당신의 배경과 개인적 선호에 달려 있습니다.

연산자 오버로드에 두 가지 문제가 있습니다.

1. 과부하는 프로그래머가 의도하지 않은 경우에도 연산자의 의미를 변경합니다. 예를 들어, 과부하 때 &&, ||또는 ,, 당신은 이러한 연산자의 내장 변종에 의해 암시하는 시퀀스 포인트 (뿐만 아니라 논리 연산자의 단락 동작을) 잃게됩니다. 이러한 이유로 언어가 허용하더라도 이러한 연산자에 과부하를주지 않는 것이 좋습니다.
2. 어떤 사람들은 연산자 오버로딩이 훌륭한 기능이라고 생각하며, 적절한 솔루션이 아니더라도 어디서나 사용하기 시작합니다. 이로 인해 다른 사람들이 다른 방향으로 과도하게 반응하여 작업자 과부하를 사용하지 않도록 경고합니다. 나는 어느 그룹에도 동의하지 않지만 중간 입장을 취하십시오 : 운영자 과부하는 약간만 사용해야합니다.
   • 과부하 된 운영자는 도메인 전문가와 소프트웨어 전문가 모두에게 자연스러운 의미를 갖습니다. 이 두 그룹이 운영자의 자연스러운 의미에 동의하지 않으면 과부하하지 마십시오.
   • 관련된 유형 (들)에 대해, 연산자에 대한 자연스러운 의미는 없으며 즉각적인 맥락 (바람직하게는 같은 표현이지만 몇 줄을 넘지 않음)은 항상 연산자의 의미가 무엇인지 명확하게합니다. 이 범주의 예는 operator<<스트림입니다.

필자의 개인적인 경험을 바탕으로 여러 메소드를 허용하지만 연산자를 오버로드하지 않는 Java 방식은 운영자를 볼 때마다 정확히 무엇을 하는지를 의미합니다.

*이상한 코드를 호출 하는지 여부를 알 필요 는 없지만 코드가 곱셈임을 알고 Java 언어 사양에 정의 된 방식과 동일하게 동작합니다. 이것은 프로그래머가 정의한 모든 개찰구를 찾는 대신 실제 행동에 집중할 수 있음을 의미합니다.

즉, 연산자 오버로드를 금지하는 것은에 혜택입니다 독자 가 아닌 작가 , 따라서 유지 보수 프로그램을 쉽게!

오버로드 a * b와 호출의 한 가지 차이점 multiply(a,b)은 후자를 쉽게 잡을 수 있다는 것입니다. multiply함수가 다른 유형에 대해 오버로드되지 않은 경우 a및 의 유형을 추적하지 않고도 함수가 수행 할 작업을 정확하게 찾을 수 있습니다 b.

Linus Torvalds는 연산자 오버로드에 대한 흥미로운 주장을 가지고 있습니다. 대부분의 변경 사항이 전자 메일을 통해 패치를 통해 전송되는 Linux 커널 개발과 같이 관리자는 각 변경에 대한 몇 줄의 컨텍스트만으로 패치가 수행 할 작업을 이해할 수 있어야합니다. 함수와 연산자에 과부하가 걸리지 않으면 패치를 컨텍스트 독립적 인 방식으로 더 쉽게 읽을 수 있습니다. 변경된 파일을 통해 모든 유형이 무엇인지 알아 내고 과부하 된 연산자를 확인할 필요가 없기 때문입니다.

나는 그것이 기대를 깨는 것과 관련이 있다고 생각합니다. 나는 당신이 C ++에 익숙했고, 언어에 의해 완전히 지시되지 않은 연산자 행동에 익숙해졌으며 연산자가 이상한 일을 할 때 놀라지 않을 것입니다. 해당 기능이없는 언어에 익숙하고 C ++ 코드를 보는 경우 다른 언어의 기대치를 충족 시키며 과부하 된 연산자가 펑키 한 일을하는 것을 발견하면 놀라 울 수 있습니다.

개인적으로 차이가 있다고 생각합니다. 언어의 내장 구문 동작을 변경할 수 있으면 추론하기가 더 불투명 해집니다. 메타 프로그래밍을 허용하지 않는 언어는 구문 적으로 덜 강력하지만 개념적으로 이해하기가 더 간단합니다.

수학 연산자 오버로드는 C ++에서 연산자 오버로드의 실제 문제가 아니라고 생각합니다. 나는 표현의 맥락에 의존해서는 안되는 과부하 연산자 (즉 타입)는 "악"이라고 생각합니다. 예를 들어 과부하 , [ ] ( ) -> ->* new delete또는 단항 *. 절대 변경해서는 안되는 운영자의 기대치가 있습니다.

숨기는 것에 대한 요엘의 주장이 마음에 들지 않는다는 것을 잘 알고 있습니다. 나도 마찬가지야 내장 숫자 유형과 같은 것 또는 매트릭스와 같은 자신의 것에는 '+'를 사용하는 것이 훨씬 좋습니다. 나는 두 개의 행렬에 '.multiply ()'대신 '*'를 곱할 수있는 깔끔하고 우아하다는 것을 인정합니다. 그리고 결국 우리는 두 경우 모두 같은 종류의 추상화를 얻었습니다.

여기서 아픈 것은 코드의 가독성입니다. 실제 사례에서는 행렬 곱셈의 학문적 예가 아닙니다. 예를 들어, 언어에서 처음에 언어 핵심에없는 연산자를 정의 할 수있는 경우가 있습니다 =:=. 이 시점에서 많은 추가 질문이 발생합니다. 그 망할 운영자는 무엇입니까? 그 일의 우선 순위는 무엇입니까? 연관성은 무엇입니까? 어떤 순서로 a =:= b =:= c실제로 실행됩니까?

그것은 이미 연산자 오버로드에 대한 논쟁입니다. 아직도 확신하지 않습니까? 우선 순위 규칙을 확인하면 10 초 이상 걸리지 않습니까? 좋아, 계속하자

연산자 오버로드를 허용하는 언어 (예 : 이름이 'S'로 시작하는 언어)를 사용하기 시작하면 라이브러리 디자이너가 연산자를 재정의하는 것을 좋아한다는 것을 빨리 알게됩니다. 물론 그들은 교육을 잘 받았으며 모범 사례 (여기에는 냉소주의 없음)를 따르며 모든 API는 개별적으로 볼 때 완벽하게 이해됩니다.

이제 코드 하나에 연산자 오버로드를 많이 사용하는 몇 가지 API를 사용해야한다고 상상해보십시오. 또는 더 나은-그런 레거시 코드를 읽어야합니다. 이것은 작업자 과부하가 실제로 짜증나는 때입니다. 기본적으로 한곳에 과부하 된 연산자가 많으면 곧 프로그램 코드의 다른 비 숫자 문자와 어울리기 시작합니다. 그들은 실제로 연산자가 아닌 블록과 스코프, 모양 흐름 제어 문 또는 일부 메타 물건을 나타내는 좀 더 기본적인 언어 문법 요소가 아닌 알파벳이 아닌 문자와 섞일 것입니다. 시각적 혼란을 이해하려면 안경을 착용하고 눈을 LCD 디스플레이에 10cm 더 가까이 이동해야합니다.

일반적으로 직관적이지 않은 방식으로 연산자 오버로드를 사용하지 않습니다. 즉, 숫자 클래스가있는 경우 과부하가 허용됩니다 (권장). 그러나 직원 클래스가있는 경우 오버로드는 어떻게됩니까? 다시 말해서, 이해하기 쉬운 직관적 인 방법으로 운영자에게 과부하를가하십시오.

받아 들여 지거나 격려되는 :

class Complex
{
public:
    double r;
    double i;

    Complex operator*(const Compex& rhs)
    {
        Complex result;
        result.r = (r * rhs.r) - (i * rhs.i);
        result.i = (r * rhs.i) + (i * rhs.r);
        return result;
    }
};

받아 드릴 수없는:

class Employee
{
public:
    std::string name;
    std::string address;
    std::string phone_number;

    Employee operator* (const Employee& e)
    {
        // what the hell do I do here??
    }
};

여기에 이미 언급 된 것 외에도 연산자 오버로드에 대한 또 다른 주장이 있습니다. 실제로, 당신이 글을 쓴다면 +, 이것은 당신이 무언가에 무언가를 추가한다는 것을 의미합니다. 그러나 항상 그런 것은 아닙니다.

C ++ 자체는 그러한 경우의 훌륭한 예를 제공합니다. 어떻게 stream << 1읽어야합니까? 스트림이 1만큼 왼쪽으로 이동 했습니까? C ++의 <<도 스트림에 쓰라는 것을 명시 적으로 알지 않는 한 전혀 분명하지 않습니다. 그러나이 작업이 메서드로 구현 된 경우 정상적인 개발자는 쓸 o.leftShift(1)수 없으며 다음과 같습니다 o.write(1).

결론은 연산자 오버로드를 사용할 수 없게함으로써 언어는 프로그래머가 작업 이름에 대해 생각하게한다는 것입니다. 선택한 이름이 완벽하지 않더라도 이름보다 부호를 잘못 해석하는 것은 여전히 ​​어렵습니다.

철자법에 비해 연산자는 더 짧지 만 괄호가 필요하지 않습니다. 괄호는 입력하기가 상대적으로 불편합니다. 그리고 당신은 그것들의 균형을 잡아야합니다. 전체적으로, 모든 메소드 호출은 연산자와 비교하여 3 문자의 일반 노이즈가 필요합니다. 이것은 연산자를 사용하는 것이 매우 유혹적입니다.
왜 다른 사람이 이것을 원 cout << "Hello world"할까요?

과부하 문제는 대부분의 프로그래머가 믿을 수 없을 정도로 게으 르며 대부분의 프로그래머가 감당할 수 없다는 것입니다.

C ++ 프로그래머가 연산자 오버로드를 악용하게 만드는 것은 존재하지 않지만 메소드 호출을 수행하는 더 좋은 방법이 없다는 것입니다. 그리고 사람들은 가능하기 때문에 운영자 오버로드를 두려워하지 않고 완료 되었기 때문입니다.
예를 들어 Ruby와 Scala에서는 아무도 작업자 오버로드를 두려워하지 않습니다. 사실 연산자를 사용하는 것이 메소드보다 짧지 않다는 또 다른 이유는 Ruby가 연산자 오버로드 를 합리적인 최소값으로 제한 하고 Scala를 사용하면 자신의 연산자를 선언하여 충돌을 피할 수 있다는 것입니다.

연산자 오버로딩이 무서워하는 이유는 *단순히 "곱하기"를 의미하지 않는 생각조차 하지 않는 많은 프로그래머들이 있기 때문입니다 . 반면 foo.multiply(bar)에 최소한 같은 프로그래머 같은 방법 은 누군가가 커스텀 곱셈 방법을 쓴다는 것을 그 프로그래머에게 즉시 지적합니다 . 그 시점에서 그들은 왜 궁금해하고 조사하러 갈 것입니다.

저는 "CompareValues"라는 메소드를 만들어서 2 개의 인수를 취하고 한 값을 다른 값으로 적용하고 부울 값을 반환하는 상위 수준의 "좋은 프로그래머"와 함께 작업했습니다. 또는 "LoadTheValues"라는 메소드를 사용하여 3 개의 다른 개체에 대해 데이터베이스로 이동하여 값을 가져 this오고 계산을 수행 하고이를 데이터베이스에 저장합니다.

이러한 유형의 프로그래머와 팀을 이루어 작업하고 있다면, 그들이 일한 것을 조사하는 것을 즉시 알고 있습니다. 그들이 연산자에 과부하를가했다면, 그들이하고 있다고 생각하는 것을 제외하고 그들이 그것을했다는 것을 전혀 알 수 없습니다.

완벽한 세계 또는 완벽한 프로그래머가있는 팀에서 운영자 과부하는 아마도 환상적인 도구 일 것입니다. 그래도 완벽한 프로그래머 팀에서 일하지는 않았으므로 그것이 무서운 이유입니다.