Вопрос глупвй,но я пытаюсь с этим разобраться уже давно так что не бейте меня, а лучше поделитесь опытом...
Проблемма такая: я не могу понять как происходит компиляция когда используется много файлов cpp и h Мне приходится просто наугад вставлять #include "***.h" где попало, а потом проверять компилится или нет Вот например есть два класса в четырех файлах First.cpp First.h Second.cpp Second.h и файл Main.cpp с функцией WinMain
в обоих классах используется объекты из файла d3d8.h, вот как в них подключены заголовочные файлы:
..да в First.h используется Second.h
First.cpp:

#include <windows.h>
#include <D3D8.h>
#include "Second.h"
#include "First.h"

Second.cpp

#include <Windows.h>
#include <D3D8.h>
#include "Second.h"

Main.cpp

#include <windows.h>
#include "First.h"

Вот не компилются По каким правилам они должны компилится?! Компилятор VC++

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

...

Приведи сообщения компилятора, а еще лучше — минимальный код.

ЗЫ
сильно подозреваю, что в хедерах отсутствуют "защитники"

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

TB>Вопрос глупвй,но я пытаюсь с этим разобраться уже давно так что не бейте меня, а лучше поделитесь опытом...
Если используеться клас описаный в заголовке — включаешь его.
если же только указатель, то пишешь class ...; вроде всё.
если получаеться что в одном заголовке нужно что то из первого, а первому из второго — напрягаешь извилину и правишь, что бы такого не было...

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

TB>Вот не компилются По каким правилам они должны компилится?! Компилятор VC++

Используй следующее 2 простых правила, и забудь о своих проблемах:

1. В каждый хидер вставляй страж:

//myheader.h
#ifndef __MYHEADER_H__
#define __MYHEADER_H__

//тут твой код

#endif //__MYHEADER_H__

2. Все хидеры должны быть самодостаточными, тоесть он должен включать все хидеры, необходимые для его компиляции

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

ssm>Используй следующее 2 простых правила, и забудь о своих проблемах:

ssm>1. В каждый хидер вставляй страж:

ssm>

ssm>//myheader.h
ssm>#ifndef __MYHEADER_H__
ssm>#define __MYHEADER_H__

ssm>//тут твой код

ssm>#endif //__MYHEADER_H__
ssm>

ssm>2. Все хидеры должны быть самодостаточными, тоесть он должен включать все хидеры, необходимые для его компиляции

Ну я включаю эти дефайны, а насчет второго правила: я там в примере показал, они все самодостаточные, ведь в main.cpp нужен только First.h, а он не компилится без d3d8.h и second.h, хотя они нужны только в First.cpp

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

ssm>Используй следующее 2 простых правила, и забудь о своих проблемах:

... до поры-до времени.

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

TB>Ну я включаю эти дефайны, а насчет второго правила: я там в примере показал, они все самодостаточные, ведь в main.cpp нужен только First.h, а он не компилится без d3d8.h и second.h, хотя они нужны только в First.cpp

Тут ты немного непонял, вот в общем виде(будет работать всегда):

//first.h 
#ifdef __first_h__
#define __first_h__

#include <windows.h>     //если для декланации класса First надо windows.h
#include <D3D8.h>        //если для декланации класса First надо D3D8.h
#include "second.h"      //если для декланации класса First надо second.h

//декланация класса First

#endif //__first_h__

//second.h
#ifdef __second_h__
#define __second_h__
#include <windows.h>     //если для декланации класса Second надо windows.h
#include <D3D8.h>        //если для декланации класса Second надо D3D8.h

//декланация класса Second

#endif //__second_h__

//First.cpp 
#include "First.h"
#include <windows.h>     //если для реализации класса First надо windows.h
#include <D3D8.h>        //если для реализации класса First надо D3D8.h
#include "second.h"      //если для реализации класса First надо second.h

//реализация класса First

//Second.cpp
#include "Second.h"
#include <windows.h>     //если для реализации класса Second надо windows.h
#include <D3D8.h>        //если для реализации класса Second надо D3D8.h

//реализация класса Second

//Main.cpp
#include <windows.h>     //если для реализации main надо windows.h
#include <D3D8.h>        //если для реализации main надо D3D8.h
#include "second.h"      //если для реализации main надо декларация Second
#include "first.h"       //если для реализации main надо декларация Second

int main(){
  //...
  return 0;
}

Давай файлы, тогда будет без "если"

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

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

ssm>Используй следующее 2 простых правила, и забудь о своих проблемах:

А>... до поры-до времени.

сказал А говори и B, или это ты о precompiled headers?

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

ssm>Используй следующее 2 простых правила, и забудь о своих проблемах:

А>... до поры-до времени.

ssm>сказал А говори и B, или это ты о precompiled headers?

В достаточно изощренных случаях можно придти к тому, что эти правила работать перестанут. Тогда придется сесть и с карандашиком повычерчивать зависимости между именами. На БОЛЬШОМ ватмане.

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

А>В достаточно изощренных случаях можно придти к тому, что эти правила работать перестанут.

Пример!!!

А>Тогда придется сесть и с карандашиком повычерчивать зависимости между именами. На БОЛЬШОМ ватмане.

Я предпочитаю с карандашиком садиться ПЕРЕД реализацией, а не когда припечет и необходимо в дверь через форточку залазить

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

ssm>Пример!!!

Понимаешь, нередко может случиться так, что два-три класса (или шаблона) очень сильно зависят друг от друга, причем обращаясь к членам друг друга.

Когда у тебя все объявления — в .h, а определения — в .cpp, все просто. Но, во-первых, бывает так, что объекты имеют методы настолько крохотные, а требования к быстродействию настолько серьезны, что хочется применять вставку по месту (inlining). А во-вторых, шаблоны — они еще могут добавить путаницы в такой ситуации.

Впрочем, я написал, что это довольно изощренная ситуация. Разрешается она легко, но от заповедей приходится отступать.

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

TB>Ну я включаю эти дефайны, а насчет второго правила: я там в примере показал, они все самодостаточные, ведь в main.cpp нужен только First.h, а он не компилится без d3d8.h и second.h, хотя они нужны только в First.cpp

ssm>Тут ты немного непонял, вот в общем виде(будет работать всегда):

ssm>Давай файлы, тогда будет без "если"

А, ну так у меня работает, только мне говорили что в сами заголовочные файлы включать другие файлы нехорошо

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


TB>А, ну так у меня работает, только мне говорили что в сами заголовочные файлы включать другие файлы нехорошо

Срочно уволить!!!

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


А>Понимаешь, нередко может случиться так, что два-три класса (или шаблона) очень сильно зависят друг от друга, причем обращаясь к членам друг друга.

А>Когда у тебя все объявления — в .h, а определения — в .cpp, все просто. Но, во-первых, бывает так, что объекты имеют методы настолько крохотные, а требования к быстродействию настолько серьезны, что хочется применять вставку по месту (inlining). А во-вторых, шаблоны — они еще могут добавить путаницы в такой ситуации.

А>Впрочем, я написал, что это довольно изощренная ситуация. Разрешается она легко, но от заповедей приходится отступать.

Давай пример!, тем более если всего "два-три класса (или шаблона)"...
А то разглогольствовать мы все мастера

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

ssm>Давай пример!, тем более если всего "два-три класса (или шаблона)"...

Эге, разбежался! Во-первых, я не имею права публиковать имеющийся у меня в разработке код. Во-вторых, писать пример, воспроизводящий ситуацию, мне лень , потому что, и это в-третьих, он будет довольно велик.

Что ты так волнуешься? Можно подумать, что правила декомпозиции кода (h-cpp) священны?

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

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

ssm>Давай пример!, тем более если всего "два-три класса (или шаблона)"...

А>Эге, разбежался! Во-первых, я не имею права публиковать имеющийся у меня в разработке код. Во-вторых, писать пример, воспроизводящий ситуацию, мне лень , потому что, и это в-третьих, он будет довольно велик.

Однозначно

А>Что ты так волнуешься?

Я волнуюсь когда мне денег на пиво недостает, либо на рыбалке.

А>Можно подумать, что правила декомпозиции кода (h-cpp) священны?

Уверуй

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

TB>А, ну так у меня работает, только мне говорили что в сами заголовочные файлы включать другие файлы нехорошо

Зря говорили.
Каждый файл (будь то h или cpp) должен быть самодостаточен.

Если тебе нужно воспользоваться файлом abc.h, то ты не обязан помнить, что для этого ты должен в правильном порядке (!) включить еще до дури файлов.
А если содержимое abc.h поменяется, и он станет требовать включения еще чего-нибудь... Не переписывать же все исходники, где он упомянут.

То же самое касается дефайнов. Желательно, чтобы дефайн был или глобальным (и определялся в сборщике проекта — т.е. *.dsp или makefile), или объявлялся по месту использования (например, во включаемом заголовочнике).
Местный дефайн, влияющий на заголовочник

#define XXX yyy

#include "abc.h" // в нем используется XXX

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

Здравствуйте
Ворос по теме — как лучше организовать проект ?
1. определение и реализация класса в одном файле *.h
2. определение и реализация класса в двух файлах *.h & *.cpp

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

ssm>1. В каждый хидер вставляй страж:

а что вы думаете насчет

#pragma once

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

K_>а что вы думаете насчет

K_>

K_>#pragma once
K_>

Такой конструкции в переносимом Си/Си++ нет.