익명의 네임 스페이스 : 정말 훌륭합니까?

Question

내부 링크를 정의하는 데 오랫동안 static 키워드를 사용했습니다. 나중에 익명의 네임 스페이스에서 로컬 객체를 래핑하는 C++ 스타일로 전환했습니다.

그러나 익명의 네임 스페이스로 몇 년 동안 작업했을 때 나는 static 키워드로 작업하기가 훨씬 쉽다고 생각하기 시작했습니다.

일반적인 문제는이 패턴을 가지고있다 : 특정 기능은 내부 또는 외부 링크가있는 경우

namespace { 
    // ...five pages of code... 
} // namespace 

이전 C 스타일의 반대로 지금, 많이 스크롤해야 볼하려면를 어디 함수/객체 앞에 static이 있는지 확인할 수 있습니다.

익명의 네임 스페이스가 있습니다. static은 typedef를 숨길 수 없습니다.하지만 개인적으로는별로 관심이 없습니다.

당신의 책임은 무엇입니까? 익명의 네임 스페이스의 승리가 그로 인해 가독성이 떨어짐을 보증합니까? 아니면 내가 잘못 됐어?

Answer 1

네임 스페이스의 코드가 너무 긴 경우,이 일을 당신을 막을 아무것도 없습니다 : C++ 03 이름없는 네임 스페이스를 사용의 실제 활용에

namespace { 
    int foo(char* x) { 
     return x[0] + x[1]; 
    } 
} 

namespace { 
    int bar(char *x, char *y) { 
     return foo(x) + foo(y); 
    } 
} 

는 내용이 외부 을 가지고 정확하게는 linkage (그러나 TU 밖에서는 볼 수 없기 때문에 여전히 보이지 않습니다.) 템플릿 매개 변수는 내부 연결을 가질 수 없습니다.

namespace { 
    int foo(const char* x) { 
     return x[0] + x[1]; 
    } 
} 

static int foo2(const char *x) { 
    return x[0] + x[1]; 
} 

template <int (*F)(const char*)> 
void baz(const char *p) { 
    F(p); 
} 

int main() { 
    baz<foo>("ab"); // OK 
    baz<foo2>("ab"); // not valid 
} 

Answer 2

익명 네임 스페이스는 클래스 선언으로 전역 범위를 오염시키지 않는 유일한 방법입니다. .cpp 파일에 클래스를 정의 할 때 매우 유용합니다.

Answer 3

는 별도로 스티브에 의해 언급 된 매우 유효한 점에서 나는 정적 함수에 우수한 만들 익명의 네임 스페이스에서 다른 매우 중요한 측면을 참조하십시오 소재지, 리팩토링 및 정보를 숨기고의 용이성.

매우 특정한 헬퍼 함수를 ​​필요로하지만 클래스 멤버를 사용하지 않는 하나 또는 두 개의 클래스 함수가 ​​있다고 가정합니다. 로버트 C. 마틴 (함수는 작아야하고 잘 정의 된 목적을 수행해야 함)을 사용하면 커다란 함수가 작은 함수로 리팩토링 될 수 있음을 알 수 있습니다. 작은 함수는 처음에는 큰 함수로만 사용될 수 있습니다.

그래서 옵션을 무엇을 가지고 :이 입력 꽤 많은 잔인한 수 있습니다 수반

와 -하자가 - 그것을 직면

1. 즉시 새로운 (아마도 개인) 클래스를 확인 모두 은 때때로 게으르거나 서두릅니다.

2. 개인 정적 기능 또는 비 멤버 함수 생성 : 더 흐름을 방해가 될 수

   당신이 그것을 제대로 할 경우 모두 헤더 파일과 CPP 파일을 편집 수반, 그래서 아직도 조금 부담 필요 이상으로 코드를 생성하여 불필요하게 이 헤더 파일을 혼란스럽게 만들거나, 앞으로 선언이 필요하거나 헤더에 추가로 포함될 수도 있습니다.

3. 익명 네임 스페이스 : -> 거기를 넣고 그것이 사용되는 클래스 메소드에 가까운이 함수를 작성

   당신은 멤버 액세스를 필요로 하나의 목적을 제공하지 않는 도우미 기능이 . 이것은 크게 나의 선호하는 것 : 그것은 빠르며 헤더 파일을 어지럽히 지 않습니다. 네임 스페이스에는이 cpp 이외의 다른 것에 의해 사용되지 않는다는 내용이 명시되어 있습니다. 친구가 사용하지 않으며 라이브러리 사용자는 그 존재를 알 수 없습니다. 당신은 거의 더 명확하지 않을 수 있으며, 종종이 패러다임은 출력을 수정 한 적은 수의 입력 매개 변수 인 클리너 기능 디자인으로 이어질 것입니다. 또한 기능 지역성이 있습니다 : 주전의 사용 직전에 정의하십시오. 이것은 단점이 될 수도 있지만 큰 클래스를 구현할 때 구현을 탐색 할 때 상당히 도움이된다. 또 다른 이점은 몇 가지 함수에 걸쳐 있지만 라이브러리 사용자에게는 정말 흥미로운 것은 아닙니다. 네임 스페이스에도 넣으십시오. 사용하는 기능과 동일하게 가장 좋습니다. 나중에 으로 바뀌면 다른 곳에서 상수와 함수가 필요하므로 전체를 클래스로 변환합니다. 이미 클래스가 깔끔하게 정리되어 있습니다.

면책 조항 : 많은 사람들은 제재목의 사용이 훨씬 더 깨끗하다고 ​​주장 할 수 있습니다. 이것은 단지 내 개인 의견입니다.