C ++의 내부 typedef-좋은 스타일 또는 나쁜 스타일?

내가 최근에 자주 발견 한 것은 해당 클래스 내의 특정 클래스와 관련된 typedef를 선언하는 것입니다.

class Lorem
{
    typedef boost::shared_ptr<Lorem> ptr;
    typedef std::vector<Lorem::ptr>  vector;

//
// ...
//
};

이러한 유형은 코드의 다른 곳에서 사용됩니다.

Lorem::vector lorems;
Lorem::ptr    lorem( new Lorem() );

lorems.push_back( lorem );

내가 좋아하는 이유 :

• 클래스 템플릿에서 발생하는 노이즈를 줄이고 등 std::vector<Lorem>이됩니다 Lorem::vector.
• 의도의 진술로 사용됩니다. 위의 예에서 Lorem 클래스는 참조 횟수를 통해 계산 boost::shared_ptr되고 벡터에 저장됩니다.
• 이를 통해 구현이 변경 될 수 있습니다. 즉, Lorem boost::intrusive_ptr이 이후 단계에서 (참조를 통해 ) 참조 횟수로 변경되도록 변경해야하는 경우 이는 코드에 최소한의 영향을 미칩니다.
• 나는 그것이 더 예쁘고 읽기 쉽다고 생각합니다.

내가 싫어하는 이유 :

• 의존성에 문제가있는 경우가 있습니다- Lorem::vector다른 클래스 내에 포함하고 싶지만 Loem 선언을 전달 해야하는 경우 (또는 헤더 파일에 의존성을 도입하는 것이 아니라) 원하는 경우 약간 일치하지 않는 명시 적 유형 (예 : boost::shared_ptr<Lorem>대신 Lorem::ptr).
• 매우 일반적이지 않으므로 이해하기 어려울 수 있습니까?

나는 코딩 스타일에 객관적이 되려고 노력하기 때문에 그것에 대한 다른 의견을 얻는 것이 좋을 것입니다.

나는 그것이 훌륭한 스타일이라고 생각하고 직접 사용합니다. 가능한 한 이름의 범위를 제한하는 것이 항상 최선이며 클래스 사용은 C ++에서이를 수행하는 가장 좋은 방법입니다. 예를 들어 C ++ 표준 라이브러리는 클래스 내에서 typedef를 많이 사용합니다.

의도의 진술로 사용됩니다. 위의 예에서 Lorem 클래스는 boost :: shared_ptr을 통해 참조 카운트되고 벡터에 저장됩니다.

이것이 정확히하지 않는 것입니다.

코드에 'Foo :: Ptr'이 표시되면 그것이 shared_ptr인지 Foo * (STL에 :: pointer typedef가 T *인지 기억하십시오)인지 또는 다른 것이 있는지 전혀 모릅니다. Esp. 공유 포인터 인 경우 typedef를 전혀 제공하지 않지만 코드에서 shared_ptr 사용을 명시 적으로 유지하십시오.

실제로 템플릿 메타 프로그래밍 외부에서는 typedef를 거의 사용하지 않습니다.

STL은 항상 이런 유형의 일을합니다

멤버 함수와 중첩 된 typedefs로 정의 된 개념을 가진 STL 디자인은 역사적으로 막 다른 골목입니다. 현대 템플릿 라이브러리는 무료 함수와 특성 클래스를 사용합니다 (Bus.Graph 참조). 개념을 모델링하고 주어진 템플릿 라이브러리의 개념을 염두에두고 설계되지 않은 유형을보다 쉽게 ​​적용 할 수 있기 때문입니다.

STL을 같은 실수를 저지르는 이유로 사용하지 마십시오.

Typedef는 정책 기반 디자인과 특성 이 C ++에서 구축 된 것이므로 C ++의 Generic Programming의 힘은 typedef 자체에서 비롯됩니다.

Typdef는 확실히 좋은 스타일입니다. 그리고 당신의 모든 "내가 좋아하는 이유"는 좋고 정확합니다.

당신이 가진 문제에 대해. 앞으로의 선언은 성배가 아닙니다. 다중 레벨 종속성을 피하기 위해 코드를 간단히 디자인 할 수 있습니다.

typedef를 클래스 외부로 옮길 수는 있지만 Class :: ptr은 ClassPtr보다 훨씬 더 예쁘기 때문에이 작업을 수행하지 않습니다. 그것은 네임 스페이스와 비슷합니다-사물은 범위 내에서 연결되어 있습니다.

때때로 나는했다

Trait<Loren>::ptr
Trait<Loren>::collection
Trait<Loren>::map

또한 모든 도메인 클래스에 대해 기본값이 될 수 있으며 특정 도메인 클래스에 대한 일부 전문화가 가능합니다.

STL은 항상 이런 유형의 작업을 수행합니다. typedef는 STL의 많은 클래스에 대한 인터페이스의 일부입니다.

reference
iterator
size_type
value_type
etc...

다양한 STL 템플리트 클래스에 대한 인터페이스의 일부인 모든 typedef입니다.

이것에 대한 또 다른 투표는 좋은 생각입니다. 시간과 공간 모두에서 효율적인 시뮬레이션을 작성할 때이 작업을 시작했습니다. 모든 값 유형에는 부스트 공유 포인터로 시작된 Ptr typedef가 있습니다. 그런 다음 프로파일 링을 수행 하고이 객체가 사용 된 코드를 변경하지 않고도 일부를 부스트 침입 포인터로 변경했습니다.

이것은 클래스가 사용될 위치를 알고 모든 용도가 동일한 요구 사항을 갖는 경우에만 작동합니다. 예를 들어 라이브러리를 사용할 때 컨텍스트를 작성할 때 알 수 없기 때문에 라이브러리 코드에서 이것을 사용하지 않습니다.

현재 저는 이러한 종류의 typedef를 집중적으로 사용하는 코드를 작성하고 있습니다. 지금까지는 괜찮습니다.

그러나 반복적 인 typedef가 자주 있고 정의가 여러 클래스로 나뉘어져 있으며 어떤 유형을 다루고 있는지 전혀 알지 못합니다. 내 임무는 이러한 typedef 뒤에 숨겨진 일부 복잡한 데이터 구조의 크기를 요약하는 것이므로 기존 인터페이스에 의존 할 수 없습니다. 3-6 단계의 중첩 네임 스페이스와 결합하면 혼란스러워집니다.

따라서 사용하기 전에 고려해야 할 몇 가지 사항이 있습니다.

• 다른 사람이 이러한 typedef가 필요합니까? 수업은 다른 수업에서 많이 사용됩니까?
• 사용법을 줄이거 나 수업을 숨기나요? (숨기는 경우 인터페이스도 생각할 수 있습니다.)
• 다른 사람들이 코드를 사용하고 있습니까? 그들은 그걸 어떻게 햇어? 그들은 더 쉽다고 생각하거나 혼란스러워할까요?

이러한 typedef를 클래스 외부로 옮기는 것이 좋습니다. 이런 식으로 공유 포인터 및 벡터 클래스에 대한 직접적인 종속성을 제거하고 필요할 때만 포함시킬 수 있습니다. 클래스 구현에 이러한 유형을 사용하지 않는 한 내부 유형 정의가 아니어야한다고 생각합니다.

당신이 그것을 좋아하는 이유는 클래스 내에서 선언하지 않고 typedef를 통해 유형 별칭으로 해결되기 때문에 여전히 일치합니다.

typedef가 클래스 자체 내에서만 사용되면 (즉, private으로 선언 됨) 좋은 생각이라고 생각합니다. 그러나 정확히 당신이주는 이유 때문에 typedef를 클래스 외부에서 알아야 할 경우에는 사용하지 않을 것입니다. 이 경우 수업 외부로 옮기는 것이 좋습니다.