우리는 여러 다른 클라이언트에 제공하는 C++ 라이브러리가 있습니다. 최근에 공용 인터페이스에서 raw 포인터를 사용하는 대신 boost :: sharedptr을 사용하도록 전환했습니다. 이제는 고객이 더 이상 언제 어디에서 삭제할 필요가 있는지 걱정할 필요가 없으므로 이로 인해 엄청난 이점을 얻을 수 있습니다. 전환 작업을 수행 할 때는 올바른 일이라고 생각했지만 공개 인터페이스에 제 3 자 라이브러리의 항목을 포함시켜야한다는 것을 귀찮게했습니다. 일반적으로 가능한 한 그런 일을 피하십시오. 나는 부스트가 사실상 C++ 언어의 일부 였다고 합리화했다. 우리의 유스 케이스에서는 클라이언트 코드와 라이브러리가 객체에 대한 포인터를 가지고 있어야한다. 그러나 최근에 우리 고객이 인터페이스에 중립 스마트 포인터 클래스를 사용하도록 전환 할 수 있는지 물어 보았습니다. 왜냐하면 우리 도서관이 본질적으로 그들이 분명히 이해하고 높이 평가하는 특정 버전의 부스트를 강요하기 때문입니다. 그래서 지금 나는 최선의 행동이 무엇인지 궁금해하고 있습니다. 나는 그것에 대해 조금 생각해 보았고 간단하게 스마트 포인터를 높이는 간단한 스마트 포인터 클래스를 만드는 것에 대해 궁금해했습니다. 그러나 클라이언트는 아마 boost :: sharedptr의 맛을 보게 될 것입니다. 그리고 나서 우리는 세 개의 공유 된 포인터가 될 것입니다. 이것은 문제가 될 수도 있고 그렇지 않을 수도 있습니다. 어쨌든이 문제를 해결하는 가장 좋은 방법에 대한 의견을 듣고 싶습니다.라이브러리의 공용 인터페이스에서 boost :: shared_ptr 사용
편집 : 처음에는 소유권 이전을했지만 API 경계 양쪽에있는 코드는 객체에 대한 포인터를 보유해야한다고 지정 했어야합니다.
그렇습니다. 그러나 TR1이 포함 된 Visual Studio 2008, IIRC로 클라이언트를 이동시킬 수는 없습니다. 일부는 여전히 VS 2005에 있습니다. –
라이브러리 헤더에 Boost TR1 폴더를 포함시킬 수 있습니까? 그게 합법적인지 알아보기 위해서는 면허증을 봐야 겠지만, 아마도 그렇습니다. boost :: shared_ptr <>은 단순한 템플릿이기 때문에 공유 라이브러리 나 정적 라이브러리가 필요하지 않습니다. –
TR1은 언어의 일부는 아니지만 향후 언어 표준의 일부가 될 수있는 (공식적인) 정보 수집 모음입니다. 여기를 참조하십시오 : http://www.iso.org/iso/standards_development/processes_and_procedures/deliverables/iso_tr_deliverable.htm –