Обход шаблона C ++ - PullRequest
       3

Обход шаблона C ++

2 голосов
/ 13 октября 2010

В моем проекте C ++ я недавно наткнулся на небольшую проблему: шаблоны.

Я объявил класс Data в моем заголовочном файле (который является общим для каждого .cpp) и дал ему функцию шаблона. Я реализовал это в data.cpp. Вскоре я вспомнил, как шаблоны компилируются на месте, когда на них ссылаются, и это нарушает разделение объявления / реализации, сделанное с файлами .h и .cpp.

Итак, я подумал о небольшой работе, поставив:

class Data {
  template<typename T> void myFunc(T in);
};

#define __DATA_TEMPLATE_IMPL
#include "Data.cpp"
#undef __DATA_TEMPLATE_IMPL

В header.h и:

#ifndef __DATA_TEMPLATE_IMPL

// non-template functions and other stuff....

#else

template<typename T>
void Data::myFunc(T in) {
  // implementation of template function
}

#endif

Это большой обходной путь, и для компилятора он выглядит так, как будто код между #else и #endif перенесен в файл заголовка.

Два вопроса:

Вы видите что-нибудь не так с этим? Можете ли вы вспомнить причину, по которой это может быть неправильно, неэффективно или что-то еще?

Есть ли лучший способ (кроме фактического размещения реализации в заголовочном файле)?

Ответы [ 2 ]

2 голосов
/ 13 октября 2010

Видите ли вы что-то не так с этим?Можете ли вы вспомнить причину, по которой это может быть неправильно, неэффективно или что-то еще?

Да.

  • ваши инструменты сборки будут либо:

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

Есть ли какой-нибудь лучший способ (кроме фактического размещения реализации в заголовочном файле)?

Лучше, каким образом?Есть практическая проблема, которую вы пытаетесь решить?Если так, то, вероятно, есть много способов ее решить.Если ваша проблема - это просто разочарование по поводу неэластичности, тогда двигайтесь дальше ... жизнь слишком коротка.

1 голос
/ 13 октября 2010

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

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

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