특정 네임 스페이스에서 라이브러리를 제작할 때 해당 네임 스페이스에있는 클래스에 대해 오버로드 된 연산자를 제공하는 것이 편리합니다. 이 오버로드 된 연산자 라이브러리의 네임 스페이스에 하나 구현 될 수있는 (적어도 g와 ++) 보인다 내 테스트에서C++에서 네임 스페이스 및 연산자 오버로드
namespace Lib {
class A {
};
A operator+(const A&, const A&);
} // namespace Lib
또는 전역 네임 스페이스
namespace Lib {
class A {
};
} // namespace Lib
Lib::A operator+(const Lib::A&, const Lib::A&);
을, 그들은 모두 잘 작동하는 것 같다. 이 두 가지 옵션간에 실질적인 차이점이 있습니까? 어느 접근법이 더 좋습니까?
라이브러리 네임 스페이스에서 정의해야합니다. 컴파일러는 인수 별 조회를 통해 어쨌든 찾을 것입니다.
전역 이름 공간을 오염시킬 필요가 없습니다.
구문이 덜 모호하고 전역 네임 스페이스가 복잡하지 않으므로 네임 스페이스에 정의해야합니다. 때문에 Koenig lookup의 작동
namespace Lib {
class A {
public:
A operator+(const A&);
};
} // namespace Lib
이것은 B가 암시 적으로 A로 변환 될 수 있지만 A의 서브 클래스가 아닌 경우 A + B가 작동하지만 B + A가 혼동을 일으키지 않는다는 것을 의미하므로 나쁜 생각 일 수 있습니다. 물론 그것은 중요하지 않습니다. 예를 들어 하우스 스타일이 사용자 정의 유형 간의 암시 적 변환을 금지하는 경우입니다. –
동의합니다 : A + B는 작동하지만 B + A는 작동하지 않는 문제가 있습니다 (A는 복소수를 시뮬레이트하는 클래스이고 B는 int 임). 또 다른 문제점은 클래스가 아닌 클래스가 캡슐화를 증가시키는 반면, friend가 아닌 operator + 함수는 클래스의 캡슐화를 증가 시킨다는 것입니다. – paercebal
라이브러리 네임 스페이스로 퍼팅 : 당신이 당신의 클래스 정의에 과부하를 정의하는 경우
사실,이 논쟁 문제가된다.
실제로 Koeing 검색은 Lib 네임 스페이스 내에 함수를 넣을 수 있도록 정확하게 작성되었으며 여전히 correclty에 과부하가 걸려 있습니다. 예외 C++ 항목 31-32를 참조하십시오. – tenpn
라이브러리 네임 스페이스를 사용하는 또 다른 이유는 [이 포스트] (http://stackoverflow.com/questions/5195512/namespaces-and-operator-resolution)에는 전역 네임 스페이스 사용이 작동하지 않는 예제가 포함되어 있습니다. – Tim