Защита включения не может вам помочь, потому что, если сначала будет включен publi c .h, что является логическим случаем для клиентов библиотеки, вы получите
// public.h already included so #include "Public.h" is ignored
namespace InternalFunctions {
FileObject GetFileObject(PublicFunctions::Access a);
// PublicFunctions::Access not defined yet.
}
namespace PublicFunctions {
enum Access{
READ,
WRITE,
}
FileObject CreateFileObject(Access a) {
return InternalFunctions::GetFileObject(a);
}
}
Хуже того, кто включает publi c .h получает возможность заглянуть в internals.h, что не позволяет разделить два.
Но если вы удалите реализацию CreateFileObject
из publi c .h, вы можете
namespace PublicFunctions {
enum Access{
READ,
WRITE,
}
FileObject CreateFileObject(Access a);
}
и оставьте файл internal.h в покое. Он будет использоваться исключительно скомпилированной библиотекой и не будет поставляться с интерфейсом publi c.
#include "Public.h"
namespace InternalFunctions {
FileObject GetFileObject(PublicFunctions::Access a);
}
, а затем Internal. cpp
#include "internal.h"
FileObject InternalFunctions::GetFileObject(PublicFunctions::Access a) {
if (a == PublicFunctions::Read) {
return openreadonly();
}
else {
return openwrite();
}
}
и, наконец, publi c. cpp
#include "internal.h"
FileObject PublicFunctions::CreateFileObject(Access a) {
return InternalFunctions::GetFileObject(a);
}
Стоит ли разделять publi c. cpp и internal. cpp зависит от программиста и их стандарта кодирования.