Вопрос вызван в основном нехватой опыта при написании коммерческих модулей, так как я еще далеко новичек в этом деле.
Дело в то что модули уже выполнены и протестированы, проходят последний этап исправлений (в основном на внешность)
И вот после исправлений возник такой вопрос.. (Пожалййста не цепляйтесь к словам так как мне возможно будет трудно выразить свои мысли)
Вопрос..
А как же правильно подключить другие модули, используемые моим модулем в работе.
Есть несколько соображений по этому поводу.
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>Хитро)) Спасибо!
Не за что, но для "спасибо", тут есть кнопки
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском