заголовочный файл и файл исходного текста

[Роман Радер]

Собственно, какая разница по сути? Есть куча файлов и среди них один единственный .cpp в котором main() и в него инклудятся все остальные. Если все равно все надо инклудить, какая тогда разница .h файл или .cpp или хоть .txt?
Сейчас я делаю так: у меня ОДИН cpp файл и куча .h. У других видел кучу cpp файлов, поэтому и спросил.

[pu4koff]

Сообщение от Роман Радер

Собственно, какая разница по сути? Есть куча файлов и среди них один единственный .cpp в котором main() и в него инклудятся все остальные. Если все равно все надо инклудить, какая тогда разница .h файл или .cpp или хоть .txt?

Да хоть "программа.моя" назовите. Главное - содержание, а не расширение, хотя таки принято заголовочные обзывать *.h или *.hpp и соответственно реализация в *.c (для Си) и *.cpp (для С++).
В заголовочных файлах должен быть только интерфейс (описание классов, функций, глобальных переменных,... исключение: шаблоны), а в cpp - реализация. Так же #include "Source.cpp" писать нихарашо)

Сообщение от Роман Радер

Сейчас я делаю так: у меня ОДИН cpp файл и куча .h. У других видел кучу cpp файлов, поэтому и спросил.

Главное - качество, а не количество.

[ROD]

В заголовочных файлах должен быть только интерфейс (описание классов, функций, глобальных переменных,... исключение: шаблоны), а в cpp - реализация. Так же #include "Source.cpp" писать нихарашо)

Не понял. Если в .h только описание, а #include "Source.cpp писать не хорошо, где тогда описывать сами "тела функций" ?

К стати, а это хорошо или не очень, когда что-то инклудишь не в верху, а по мере возникновения необходимости в инклудивании чего-либо? (ну как с объявлением переменных)

[pu4koff]

Сообщение от ROD

Не понял. Если в .h только описание, а #include "Source.cpp писать не хорошо, где тогда описывать сами "тела функций" ?

Тело функции - есть реализация, т.е. в *.cpp файлах им место. А инклюдить "сипипишки" и не надо, ибо они компилятору "автоматом" посылаются для обработки, а уже по инклюдам в них находятся хедеры.

Сообщение от ROD

К стати, а это хорошо или не очень, когда что-то инклудишь не в верху, а по мере возникновения необходимости в инклудивании чего-либо? (ну как с объявлением переменных)

Лучше вверху, чтобы легче просматривалась зависимость отдельных модулей программы. Появится так по невнимательности циклическая зависимость (а она может быть не прямая: a <-> b, а через пятое колено: a -> b -> c -> a) модулей и ищи свищи потом почему не линкуется программа, а поймешь почему, так ищи этот злочастный инклюд по всему коду...

[Роман Радер]

ибо они компилятору "автоматом"

ну вот компилирую я main.cpp откуда оно знает что нужно еще f2.cpp компилить? все равно нужно проинклюдить...
а даже если и не нужно, то нафиг тогда несвязаные cpp файлы? есть один класс в f1.cpp, второй класс в f2.cpp. как создать их объекты в main.cpp если они не проинклюдены? будет ошибка про необъявленный идентификатор..
вывод - в main.cpp обязательно придется проинклюдить все остальные cppшки... или я не так понял

[Blade]

Сообщение от Роман Радер

есть один класс в f1.cpp, второй класс в f2.cpp. как создать их объекты в main.cpp если они не проинклюдены? будет ошибка про необъявленный идентификатор..

Как уже говорилось выше - создать файл f.h в котором будут объявлены соответствующие классы или прототипы нужных функций, а реализация этих функций может быть в файле *.cpp или *.c
Но вообще, нужно заметить, что все, что качается модульного программирование - условно. Никто не мешает вам писать все, например, в одном файле, или наоборот - каждую функцию в отдельном. Все это делается для удобства программиста. Вот и делайте как вам удобно

[pu4koff]

Сообщение от Роман Радер

ну вот компилирую я main.cpp откуда оно знает что нужно еще f2.cpp компилить?

Не знаю как это происходит в командной строке и как это делают другие среды, но Visual C++ "отправляет" компилятору все *.cpp файлы из проекта.
Там уже видит препроцессор #include "xxx.h" и, грубо говоря, вставляет на это место содержимое соответствующего файла. Именно поэтому *.срр файлы не надо защищать от повторного включения, в отличии от хедеров.
С защитой, при попытке повторного включения файла:

#ifndef XXX_H
#define XXX_H
...
#endif

после работы препроцессора, будет "пустота". Если же убрать защиту, то один и тот же код добавится вторично и компилятор будет в недоумении: "какой из этих одинаковых классов использовать?"

Сообщение от Роман Радер

а даже если и не нужно, то нафиг тогда несвязаные cpp файлы?

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

Сообщение от Роман Радер

есть один класс в f1.cpp, второй класс в f2.cpp. как создать их объекты в main.cpp если они не проинклюдены?

Описываем классы хоть в общем f.h или для каждого свой хедер создаем, а в срр пишем только реализацию методов. В main.cpp соответственно инклюдим этот хедер, а не f1.cpp и f2.cpp. Нам же тут главное, чтобы в main.cpp было известно о существовании класса, а его реализация безразлична.

[pavelstraut]

Не знаю как это происходит в командной строке и как это делают другие среды, но Visual C++ "отправляет" компилятору все *.cpp файлы из проекта.
Там уже видит препроцессор #include "xxx.h" и, грубо говоря, вставляет на это место содержимое соответствующего файла. Именно поэтому *.срр файлы не надо защищать от повторного включения, в отличии от хедеров.
С защитой, при попытке повторного включения файла:
Код:


#ifndef XXX_H
#define XXX_H
...
#endif

после работы препроцессора, будет "пустота". Если же убрать защиту, то один и тот же код добавится вторично и компилятор будет в недоумении: "какой из этих одинаковых классов использовать?"
Цитата:

МОжно об этом поподробнее,особенно о защите от многократного использования
почему ее не нужно ставить,ведб тогда будет сгенерирована ошибка
так же интересует как файлы в одном проекте инклудятся друг в друга
компилятор видит #include <.....h> и вставляет хедер а сипипишки как?

[pu4koff]

Сообщение от pavelstraut

МОжно об этом поподробнее,особенно о защите от многократного использования
почему ее не нужно ставить,ведб тогда будет сгенерирована ошибка

Ну её не нужно ставить только у *.срр. Хедеры надо защищать всегда, ну за исключением хитрого какого-то использования, которое будет работать при повторном включении файла.

Сообщение от pavelstraut

так же интересует как файлы в одном проекте инклудятся друг в друга
компилятор видит #include <.....h> и вставляет хедер а сипипишки как?

сипипишки инклюдить и не стоит. Если написать: #include "Source.cpp", то этот файл подключится ровно так, как и хедер, т.е. защищать тоже придется. Только вот никогда так не делают и потому никогда не защищают их от повторного включения. Компилятору на расширения в принципе по барабану. То, что дали ему для компиляции в качестве параметра командной строки - срр, то, что в инклюдах написано - хедер.
Компилятор на входе получает кучу сипипишек, берет первую, ищет все нужные хедеры, прописанные в инклюдах, собирает из всего этого некий объектный файл для внутреннего использования и так все сипипишки перебирает. Потом все эти объектные файлы компилятся уже в exe-шник.
Отдельно обращаем внимание, что объектные файлы создаются на каждый сипипишник, а не хедер (для хедеров вообще никаких временных файлов не создается и для каждой сипипишки он подключается и обрабатывается заново). т.е. к каждой сипипишке приписывается один и тот же код хедера. Защита от повторного включения защищает только от включения одного и того же кода в объектный файл, т.е. от ситуации:

// а.h
class A
{
...
};
// b.h
#include "a.h"
class B: public A
{
...
};
// main.cpp
#include "a.h"
#include "b.h"
...

Компилим main.cpp и получается в итоге вот такое:

// Вместо #include "a.h"
class A
{
...
};
//

// Вместо #include "b.h"
// Вместо #include "a.h"
class A
{
...
};
//
class B: public A
{
...
};
//

т.е. один и тот же класс присутствует в двух экземплярах, на что линкер будет ругаться.
Если добавить защиту от копирования, то второй инклюд просто удалится и вместо него никакой код не добавится.
Если же в проект добавить еще некий Source.cpp с кодом:

#include "a.h"
#include "b.h"
...

это уже будет другая единица компиляции и защита от повторного включения тут не спасёт. У объектного файла Source.cpp будут свои экземпляры a.h и b.h, а у main.cpp - свои.
Если мы в a.h добавим строку: "int a;", то прога не скомпилится, потому что в main'е будет создана эта переменная и в Source будет она создана и линкер не поймет какой именно экземпляр и где использовать. Если же этот код и скомпилится, то будет несколько экземпляров одной и той же переменной со всеми вытекающими непонятностями во время работы программы. Потому для глобальных переменных пишем в хедерах "extern int a;", а в сипипишках уже "int a;".
Смотрим на этот код:

// test.h
#ifndef INCLUDE_COUNT
#define INCLUDE_COUNT 1
#elif (INCLUDE_COUNT == 1)
#undef INCLUDE_COUNT
#define INCLUDE_COUNT 2
#elif (INCLUDE_COUNT == 2)
#undef INCLUDE_COUNT
#define INCLUDE_COUNT 3
#endif

// a.h
#include "test.h"
int getCount();

// a.cpp
#include "a.h"
int getCount()
{
  return INCLUDE_COUNT;
}

// main.cpp
#include <iostream>
#include "test.h"
#include "test.h"
#include "a.h"

using namespace std;

int main()
{
	cout << INCLUDE_COUNT << endl; // Выведет 3, т.к. 3 инклюда test.h (еще один из a.h Тянется)
	cout << getCount() << endl; // Выведет 1, т.к. из "a.cpp" выходит только 1 инклюд test.h

	getchar();
	return 0;
}

В общем хедер для каждого сипипишника обрабатывается заново и один и тот же макрос имеет разное значение в разных срр файлах

[Роман Радер]

эксперементальным путем понял что если в хедере
a.h

int func1(int k);
int func2(float f);

и в файле с таким же именем но расширением cpp - реализация
a.cpp

int func1(int k)
{
  return k*2;
}
int func2(int f)
{
  return f+2;
}

а в main.cpp

#include "a.h"
void main()
{
  func1();
}

то будет работать. значит достаточно подключить хедер а реализацию компилятор будет искать в cpp файле такого-же имени

верно??