Здравствуйте

Начал изучение c++, поэтому в специфичной терминологии еще плаваю. Помогите, пожалуйста, разобраться:

Хотелось функции хранить в отдельном файле и в основной подгружать только необходимые. Решил следующим образом

main.cpp - основной файл


func.cpp - здесь хранятся вызываемые функции


vars.cpp - здесь хранятся переменные


для компиляции использовал Borland C++ 5.6 for Win32 компилятор (из дистрибутива Borland C++ Builder)
bcc32 main.cpp func.cpp vars.cpp

А теперь, собственно, вопрос:
1. Действительно ли при компиляции в результирующий main.exe добавились только extern int test1(); extern char test4[]; extern int test5; или остальные функции и переменные из внешних файлов тоже там присутствуют?
2. При компиляции корневым (начальным) указывается первый .cpp в строке или порядок не важен?
3. Правильный ли способ я использую или можно каким-то другим образом хранить функции в отдельном файле и включать только необходимые? (#include, насколько я понял, включает файл целиком?)

не определено однозначно
хотя конкретно для BC можно узнать наверняка

не важен

extern-ы принято помещать в .h файл

Статические переменные с внешним связыванием(т.е. как у тебя) будут включены обязательно. По крайней мере, по Стандарту.

Это понятно. Интересовало - будут ли включены функции test2() и test3 из func.cpp. Сейчас посмотрел exe-шник, вроде нигде не присутствуют


Понял. Т.е.
func.h

main.h

*.h - это интерфейс, который должен быть реализован в одном из скомпилированных файлов, к которому он подключен?

yorm, 
в .h файле не должно быть (кроме случаев, когда ты знаешь, что делаешь) определений, только объявления
в твоем случае надо делать так

Спасибо за консультацию!

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

выходит, что LD туп   
не, на самом деле это довольно нетривиальная задача

А в чём нетривиальность заключается? 0_о 

archimed7592, 
скажем так, не нетривиальная, а доволно сложная   
представь себе набор объектных файлов, которые поступают на вход компоновщику
каков алгоритм его работы?
в случае LD в качестве алгоритма выступает скрипт, который ставит в соответствие секциям входных объектных файлов секциии выходного
если не смотреть на то, что на самом деле используется, а что нет, то все крайне просто: берется секция входного объектного файла и помещается по определенному смещению в выходной
если смотреть на факт использования, то для каждой секции входного объектного файла нужно найти символы, которые определены в ней
для каждого такого символа нужно находить все релокации в других объектных файлах, которые ссылаются на этот символ
если эти другие объектные файлы не являются контейнером для main(), то необходимо определить контекст релокации, т. е в контексте определения какого символа находится релокация и, определив, продолжить процесс рекурсивно
причем есть вероятность того, что этот процесс породит бесконечную рекурсию
кроме того, не факт, что символ, на который есть релокация в другом символе, определенном в модуле с символом main, действительно не используется

Цикличность графа отслеживать не судьба? 

На самом деле, если, в придачу, компилятор будет отслеживать зависимости(те что он может отследить - т.е. в пределах объектника) и вкладывать эту информацию в объектник, то компоновщику нужно будет решить элементарную задачу выявления зависимостей, которая, на самом деле, тривиальна .

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


вообщем, есть три файла: main.c, functions.S, routine.S
при компиляции получаем 3 объектных файла: main.o, functions.o, routine.o
подаем их на вход компоновщику и...
попробуй догадаться, почему конечная программа не будет работать, если компоновщик будет отслеживать зависимости по приведенному выше алгоритму  

Добавлено через 2 минуты и 47 секунд

как быть с callback-функциями?
не все так просто

что бы этого точно не было, нужно пользоваться пространством имен

Это сообщение отредактировал(а) warmonger_ - 20.1.2008, 23:14

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

пространства имен здесь не причем

Добавлено через 2 минуты и 53 секунды

  
прав