Вот нарыл в одной умной книжке, автора звать Бьерн Страуструп
(для программистов на С++ это что-то "Ветхого Завета" если я правильно понял)

1.3.6 Модули

Программа С++ почти всегда состоит из нескольких раздельно
транслируемых "модулей". Каждый "модуль" обычно называется исходным
файлом, но иногда - единицей трансляции. Он состоит из последовательности
описаний типов, функций, переменных и констант. Описание extern позволяет
из одного исходного файла ссылаться на функцию или объект, определенные в
другом исходном файле . Например:

extern "C" double sqrt ( double );
extern ostream cout;

Самый распространенный способ обеспечить согласованность описаний
внешних во всех исходных файлах - поместить такие описания в специальные
файлы, называемые заголовочными. Заголовочные файлы можно включать во все
исходные файлы, в которых требуются описания внешних. Например, описание
функции sqrt хранится в заголовочном файле стандартных математических
функций с именем math.h, поэтому, если нужно извлечь квадратный корень из
4, можно написать:

#include <math.h>
//...
x = sqrt ( 4 );

Поскольку стандартные заголовочные файлы могут включаться во многие
исходные файлы, в них нет описаний, дублирование которых могло бы вызвать
ошибки. Так, тело функции присутствует в таких файлах, если только это
функция-подстановка, а инициализаторы указаны только для констант ($$4.3).
Не считая таких случаев, заголовочный файл обычно служит хранилищем для
типов, он предоставляет интерфейс между раздельно транслируемыми частями
программы.
В команде включения заключенное в угловые скобки имя файла (в нашем
примере - <math.h>) ссылается на файл, находящийся в стандартном каталоге
включаемых файлов. Часто это - каталог /usr/include/CC. Файлы, находящиеся
в других каталогах, обозначаются своими путевыми именами, взятыми в
кавычки. Поэтому в следующих командах:

#include "math1.h"
#include "/usr/bs/math2.h"

включаются файл math1.h из текущего каталога пользователя и файл
math2.h из каталога /usr/bs.

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

// header.h

extern char * prog_name;
extern void f ();

Файл main.c является основной программой:

// main.c

#include "header.h"
char * prog_name = "примитивный, но законченный пример";
int main ()
{
f ();
}

а строка печатается функцией из файла f.c:

// f.c

#include <stream.h>
#include "header.h"
void f ()
{
cout << prog_name << '\n';
}

При запуске транслятора С++ и передаче ему необходимых
файлов-параметров в различных реализациях могут использоваться разные
расширения имен для программ на С++. На машине автора трансляция и запуск
программы выглядит так:

$ CC main.c f.c -o silly
$ silly

примитивный, но законченный пример

$

Кроме раздельной трансляции концепцию модульности в С++ поддерживают
классы ($$5.4).

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




Я сделал всё что мог, кто может пусть сделает лучше.

Вот вам ещё оттуда же....
короче рудимент как я и говорил и можно жить и без этого прекрасно.

4.3 Заголовочные файлы

Типы одного объекта или функции должны быть согласованы во всех их
описаниях. Должен быть согласован по типам и входной текст,
обрабатываемый транслятором, и связываемые части программы. Есть
простой, хотя и несовершенный, способ добиться согласованности
описаний в различных файлах. Это: включить во входные файлы,
содержащие операторы и определения данных, заголовочные файлы,
которые содержат интерфейсную информацию.
Средством включения текстов служит макрокоманда #include,
которая позволяет собрать в один файл (единицу трансляции)
несколько исходных файлов программы. Команда

#include "включаемый-файл"

заменяет строку, в которой она была задана, на содержимое файла
включаемый-файл. Естественно, это содержимое должно быть текстом
на С++, поскольку его будет читать транслятор. Как правило, операция
включения реализуется отдельной программой, называемой препроцессором
С++. Она вызывается системой программирования перед собственно
трансляцией для обработки таких команд во входном тексте. Возможно
и другое решение: часть транслятора, непосредственно работающая
с входным текстом, обрабатывает команды включения файлов по мере их
появления в тексте. В той системе программирования, в которой
работает автор, чтобы увидеть результат команд включения файлов,
нужно задать команду:

CC -E file.c

Эта команда для обработки файла file.c запускает препроцессор
(и только!), подобно тому, как команда CC без флага -E запускает сам
транслятор.
Для включения файлов из стандартных каталогов (обычно каталоги
с именем INCLUDE) надо вместо кавычек использовать угловые скобки
< и >. Например:

#include <stream.h> // включение из стандартного каталога
#include "myheader.h" // включение из текущего каталога

Включение из стандартных каталогов имеет то преимущество, что имена
этих каталогов никак не связаны с конкретной программой (обычно
вначале включаемые файлы ищутся в каталоге /usr/include/CC, а
затем в /usr/include). К сожалению, в этой команде пробелы существенны:

#include < stream.h> // <stream.h> не будет найден

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

Определения типов struct point { int x, y; };
Шаблоны типов template<class T>
class V { /* ... */ }
Описания функций extern int strlen(const char*);
Определения inline char get() { return *p++; }
функций-подстановок
Описания данных extern int a;
Определения констант const float pi = 3.141593;
Перечисления enum bool { false, true };
Описания имен class Matrix;
Команды включения файлов #include <signal.h>
Макроопределения #define Case break;case
Комментарии /* проверка на конец файла */

Перечисление того, что стоит помещать в заголовочный файл, не является
требованием языка, это просто совет по разумному использованию включения
файлов. С другой стороны, в заголовочном файле никогда не должно быть:

Определений обычных функций char get() { return *p++; }
Определений данных int a;
Определений составных const tb = { /* ... */ };
констант

По традиции заголовочные файлы имеют расширение .h, а файлы,
содержащие определения функций или данных, расширение .c. Иногда
их называют "h-файлы" или "с-файлы" соответственно. Используют
и другие расширения для этих файлов: .C, cxx, .cpp и
.cc. Принятое расширение вы найдете в своем справочном руководстве.
Макросредства описываются в $$4.7. Отметим только, что в С++ они
используются не столь широко, как в С, поскольку С++ имеет определенные
возможности в самом языке: определения констант (const),
функций-подстановок (inline), дающие возможность более простой
операции вызова, и шаблонов типа, позволяющие порождать семейство
типов и функций ($$8).
Совет помещать в заголовочный файл определения только простых,
но не составных, констант объясняется вполне прагматической причиной.
Просто большинство трансляторов не настолько разумно, чтобы
предотвратить создание ненужных копий составной константы. Вообще
говоря, более простой вариант всегда является более общим, а значит
транслятор должен учитывать его в первую очередь, чтобы создать
хорошую программу.

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

Проще всего разбить программу на несколько файлов следующим
образом: поместить определения всех функций и данных в некоторое
число входных файлов, а все типы, необходимые для связи между
ними, описать в единственном заголовочном файле. Все входные
файлы будут включать заголовочный файл. Программу
калькулятора можно разбить на четыре входных файла .c:
lex.c, syn.c, table.c и main.c. Заголовочный файл dc.h будет
содержать описания каждого имени, которое используется более
чем в одном .c файле:

// dc.h: общее описание для калькулятора

#include <iostream.h>

enum token_value {
NAME, NUMBER, END,
PLUS='+', MINUS='-', MUL='*', DIV='/',
PRINT=';', ASSIGN='=', LP='(', RP=')'
};

extern int no_of_errors;
extern double error(const char* s);
extern token_value get_token();
extern token_value curr_tok;
extern double number_value;
extern char name_string[256];
extern double expr();
extern double term();
extern double prim();

struct name {
char* string;
name* next;
double value;
};

extern name* look(const char* p, int ins = 0);
inline name* insert(const char* s) { return look(s,1); }

Если не приводить сами операторы, lex.c должен иметь такой вид:

// lex.c: ввод и лексический анализ

#include "dc.h"
#include <ctype.h>

token_value curr_tok;
double number_value;
char name_string[256];

token_value get_token() { /* ... */ }

Используя составленный заголовочный файл, мы добьемся,
что описание каждого объекта, введенного пользователем, обязательно
окажется в том файле, где этот объект определяется. Действительно,
при обработке файла lex.c транслятор столкнется с описаниями

extern token_value get_token();
// ...
token_value get_token() { /* ... */ }

Это позволит транслятору обнаружить любое расхождение в типах,
указанных при описании данного имени. Например, если бы функция
get_token() была описана с типом token_value, но определена с
типом int, трансляция файла lex.c выявила бы ошибку: несоответствие
типа.
Файл syn.c может иметь такой вид:

// syn.c: синтаксический анализ и вычисления

#include "dc.h"

double prim() { /* ... */ }
double term() { /* ... */ }
double expr() { /* ... */ }

Файл table.c может иметь такой вид:

// table.c: таблица имен и функция поиска

#include "dc.h"

extern char* strcmp(const char*, const char*);
extern char* strcpy(char*, const char*);
extern int strlen(const char*);

const int TBLSZ = 23;
name* table[TBLSZ];

name* look(char* p, int ins) { /* ... */ }

Отметим, что раз строковые функции описаны в самом файле table.c,
транслятор не может проверить согласованность этих описаний по типам.
Всегда лучше включить соответствующий заголовочный файл,
чем описывать в файле .c некоторое имя как extern. Это может
привести к включению "слишком многого", но такое включение нестрашно,
поскольку не влияет на скорость выполнения программы и ее размер, а
программисту позволяет сэкономить время. Допустим, функция strlen() снова
описывается в приведенном ниже файле main.c. Это только лишний
ввод символов и потенциальный источник ошибок, т.к. транслятор
не сможет обнаружить расхождения в двух описаниях strlen() (впрочем,
это может сделать редактор связей). Такой проблемы не возникло бы,
если бы в файле dc.h содержались все описания extern, как первоначально
и предполагалось. Подобная небрежность присутствует в нашем примере,
поскольку она типична для программ на С. Она очень естественна
для программиста, но часто приводит к ошибкам и таким программам,
которые трудно сопровождать. Итак, предупреждение сделано!
Наконец, приведем файл main.c:

// main.c: инициализация, основной цикл, обработка ошибок

#include "dc.h"

double error(char* s) { /* ... */ }

extern int strlen(const char*);

int main(int argc, char* argv[]) { /* ... */ }

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

4.3.2 Множественные заголовочные файлы

Разбиение программы в расчете на один заголовочный файл больше
подходит для небольших программ, отдельные части которых не
имеют самостоятельного назначения. Для таких программ допустимо,
что по заголовочному файлу нельзя определить, чьи описания там
находятся и по какой причине. Здесь могут помочь только комментарии.
Возможно альтернативное решение: пусть каждая часть программы
имеет свой заголовочный файл, в котором определяются средства,
предоставляемые другим частям. Теперь для каждого файла .c будет
свой файл .h, определяющий, что может предоставить первый. Каждый файл
.c будет включать как свой файл .h, так и некоторые другие файлы .h,
исходя из своих потребностей.
Попробуем использовать такую организацию программы для
калькулятора. Заметим, что функция error() нужна практически во всех
функциях программы, а сама использует только <iostream.h>. Такая
ситуация типична для функций, обрабатывающих ошибки.
Следует отделить ее от файла main.c:

// error.h: обработка ошибок

extern int no_of_errors;

extern double error(const char* s);

// error.c

#include <iostream.h>
#include "error.h"

int no_of_errors;

double error(const char* s) { /* ... */ }

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

// table.h: описание таблицы имен

struct name {
char* string;
name* next;
double value;
};

extern name* look(const char* p, int ins = 0);
inline name* insert(const char* s) { return look(s,1); }

// table.h: определение таблицы имен

#include "error.h"
#include <string.h>
#include "table.h"

const int TBLSZ = 23;
name* table[TBLSZ];

name* look(const char* p, int ins) { /* ... */ }

Заметьте, что теперь описания строковых функций берутся из включаемого
файла <string.h>. Тем самым удален еще один источник ошибок.

// lex.h: описания для ввода и лексического анализа

enum token_value {
NAME, NUMBER, END,
PLUS='+', MINUS='-', MUL='*',
PRINT=';', ASSIGN='=', LP='(', RP= ')'
};

extern token_value curr_tok;
extern double number_value;
extern char name_string[256];

extern token_value get_token();

Интерфейс с лексическим анализатором достаточно запутанный. Поскольку
недостаточно соответствующих типов для лексем, пользователю
функции get_token() предоставляются те же буферы number_value
и name_string, с которыми работает сам лексический анализатор.

// lex.c: определения для ввода и лексического анализа

#include <iostream.h>
#include <ctype.h>
#include "error.h"
#include "lex.h"

token_value curr_tok;
double number_value;
char name_string[256];

token_value get_token() { /* ... */ }

Интерфейс с синтаксическим анализатором определен четко:

// syn.h: описания для синтаксического анализа и вычислений

extern double expr();
extern double term();
extern double prim();

// syn.c: определения для синтаксического анализа и вычислений

#include "error.h"
#include "lex.h"
#include "syn.h"

double prim() { /* ... */ }
double term() { /* ... */ }
double expr() { /* ... */ }

Как обычно, определение основной программы тривиально:

// main.c: основная программа

#include <iostream.h>
#include "error.h"
#include "lex.h"
#include "syn.h"
#include "table.h"

int main(int argc, char* argv[]) { /* ... */ }

Какое число заголовочных файлов следует использовать для данной
программы зависит от многих факторов. Большинство их определяется
способом обработки файлов именно в вашей системе, а не
собственно в С++. Например, если ваш редактор не может работать
одновременно с несколькими файлами, диалоговая обработка нескольких
заголовочных файлов затрудняется. Другой пример: может оказаться,
что открытие и чтение 10 файлов по 50 строк каждый занимает
существенно больше времени, чем открытие и чтение одного файла из 500
строк. В результате придется хорошенько подумать, прежде чем
разбивать небольшую программу, используя множественные заголовочные
файлы. Предостережение: обычно можно управиться с множеством, состоящим
примерно из 10 заголовочных файлов (плюс стандартные заголовочные
файлы). Если же вы будете разбивать программу на минимальные логические
единицы с заголовочными файлами (например, создавая для каждой структуры
свой заголовочный файл), то можете очень легко получить неуправляемое
множество из сотен заголовочных файлов.



Я сделал всё что мог, кто может пусть сделает лучше.

Я так чуствую - надо внести ясность.
Поэтому предлагаю начать с начала - с моего вопроса.

Если я пишу класс в С++, то описания находятся в заголовочном файле а сами ф-ии класса в файле *.cpp

Зачем и почему и можно ли это в С++ делать иначе?

Если бы это несло в себе какое-то рациональное зерно, то такие файлы были бы везде и в паскале и в бэйсике и в шарпе...., но нет зерна, просто рудимент из далёкого прошлого....

Вы чего, M234, с Луны свалились? Как это зерна нет? А в Паскале точно так же есть интерфейс модуля и есть его реализация. Они разбиты на две независимые части.

Вот здесь я вижу ошибку, да в паскале ЭТО тоже разделено, НО находится в одном файле, мой первоначальный вопрос был, зачем нужны ОТДЕЛЬНЫЕ заголовочные файлы,тем более что с помощью директивы инклуд"апапрю.х" вы просто склеиваете их вместе.

В дальнейшем дискуссия ушла в сторону рассуждений о том, а хорошо ли ЭТО держать всё вместе или надо непременно разделять...

Вот единстенный аргумент, который что-то объясняет

- для использования сторонних модулей нужны были их исходники (т.е. по крайнем мере .h файлы - что тоже не мало) - ясно что этот пункт MS и Co не нравился больше всего :)

По поводу интерфейсной части модуля, так в визуал студио она у меня всегда перед глазами в маленьком окошечке в углу экрана, где я могу посмотреть всё своё добро в удобной мне форме и как надо сгруппировано и отсортированно...

Кому нужен УМЛ, тот тоже без заголовочных файлов проживёт, см линк выше..


вы все еще считает, что интерфейсы C# и .h файлы служат одним целям :)

Нет не считаю, уже нет... :)

П.С. А "зерна" я попрежнему не увидел, в разделении модуля на 2 части...



Я сделал всё что мог, кто может пусть сделает лучше.

А в vi editor'е под UNIX или в ED/EDT под VAX/VMS Вам кодировать не доводилось? Поищите там Ваши окошечки.

Нет там окошечек, ничего там нет и жизни тоже :)

Я сделал всё что мог, кто может пусть сделает лучше.

Собственно по теме топика - это поколение Pepsi уже начинает раздражать:

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

А есть еще такие кулхацкеры образца 1950-х, которые программы на Си пишут в Ви, ХТМЛ-страницы верстают в блокноте, и говорят при этом: "Командная строка - рулез форевер, а всё что с окошечками - это от лукавого. Видовс маст дай!"

Слава Богу это вымирающий вид.
Будущее за "поколением пепси" !

Вот я и выбрал - программирование, а Вы - девелопмент

Нет уважаемый, это я программирование выбрал, программирование где удобные инструменты позволяют сосредоточится на главном - решение поставленной задачи оптимальным образом и в приемлимые сроки.
А ваши инструменты позволяют только применять принцип повторного исп-я кода, да и то методом "Копи-Пасте" :).


С уважением, ваше "поколение пепси"... :)


Я сделал всё что мог, кто может пусть сделает лучше.

Да все Ваши задачи известны наизусть: натянем на формочку контролов, создадим базу данных, одно к другому прикрутим - вот и всё...

Если что-то делается просто, то это не значит, что это делается плохо и наоборот применение ассемблера не гарантирует вам замечательного результата и даже наоборот кривое его применение грозит серьёзными проблемами. ВС и Ассемблер - это просто инструменты, как применишь - такой результат и получишь.

Я говорю о том, что к сожалению у Вас, поколение Pepsi, отсутствует понимание того, что жизнь есть и за пределами GUI. Насчёт программирования vs девелопмент - убери сейчас у Вас эти "удобные инструменты" и оставь один на один с голой Win32 API - много Вас выживет? Не думаю.

Нууу не совсем так, я помню на моём первом компе было 48кБ памяти и встроенный Бейсик. Я конечно потыркался с ним пару месяцев, быстро понял, что на таком оборудовании с Бейсиком каши не сваришь и можно только "хелло-ворльд" программы писать и.....
взялся за Ассемблер, да да а что было делать(?!) и знаете что, а ничего не помер, да думать надо много и преиущественно о всяких мелочах(очень важных впрочем), но это-то и плохо(в боьшинстве случаев) это отвлекает и надолго от того что ты хочешь в итоге сделать. Хотя ассемблер, тоже облегчает работу программиста, а истинный кайф это программирование в машинных кодах :).

Пожалуйста, не надо о том, в чём Вы ну ни винта не рубите. Лично я позволяю себе высказываться по Вашим инструментам потому, что помимо 8 лет под VAX и 3 под UNIX на старости лет получил 5 под VS. Так вот, с помощью "моих" инструментов на тех платформах создавались обьектные библиотеки, с которыми потом линковалась куча других программеров (около 20 - 30 чел, кфмн в основном). Вот такой вот "Копи-Пасте". А вот сколько дивелоперов (кроме Вас самого) повторно используют Ваш код?

Мне лучше знать, где я рублю, а где нет. (впрочем я совсем не обиделся :))

Я пишу для конечного пользователя и как и тысячи других программистов (в том числе кандидаты и доктора всяческих наук) использую код программистов майкрософт и других фирм. Ну и конечно никто не мешает мне создать новый контрол или библиотеку и распространить это через инет.(это поболе будет чем 20-30 человек..)

Вообще конечно смешно смотреть как вы используете слова VAX, UNIX и кфмн в качестве своего рода заклинаний, которые должны внушить благоговенный трепет бедным ламерам пишущим для виндовс :).

Я сделал всё что мог, кто может пусть сделает лучше.

для funikovyuri

:))

Нууу не совсем корректное сравнение. Всё было проще: Начав изучать шарп я познакомился с написанием кода (класса) "инлайн", т.е. без разделение его на 2е части и уж темболее без растаскивания на разные файлы. Мне показалось это более удобным и тогда у меня возник вопрос: Почему только сейчас? И что за этим кроется, лучше это, хуже ли в конечном итоге или всё равно?

Затем я услышал много аргументов "ЗА" разделение, сам кое-чего почитал и счёл эти аргументы не состоятельными (в том числе и про работу с УМЛ).

Единственное нормальное объяснене которое я нашёл:
Современные многопроходные компиляторы позволят написание кода "инлайн" (старые соответственно нет).

П.С. Я не сравнивал синтаксис, я сравнивал подходы к написанию кода, как мне кажется.

Я сделал всё что мог, кто может пусть сделает лучше.