Вопрос вызван в основном нехватой опыта при написании коммерческих модулей, так как я еще далеко новичек в этом деле.
Дело в то что модули уже выполнены и протестированы, проходят последний этап исправлений (в основном на внешность)
И вот после исправлений возник такой вопрос.. (Пожалййста не цепляйтесь к словам так как мне возможно будет трудно выразить свои мысли)

Вопрос..
А как же правильно подключить другие модули, используемые моим модулем в работе.
Есть несколько соображений по этому поводу.
1) И в .hpp и .cpp вписать и там и там #include <модули> ....
2) Все модули вписать в .hpp а в .cpp ничего не вписывать
3) Постаратся чтобы все модули не имеющие значения в .hpp файле были прописаны в .cpp
А в .hpp прописать необходимый ему минимум
4) Все модули прописать в .cpp но и в .hpp прописать только необходимый ему минимум.

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

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

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

До последнего проекта делал п.2
Сейчас пробую делать в .h(pp) писать
class TMyClass;
а #include уже в .cpp

могут возникнуть сложности в template функциях и у других ситуациях, когда полное описание класса нужно в .h(pp)
ЗЫ. Как правильно не знаю. Тоже жду совета от гуру...

В .h файлах прописываются только минимально необходимые им инклуды.
Все инклуды, нужные .cpp файлам, обычно выносятся в общий файл типа common.h или stdafx.h (часто используемые) , а частично — прописываются в самих .cpp (используемые редко).

Здравствуйте, _Ursus_, Вы писали:

_U_>В .h файлах прописываются только минимально необходимые им инклуды.
_U_>Все инклуды, нужные .cpp файлам, обычно выносятся в общий файл типа common.h или stdafx.h (часто используемые) , а частично — прописываются в самих .cpp (используемые редко).

Ага! Вот оно наверное пришло.. то время когда пора узнать подробности что же такое знаменитый упоминаемый файл "stdafx.h".. Буду гуглить и знакомиться.

Все что вы написали я хорошо понял кроме одного.
Это получается при прописывании этих самых используемых модулей в "stdafx.h" то я в .cpp файлах должен вписывать #include "stdafx.h"? И файл stdafx.h я должен самостоятельно создавать в среде?

Огромное спасибо за информацию

_U_>В .h файлах прописываются только минимально необходимые им инклуды.
_U_>Все инклуды, нужные .cpp файлам, обычно выносятся в общий файл типа common.h или stdafx.h (часто используемые) , а частично — прописываются в самих .cpp (используемые редко).

Вот только с precompiled headers мне приходилось нарываться на интересные глюки при смене платформы/компилятора,
а без такой фичи stdafx.h -- зло.

Каждый .cpp должен инклюдить только то что необходимо для его компиляции.
Если есть возможность обойтись class Foo; вместо #include "foo.h" стоит так и писать, особенно в хидерах.

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

K13>Каждый .cpp должен инклюдить только то что необходимо для его компиляции.
K13>Если есть возможность обойтись class Foo; вместо #include "foo.h" стоит так и писать, особенно в хидерах.
K13>Как только приходится сталкиваться с достаточно большим проектом, необходимость такого правила становится очевидной.

Да, а то исправишь гденить один символ и собираешь потом проект минут 10...
А вот в том же Борланде (старая школа? Борланд — зло по-умолчанию?) почти все инклюды — в хеадере...

Здравствуйте, Сергей Савостин, Вы писали:

K13>>Каждый .cpp должен инклюдить только то что необходимо для его компиляции.
K13>>Если есть возможность обойтись class Foo; вместо #include "foo.h" стоит так и писать, особенно в хидерах.
K13>>Как только приходится сталкиваться с достаточно большим проектом, необходимость такого правила становится очевидной.

СС>Да, а то исправишь гденить один символ и собираешь потом проект минут 10...
СС>А вот в том же Борланде (старая школа? Борланд — зло по-умолчанию?) почти все инклюды — в хеадере...

Насколько сам знаком с продуктами борланда.. Они изначально пошустрее проекты собирают. Вот зато при написани очень больших проектов можно столкнутся с большими неприятностями с работой с кодом, иногда просто происходят баги в редакторе кода..
Но это в старых версиях борланда.. Хотя в новых тоже хватает недостатков.
В общем у каждого свои тараканы Х) ИМХО нужно уметь пользоваться средой и тогда она будет лучшим другом)

Здравствуйте, K13, Вы писали:

_U_>>В .h файлах прописываются только минимально необходимые им инклуды.
_U_>>Все инклуды, нужные .cpp файлам, обычно выносятся в общий файл типа common.h или stdafx.h (часто используемые) , а частично — прописываются в самих .cpp (используемые редко).

K13>Вот только с precompiled headers мне приходилось нарываться на интересные глюки при смене платформы/компилятора,
K13>а без такой фичи stdafx.h -- зло.

K13>Каждый .cpp должен инклюдить только то что необходимо для его компиляции.
K13>Если есть возможность обойтись class Foo; вместо #include "foo.h" стоит так и писать, особенно в хидерах.

K13>Как только приходится сталкиваться с достаточно большим проектом, необходимость такого правила становится очевидной.

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

T>Видел такие записи вот только счас начинаю понимать для чего они были))
T>Если я правильно понял это чтобы не включать целиком весь модуль а лишь подключить нужный класс, структуру и т.п.???
T>Как я понимаю класс будет найден в данном случаем уде при линковке, а это не будет влиять на работу с кодом в редакторе.. Т.е. когда среда подсказывает какие есть переменные\функции в классе, показывает какие переменные необходимо передавать функциям класса и т.п?

Нет. это нужно для того, чтобы не включать класс там где он не нужен.
Если какой-то кусок всего лишь получает в параметрах указатель/ссылку на объект и потом передает его в другие функции "как есть", не вызывая методов и т.п., то этому куску не нужен полный класс и хватает class Foo;

Вот "будет ли среда подсказывать" -- а фиг его знает... зависит от среды.
Да это и не так уж важно, по сравнению с выигрышем во времени сборки.

Здравствуйте, K13, Вы писали:

K13>Вот только с precompiled headers мне приходилось нарываться на интересные глюки при смене платформы/компилятора,
K13>а без такой фичи stdafx.h -- зло.

На то надо в .cpp прописывать все необходимые заголовки, как будто условный stdafx.h пуст. А в stdafx.h уже дублировать включение редко изменяемых заголовков.

Здравствуйте, K13, Вы писали:

K13>Нет. это нужно для того, чтобы не включать класс там где он не нужен.
K13>Если какой-то кусок всего лишь получает в параметрах указатель/ссылку на объект и потом передает его в другие функции "как есть", не вызывая методов и т.п., то этому куску не нужен полный класс и хватает class Foo;


Есть ещё вариант, что хедеру определение класса не нужно, а cpp-шнику нужно. Тогда можно в хедере просто предварительно класс объявить, а определение включить из cpp-шника...

E>Есть ещё вариант, что хедеру определение класса не нужно, а cpp-шнику нужно. Тогда можно в хедере просто предварительно класс объявить, а определение включить из cpp-шника...
Хитро)) Спасибо!

Здравствуйте, tatsu, Вы писали:

T>Хитро)) Спасибо!

Не за что, но для "спасибо", тут есть кнопки