Вы не можете безопасно пересылать объявления шаблонов STL, по крайней мере, если вы хотите сделать это переносимым и безопасным. Стандарт четко определяет минимальные требования для каждого элемента STL, но оставляет место для расширений реализации, которые могут добавлять дополнительные параметры шаблона, при условии, что они имеют значения по умолчанию. То есть: в стандарте указано, что std::vector — это шаблон, который принимает как минимум 2 параметра (тип и распределитель), но может иметь любое количество дополнительных аргументов в стандартной реализации.

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

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

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

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

За очень немногими исключениями вам не разрешено добавлять что-либо в std:; пространство имен. Таким образом, для таких классов, как вектор и строка, у вас нет другого выбора, кроме как включить соответствующие стандартные заголовочные файлы #include.

Также обратите внимание, что string — это не класс, а определение типа для basic_string<char>.

Это не поможет для вектора или строки, но, возможно, стоит упомянуть, что для iostream существует заголовок прямой ссылки, который называется iosfwd.

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

  template<typename _Tp, typename _Alloc = std::allocator<_Tp> >
    class vector : protected _Vector_base<_Tp, _Alloc>
    { ... };

Это было то, что я пытался сделать и раньше, но это невозможно из-за шаблонов.

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

Поскольку такие заголовки не меняются во время разработки, в любом случае не стоит их оптимизировать...

Нет простого очевидного способа сделать это (как это очень хорошо объяснили другие).

Однако эти заголовки следует рассматривать как часть языка (на самом деле!), поэтому вы можете без проблем использовать их в своих собственных заголовках, никто никогда не будет жаловаться.

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

Извините за ответ типа «настоящий победитель тот, кто избегает боя».

Просто включите заголовок в любой файл, где вы ссылаетесь на коллекцию STL.

Как уже упоминалось, нет способа надежно перенаправить объявление классов STL, и даже если вы найдете его для своей конкретной реализации, он, вероятно, сломается, если вы используете другую реализацию STL.

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

Если строка и вектор используются только в подписях непубличных членов вашего класса, вы можете использовать идиому PImpl:

// MyClass.h
class MyClassImpl;
class MyClass{
public:
    MyClass();
    void MyMethod();
private:
    MyClassImpl* m_impl;
};

// MyClassImpl.h
#include <vector>
#include <string>
#include <MyClass.h>
class MyClassImpl{
public:
    MyClassImpl();
    void MyMethod();
protected:
    std::vector<std::string> StdMethod();
};

// MyClass.cpp
#include <MyClass.h>
#include <MyClassImpl.h>

void MyClass::MyMethod(){
    m_impl->MyMethod();
}

Вы всегда включаете вектор и строку в заголовочный файл, но только в часть реализации вашего класса; файлы, включая только MyClass.h, не будут извлекать строку и вектор.

ВНИМАНИЕ

Ожидайте, что это вызовет бурю негодования.

Язык позволяет создавать собственные классы:

// MyKludges.h
#include <vector>
#include <string>
class KludgeIntVector : public std::vector<int> { 
  // ... 
};
class KludgeDoubleVector : public std::vector<double> {
  // ...
};

class KludgeString : public std::string {
  // ...
};

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

Строго говоря, производные классы не наследуют конструкторы базового класса, деструкторы, операторы присваивания и т.п. Вам нужно будет предоставить (тривиальные) реализации любого, что вы используете.

// LotsOfFunctions.h
// Look, no includes!  All forward declared!
class KludgeString;
// 10,000 functions that use neither strings nor vectors
// ...
void someFunction(KludgeString &);
// ... 
// Another 10,000 functions that use neither strings nor vectors

// someFunction.cpp
// Implement someFunction in its own compilation unit
// <string> and <vector> arrive on the next line
#include "MyKludges.h"
#include "LotsOfFunctions.h"
void someFunction(KludgeString &k) { k.clear(); }

Возможно, вам лучше использовать идиому pimpl: мне кажется, что вы не хотите подвергать реализацию своего класса клиентскому коду. Если векторные и строковые объекты агрегируются по значению, компилятору необходимо просмотреть их полные объявления.

За исключением добавления перегрузок в std::swap (единственное исключение, которое я могу сейчас придумать), обычно вам не разрешается добавлять что-либо в пространство имен std. Даже если бы это было разрешено, фактическое объявление для std::vector намного сложнее, чем код в OP. См. ответ Николая Н. Фетисова для примера .

Помимо всего этого, у вас есть дополнительная проблема, связанная с тем, что пользователи вашего класса будут делать с функциями, которые возвращают std::vector или std::string. В разделе 3.10 стандарта C++ говорится что функции, возвращающие такие объекты, возвращают rvalues, а rvalues ​​должен быть полного типа. В английском языке, если ваши пользователи хотят что-то делать с этими функциями, им в любом случае придется #include <vector> или <string>. Я думаю, было бы проще #include заголовки для них в файле .h и покончить с этим.

Я предполагаю, что ваша цель здесь - ускорить время компиляции? В противном случае я не уверен, почему вы хотите удалить их.

Другой подход (некрасивый, но практичный) заключается в использовании защиты макросов вокруг самого включения.

e.g.

#ifndef STDLIB_STRING
#include <string>
#define STDLIB_STRING
#endif

Хотя это выглядит беспорядочно, на больших кодовых базах это действительно увеличивает время компиляции. Что мы сделали, так это создали макрос Visual Studio, который будет автоматически генерировать охранники. Мы привязываем макрос к ключу для удобства кодирования. Затем это просто становится стандартом кодирования компании (или привычкой).

Мы также делаем это для наших собственных включений.

e.g.

#ifndef UTILITY_DATE_TIME_H
#include "Utility/DateTime.h"
#endif

Поскольку у нас есть помощники Visual Studio для автоматического создания охранников при создании собственных файлов заголовков, нам не нужен #define. Макрос знает, что это внутреннее включение, потому что мы всегда используем

#include ""

формат для наших собственных включает и

#include <>

для внешних включений.

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