Блог

Предположим, что у меня есть две шаблонные функции, объявленные в заголовочном файле:

 template <typename T> void func1(const Tamp; value);
template <typename T> void func2(const Tamp; value);
  

И предположим, что реализация этих функций (также в файле заголовка, а не в исходном файле, поскольку они являются шаблонами) использует некоторую вспомогательную функцию реализации, которая также является шаблоном:

 template <typename T> void helper(const Tamp; value) {
    // ...
}

template <typename T> void func1(const Tamp; value) {
    // ...
    helper(value);
}

template <typename T> void func2(const Tamp; value) {
    // ...
    helper(value);
}
  

В любом исходном файле, который я включаю в файл заголовка, вспомогательная функция будет видна. Я не хочу этого, потому что вспомогательная функция — это просто деталь реализации. Есть ли способ скрыть вспомогательную функцию?

Общий подход (используемый, например, во многих библиотеках Boost) заключается в размещении помощника в пространстве имен с именем details , возможно, в отдельном заголовке (включенном из заголовка «public»).

Нет способа предотвратить его видимость и возможность вызова, но это довольно ясно указывает на то, что он является частью реализации, а не интерфейса.

Установленный прецедент заключается в размещении такого рода вещей в специально (т. Е. последовательно) именованном вложенном пространстве имен. Boost использует namespace details , Loki использует namespace Private . Очевидно, что ничто не может помешать кому-либо использовать содержимое этих пространств имен, но оба названия передают смысл того, что их содержимое не предназначено для общего использования.

При этом простой альтернативой является преобразование func1 и func2 из шаблонов свободных функций в шаблоны статических функций-членов некоторого общего класса; таким образом, helper может быть просто закрытым членом указанного класса, невидимым для внешнего мира:

 struct funcs {
    template<typename T>
    static void func1(T constamp; value) {
        // ...
        helper(value);
    }

    template<typename T>
    static void func2(T constamp; value) {
        // ...
        helper(value);
    }

private:
    template<typename T>
    static void helper(T constamp; value) {
        // ...
    }
};
  

Два варианта, которые приходят мне в голову:

1. Переместите всю реализацию в файл hpp, который вы включаете в нижнюю часть вашего файла h.
2. Реорганизуйте свой код в виде шаблонов классов, затем сделайте помощников закрытыми.

Поскольку пользователю вашего кода необходимо видеть полное определение func1 функции, ни ее реализация, ни реализация вспомогательной функции не могут быть скрыты.

Но если вы переместите реализацию в другой файл, пользователю придется столкнуться только собъявлением шаблона.:

 //templates.h
template< typename T > void f1( Tamp; );

#include <templates_impl.h> // post-inclusion
  

И определение:

 // templates_impl.h
template< typename T > void f1_helper( Tamp; ) {
}

template< typename T > void f1( Tamp; ) {
   // the function body
}
  

В C 20 теперь можно использовать модули. Для этого вы могли бы создать модуль, some_module.cppm содержащий все функции и отмечающий только интерфейс (либо отдельные функции, либо пространство имен) с export , не предоставляя при этом вспомогательные функции:

 // some_module.cppm
export module some_module;

template <typename T> 
void helper(const Tamp; value) {
  // ...
}

export
template <typename T>
void func1(const Tamp; value) {
  // ...
  helper(value);
}

export
template <typename T>
void func2(const Tamp; value) {
  // ...
  helper(value);
}
  

В приведенном выше случае экспортируются только функции func1 и func2 , к которым можно получить доступ внутри main.cpp :

 // main.cpp
#include <cstdlib>
import some_module;

int main() {
  func1(1.0);
  func2(2.0);
  return EXIT_SUCCESS;
}
  

В clang 12 вы можете скомпилировать этот код с помощью следующих трех команд:

 clang   -std=c  2b -fmodules-ts --precompile some_module.cppm -o some_module.pcm
clang   -std=c  2b -fmodules-ts -c some_module.pcm -o some_module.o
clang   -std=c  2b -fmodules-ts -fprebuilt-module-path=. some_module.o main.cpp -o main
./main
  

Я бы (как говорилось ранее) создал класс шаблона, сделал все функции статическими, а вспомогательную функцию закрытой. Но помимо этого я бы также рекомендовал сделать конструктор закрытым, как показано ниже:

 template <typename T>
class Foo{
public:
  static void func1(const Tamp; value);
  static void func2(const Tamp; value);
private:
  Foo();
  static void helper(const Tamp; value);
}
  

Когда вы делаете конструктор закрытым, компилятор не разрешает экземпляры этого шаблонного класса. Таким образом, приведенный ниже код станет незаконным:

 #include "foo.h"

int main(){
  int number = 0;
  Foo<int>::func1(number); //allowed
  Foo<int>::func2(number); //allowed
  Foo<int>::helper(number); //not allowed, because it's private
  Foo<int> foo_instance; //not allowed, because it's private
}
  

Итак, зачем кому-то это нужно? Потому что наличие разных экземпляров, которые являются ТОЧНО такими же, — это то, чего вы, вероятно, никогда не захотите. Когда компилятор сообщает вам, что конструктор некоторого класса является закрытым, тогда вы можете предположить, что наличие разных его экземпляров было бы излишним.

Я знаю, вы имеете в виду, что хотите скрыть его настолько тонко, чтобы вызывающие пользователи не могли найти ваши вспомогательные функции, пока они не изменят ваш файл кода. Я знаю это так хорошо, потому что в последнее время у меня очень похожие потребности.

Итак, как насчет переноса ваших вспомогательных функций в анонимное пространство имен? За последнее время это самый элегантный стиль, который я нашел:

 namespace YourModule
{
namespace
{//Your helper functions}
//Your public functions
}
  

Эта практика эффективно скрывает ваши внутренние функции извне. Я не могу найти никакого способа, которым вызывающий объект может получить доступ к функциям в анонимных пространствах имен.

Как ответил @user3635700 , обычно не рекомендуется преобразовывать ваше пространство имен в класс, полный статических функций, особенно когда у вас есть шаблоны статических переменных, таких как:

 template <uint8_t TimerCode>
static uint16_t MillisecondsElapsed;
  

Если эта переменная появляется в классе, вам придется инициализировать ее где-то за пределами класса! Однако вы не можете этого сделать, потому что это шаблон! ЧЕРТ возьми!

Похоже, что анонимное пространство имен в заголовочном файле, которое некоторые критикуют, является единственным и наиболее совершенным решением для наших нужд.