문제

내가 이해하는 것처럼 pimpl 관용구는 C++에서 모든 비공개 클래스 멤버를 헤더에 배치하도록 강제하기 때문에 존재합니다.헤더에 공용 인터페이스만 포함된 경우 이론적으로 클래스 구현이 변경되더라도 프로그램의 나머지 부분을 다시 컴파일할 필요는 없습니다.

내가 알고 싶은 것은 왜 C++가 그러한 편리함을 허용하도록 설계되지 않았느냐는 것입니다.클래스의 비공개 부분이 헤더에 공개적으로 표시되도록 요구하는 이유는 무엇입니까(말장난 의도 없음)?

도움이 되었습니까?

해결책

이것은 객체의 크기와 관련이 있습니다. H 파일은 무엇보다도 객체의 크기를 결정하는 데 사용됩니다. 개인 회원이 그 안에 주어지지 않으면, 당신은 새로운 대상이 얼마나 큰지 알지 못할 것입니다.

그러나 원하는 동작을 다음과 같이 시뮬레이션 할 수 있습니다.

class MyClass
{
public:
   // public stuff

private:
#include "MyClassPrivate.h"
};

이것은 동작을 시행하지 않지만 .h 파일에서 개인 물건을 얻습니다. 아래쪽에는 다른 파일을 추가 할 수 있습니다. 또한 Visual Studio에서 Intellisense는 개인 회원에게는 효과가 없습니다. 이것은 플러스 또는 마이너스 일 수 있습니다.

다른 팁

나는 여기에 혼란이 있다고 생각합니다. 문제는 헤더에 관한 것이 아닙니다. 헤더는 아무것도하지 않습니다 (여러 소스 코드 파일에 공통 비트의 소스 텍스트를 포함하는 방법 일뿐).

문제는 C ++의 클래스 선언이 인스턴스가 작동하기 위해 필요한 모든 것을 공개 및 사적으로 정의해야한다는 것입니다. (Java에서도 마찬가지이지만 외부 계급 클래스에 대한 참조 방법은 공유 헤더와 같은 것을 불필요하게 사용합니다.)

공개 부품 만 사용하는 경우에도 누군가가 사용되는 콘크리트 클래스와 생성자를 사용하여 구현을 제공하는 방법을 알아야하는 것은 일반적인 객체 지향 기술 (C ++ One이 아니라)의 특성에 있습니다. (아래 3,)의 장치는 그것을 숨 깁니다. (1, 아래)의 관행은 (3)이든 아니든 상관없이 우려 사항을 분리합니다.

  1. 공공 부품, 주로 방법 만 정의하는 추상 클래스를 사용하고 구현 클래스가 해당 추상 클래스에서 상속되도록하십시오. 따라서 헤더에 대한 일반적인 컨벤션을 사용하여 공유되는 Abstract.hpp가 있습니다. 상속 클래스를 선언하고 구현 방법을 구현하는 모듈로만 전달되는 구현도 있습니다. 구현 .hpp 파일은 클래스 선언에 사용하기 위해 "actract.hpp"를 #include하므로 추상 인터페이스의 선언에 대한 단일 유지 보수 지점이 있습니다.

  2. 이제 구현 클래스 선언을 숨기려고하려면 구체적이고 완전한 클래스 선언을 보유하지 않고 구체적인 인스턴스의 구성을 요청하는 방법이 필요합니다. 새로 사용할 수 없으며 로컬 인스턴스를 사용할 수 없습니다. . (삭제할 수 있습니다.) 헬퍼 기능 소개 (클래스 인스턴스에 대한 참조를 제공하는 다른 클래스의 방법 포함)가 대체품입니다.

  3. 추상 클래스/인터페이스의 공유 정의로 사용되는 헤더 파일과 함께 또는 일부는 외부 도우미 기능에 대한 기능 서명을 포함합니다. 이러한 기능은 특정 클래스 구현의 일부인 모듈로 구현되어야합니다 (따라서 전체 클래스 선언을보고 생성자를 행사할 수 있습니다). 헬퍼 함수의 서명은 생성자의 서명과 매우 유사하지만 결과적으로 인스턴스 참조를 반환합니다 (이 생성자 프록시는 널 포인터를 반환 할 수 있으며 그러한 종류의 것을 좋아하는 경우 예외를 제외 할 수 있습니다). 도우미 함수는 특정 구현 인스턴스를 구성하고 추상 클래스의 인스턴스에 대한 참조로 캐스트를 반환합니다.

임무 완수.

오, 그리고 재 컴파일 및 리 링크는 구현 모듈 만 변경 될 때 호출 모듈의 재 컴파일을 피하기 위해 원하는 방식으로 작동해야합니다 (호출 모듈이 더 이상 구현에 대한 스토리지 할당을 수행하지 않기 때문에).

당신은 모두 질문의 요점을 무시하고 있습니다.

개발자가 PIMPL 코드를 입력 해야하는 이유는 무엇입니까?

저에게 제가 생각해 낼 수있는 가장 좋은 대답은 C ++ 코드를 표현할 수있는 좋은 방법이 없다는 것입니다. 예를 들어, 컴파일 타임 (또는 사전 프로세서 또는 그 밖의) 반사 또는 코드 DOM.

C ++는 개발자가 메타 프로그래밍을 수행 할 수 있도록 이들 중 하나 또는 둘 중 하나가 필요합니다.

그런 다음 공개 myclass.h에 이와 같은 글을 쓸 수 있습니다.

#pragma pimpl(MyClass_private.hpp)

그런 다음 자신만의 사소한 래퍼 생성기를 작성하십시오.

누군가는 나보다 훨씬 더 장황한 대답을 할 것이지만, 빠른 응답은 두 가지입니다.컴파일러는 저장 공간 요구 사항을 결정하기 위해 구조체의 모든 멤버를 알아야 하며, 컴파일러는 결정론적인 방식으로 오프셋을 생성하기 위해 해당 멤버의 순서를 알아야 합니다.

언어는 이미 상당히 복잡합니다.코드 전반에 걸쳐 구조화된 데이터의 정의를 분할하는 메커니즘은 약간의 재앙이 될 것이라고 생각합니다.

평소에는 늘 봐오던 정책 수업 Pimpl 방식으로 구현 동작을 정의하는 데 사용됩니다.정책 패턴을 사용하면 몇 가지 추가적인 이점이 있다고 생각합니다. 구현을 쉽게 교환할 수 있고 여러 부분 구현을 단일 단위로 쉽게 결합할 수 있어 구현 코드를 기능적이고 재사용 가능한 단위 등으로 나눌 수 있습니다.

인스턴스를 값으로 전달할 때 클래스의 크기가 필요하기 때문일 수 있습니다. 다른 클래스에서 집계하는 등이 있습니까?

C ++가 가치 의미론을 지원하지 않았다면 괜찮 았을 것입니다.

네,하지만...

Stroustrup의 "C ++의 디자인 및 진화"책을 읽어야합니다. 그것은 C ++의 흡수를 억제했을 것이다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top