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

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에 :: 포인터 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입니다.

---

Another vote for this being a good idea. I started doing this when writing a simulation that had to be efficient, both in time and space. All of the value types had an Ptr typedef that started out as a boost shared pointer. I then did some profiling and changed some of them to a boost intrusive pointer without having to change any of the code where these objects were used.

Note that this only works when you know where the classes are going to be used, and that all the uses have the same requirements. I wouldn't use this in library code, for example, because you can't know when writing the library the context in which it will be used.

---

Currently I'm working on code, that intensively uses these kind of typedefs. So far that is fine.

But I noticed that there are quite often iterative typedefs, the definitions are split among several classes, and you never really know what type you are dealing with. My task is to summarize the size of some complex data structures hidden behind these typedefs - so I can't rely on existing interfaces. In combination with three to six levels of nested namespaces and then it becomes confusing.

So before using them, there are some points to be considered

• Does anyone else need these typedefs? Is the class used a lot by other classes?
• Do I shorten the usage or hide the class? (In case of hiding you also could think of interfaces.)
• Are other people working with the code? How do they do it? Will they think it is easier or will they become confused?

---

I recommend to move those typedefs outside the class. This way, you remove direct dependency on shared pointer and vector classes and you can include them only when needed. Unless you are using those types in your class implementation, I consider they shouldn't be inner typedefs.

The reasons you like it are still matched, since they are solved by the type aliasing through typedef, not by declaring them inside your class.

---

When the typedef is used only within the class itself (i.e. is declared as private) I think its a good idea. However, for exactly the reasons you give, I would not use it if the typedef's need to be known outside the class. In that case I recommend to move them outside the class.

참고URL : https://stackoverflow.com/questions/759512/internal-typedefs-in-c-good-style-or-bad-style