필자가 작성한 정적 링크 된 라이브러리에 반복적 인 문제가 있습니다 (또는 경우에 따라 코드가 오픈 소스에서 누적 된 경우).재사용 성을 극대화하기 위해 라이브러리에서 유틸리티 함수를 분할하는 가장 좋은 방법은 무엇입니까?
이 라이브러리는 이름으로 MFC 도구 도서관이 많이 가지고 무료 기능, MFC 프로그래밍, Win32 API를 프로그래밍뿐만 아니라 C 라이브러리 유서 깊은 및 새로운 C++ 표준 라이브러리를 지원하는 클래스 등이있는.
간단히 말해서, 이것은 일상 업무에 적용되는 도구가있는 작업용 라이브러리이며 10 년 이상 축적되어있어 우리 제품에 없어서는 안될 항목입니다. 이와 같이,이 유틸리티는 다양한 기술에 대한 유틸리티와 기능이 풍부하게 결합되어 있으며, 종종 이러한 모든 기술을 내부적으로 혼합하여 추가 지원을 제공합니다.
예를 들어, 내가 문자열 관련 자유 기능의 과다, 심지어 클래스 또는 두 가지를 제공 문자열 Utilities.h 및 문자열 Utilities.cpp 있습니다.
그리고 종종 나는 한 쌍의 함수를 가지고 있는데, 하나는 MFC 나 CStrings가 필요없는 함수이고, 다른 것들은 이런 형제가 필요한 형제 함수입니다. 예 :
////////////////////////////////////////////////////////////////////////
// Line Terminator Manipulation
////////////////////////////////////////////////////////////////////////
// AnsiToUnix() Convert Mac or PC style string to Unix style string (i.e. no CR/LF or CR only, but rather LF only)
// NOTE: in-place conversion!
TCHAR * AnsiToUnix(TCHAR * pszAnsi, size_t size);
template <typename T, size_t size>
T * AnsiToUnix(T (&pszBuffer)[size]) { return AnsiToUnix(pszBuffer, size); }
inline TCHAR * AnsiToUnix(Toolbox::AutoCStringBuffer & buffer) { return AnsiToUnix(buffer, buffer.size()); }
// UnixToAnsi() Converts a Unix style string to a PC style string (i.e. CR or LF alone -> CR/LF pair)
CString UnixToAnsi(const TCHAR * source);
여기서 알 수 있듯이 AnsiToUnix에는 CString이 필요하지 않습니다. Unix는 줄 바꿈 문자로 단일 캐리지 리턴을 사용하고 Windows ANSI 문자열은 CR + LF를 줄 종결 자로 사용하므로 결과 문자열이 원래 버퍼 공간에 맞을 것입니다. 그러나 역 변환의 경우 문자열은 거의 모든 CR 발생에 대해 추가 LF를 추가하여 증가하므로 거의 자동으로 증가하기 위해 CString (또는 std :: string)을 사용하는 것이 바람직합니다. 문자열.
이것은 하나의 예제 일 뿐이며 그 자체만으로는 라이브러리의 해당 부분에서 MFC에 대한 종속성을 제거하기 위해 CString에서 std :: string으로 변환하는 것을 너무 비판적으로 생각하지 않아도됩니다. 그러나 종속성이 훨씬 더 미묘한 다른 예가 있으며이를 변경하는 작업이 더 많습니다. 또한 코드는 그대로 테스트됩니다. 가서 모든 MFC 종속성을 제거하려고하면 코드에 미묘한 오류가 발생하여 잠재적으로 제품을 손상시킬 수 있으며 본질적으로 꼭 필요한 것은 아닌 작업에 필요한 시간이 더 많이 걸릴 수 있습니다.
내가 알아 내야 할 중요한 점은 서로 매우 관련이있는 (ANSI-> UNIX, UNIX-> ANSI) 함수 세트가 있지만 여기에서는 한쪽이 MFC를 사용하고 다른 한쪽은 MFC를 사용한다는 점입니다. 문자 배열 만 사용합니다. 따라서 가능한 한 재사용 가능한 라이브러리 헤더를 제공하려는 경우 MFC에 의존하는 함수를 하나의 헤더로 분리하고 다른 함수는 포함하지 않는 함수를 추출하여보다 쉽게 사용할 수 있도록하는 것이 바람직합니다. MFC를 사용하지 않는 다른 프로젝트에 파일을 배포하십시오. (예 : Win32 헤더를 필요로하지 않는 모든 기능을 보유하는 것이 바람직합니다. C++의 단순한 기능 향상, 자체 헤더의 사용 및 기타.).
내 모든 궁금한 점은 이러한 문제를 어떻게 관리 할 것인가입니다. 기술 종속성과 관련 기능이 모두 같은 위치에 있습니까?
라이브러리를 세분화하려면 어떻게해야합니까? 무슨 일 이니?
내 동기 부여를 추가하는 것이 중요합니다. 기사를 게시하고 다른 사람들과 코드를 공유하고 싶지만 일반적으로 말해서 다른 부분을 사용하는 MFC Toolbox 라이브러리의 일부를 사용하는 경향이 있습니다. 의존성의 깊은 웹, 그리고 나는이 기사와 코드 프로젝트의 독자/프로그래머/소비자에게 많은 수하물로 부담을주고 싶지 않습니다!
주어진 기사 나 프로젝트에 필요한 부분 만 제거 할 수는 있지만 시간이 많이 걸리고 무의미한 시도처럼 보입니다. 내 마음으로, 라이브러리를 정리하여 라이브러리 전체를 끌지 않고보다 쉽게 공유 할 수있는 방법이 훨씬 합리적 일 것입니다.)
UINT GetPlatformGDILimit()
{
return CSystemInfo::IsWin9xCore() ? 0x7FFF : 0x7FFFFFFF;
}
GetPlatformGDILimit를 (매우 일반적이고 실용적인 무료 기능은 다음과 같습니다 즉
는 여기에 또 다른 좋은 예입니다 ... 오히려 매번에서 일을 발굴하는 것보다, 한 번 재구성. 클라이언트가 아닌 CSystemInfo와는 아무런 관련이 없습니다. 따라서 "SystemInfo.h"에 속하지 않습니다. 그리고 그것은 단지 하나의 자유 기능입니다. 아무도 자신의 헤더에 넣으 려하지 않을 것입니다. 필자는 Win32 API를 추가하는 무료 기능을 포함하는 "Win32Misc.h"에 배치했습니다. 그러나이 겉보기에 무해한 함수는 CSystemInfo에 의존합니다. CSystemInfo는 CString과 그 밖의 라이브러리 함수를 사용하여 효율적으로 작업을 수행하거나 코드 줄 수를 줄이거 나 더 강건하게 또는 전부를 사용할 수 있도록합니다.
그러나 Win32Misc.h 헤더에서 하나 또는 두 개의 함수를 참조하는 데모 프로젝트가있는 경우에는 프로젝트 필요에 맞는 개별 함수를 추출해야하는 바인딩에 들어가게됩니다. 그리고 그 엔티티가 의존하는 모든 것). 또는 Win32Misc.h와 .cpp를 포함시켜야합니다. 데모 프로젝트를 컴파일하기 위해 더 많은 불필요한 오버 헤드가 발생합니다.
그렇다면 사람들이 줄을 그어야 할 곳을 안내하기 위해 사용하는 엄지 손가락의 규칙은 무엇입니까? C++ 라이브러리가 지옥의 의존성 트리가되지 않도록하는 방법은 무엇입니까? ;)
"규격 유형"의 의미를 명확히 할 수 있습니까? –
@Emile : 다소 느슨하게 용어를 사용하고 있지만, C++ 표준에 정의 된 타입을 의미합니다. C++ 유형의 집계/유도법도 적합합니다. –
이것은 정적으로 링크 된 라이브러리이므로 DLL에는 문제가 없습니다. – Mordachai