Как мне предоставить пользователям моей библиотеки перечисление в заголовочном файле publi c, но также использовать его для внутренних целей? - PullRequest
0 голосов
/ 17 июня 2020

Если я создаю библиотеку, которая предоставляет один файл заголовка publi c, который может принимать или возвращать общедоступный enum, как я могу использовать этот enum внутри, не создавая также циклическую зависимость в файлах заголовков?

Например:

Publi c .h

#include "Internal.h"


namespace PublicFunctions {
    enum Access{
        READ,
        WRITE,
    }

    FileObject CreateFileObject(Access a) {
        return InternalFunctions::GetFileObject(a);
    }
}

Internal.h

#include "Public.h"


namespace InternalFunctions {

    FileObject GetFileObject(PublicFunctions::Access a);
}

Internal. cpp

FileObject InternalFunctions::GetFileObject(PublicFunctions::Access a) {
    if (a == PublicFunctions::Read) {
          return openreadonly();
    }
    else {
              return openwrite();
    }
}

Я знаю о директиве препроцессора #praga Once, но есть ли способ переслать объявление enum в этих внутренних файлы?

Или #pragma когда-то лучший метод для разрешения этих зависимостей?

1 Ответ

0 голосов
/ 17 июня 2020

Защита включения не может вам помочь, потому что, если сначала будет включен 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 зависит от программиста и их стандарта кодирования.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...