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

Начал изучение 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 секунды

  
прав

Извините, сказал не подумавши.  

А какая с ними проблема? 


Да ладно, если больно надо будет - добавят в формат что нужно. Или есть какая-то резкая необходимость использовать именно специфированный кем-то там(кем?) формат?

PE специфицирован
ELF тоже


как ты такое отследишь?

  


Добавлено через 3 минуты и 38 секунд
так что с примером?   
его фишка в том, что если компоновщик будет отслеживать зависимости, то в выходной файл не будет включена функция routine, что приведет к непредсказуемым последствиям


Это сообщение отредактировал(а) MAKCim - 21.1.2008, 10:28

А компилятор разве генерирует PE или ELF? 
Я же говорил о том, что компилятор будет вкладывать информацию в объектники .



Очень просто: если линкуется с флагом -rdynamic, то включать все глобальные ф-ции с внешним связываением вне зависимости от того, используются они или нет . Ежу понятно, что из dll/so ничего выкидывать не нужно, ибо использоваться оно будет внешними программами.



А ничего... Я тебе говорю о С++(С), а не об ассемблере. В случае с ассемблером - просто включать весь модуль полностью, ибо реверсить асм вредно для здоровья .

объектные файлы являются форматными PE или ELF файлами
ELF формат, к примеру, специфицирует объектные, перемещаемые, исполняемые файлы, а также файлы динамических библиотек
с PE то же самое

DLL и SO тут вообще не причем
я просто привел один из способов вызова функции foo(), которая определена в отдельном модуле
причем компоновщик в этом случае просто не в состоянии определить, что foo на самом деле используется


ты наверное немного не в теме   
компоновщик работает только с объектными файлами
а по ним невозможно определить, как они были получены: компиляцией кода на ЯВУ или трансляцией ассемблерного кода
вот есть две эквивалентные программы

и

на выходе мы получим 2 объектных файла и невозможно будет определить, что один из них получен из исходника на ассемблере

Понятно, и тем не менее: объектники не используются дальше, чем до передачи их линкеру, т.е. можно немного усовершенствовать формат от чего никто не пострадает, разве нет?



Отлично, но чтобы упомянутый тобою способ работал нужно собрать исполняемый файл в таком режиме, когда все сущности с внешним связыванием засовываются в специальную таблицу экспорта, т.е. в дальнейшем исполняемый файл можно использовать как dll/so т.е. принципиальной разницы нет, так?



Возможно я и не в теме , но компилятор точно знает с чем он работает(асм или С/C++) и если он в состоянии(т.е., если он работает с C/C++), то ничто не мешает ему добавить эту информацию в объектник. Если же этой информации нет(т.е. компилятор был не в состоянии её добавить), то линкер вправе работать "по старинке".

хорошо, какие конкретно дополнительные данные ты предлагаешь помещать в объектный файл?

не понял
здесь обычный исполняемый файл, который собирается из 2-х модулей
в первом определена main(), во-втором - foo()
также есть ссылка на dlopen()/dlsym() из libdl.so
если компоновщик будет пытаться избавиться от ненужного "мусора", то в этот "мусор" попадет и foo(), которая на самом деле используется, но на которую нет прямой ссылки из объектного файла, где определена main()

ответь на первый вопрос

Для каждой ф-ции: список сущностей от которых зависит данная ф-ция(как внутримодульных, так и внешних). Причём, если "нужная" ф-ция заинлайнена, то от неё мы не зависим.


Не совсем обычный - он компонуется с ключем -rdynamic, а иначе он работать не будет, даже если foo не будет выкинута компоновщиком... разве нет?

Вообще то и gcc (точнее ld) и BCB давно умеют линковать только нужные функции в исполняемый файл. Достигается это очень просто - каждая функция помещается компилятором в свой собственный сегмент кода (отдельный от всех других). Линкер на этапе сборки выкидывает сегменты, к меткам, описанным в которых, нет ссылок.
Кстати, этот процесс во многом аналогичен линковке со статическими библиотеками, что есть вообще везде с самого начала.

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

Добавлено через 1 минуту и 38 секунд

да, все верно
но файл все равно останется исполняемым, только с расширенной таблицей .dynsym

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

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

Добавлено через 1 минуту и 31 секунду
вообщем, если подытожить, задача исключения сложна, но решаема
я в принципе обратного и не утверждал

Так, Макс, блин, кому-то из нас двоих однозначно пора спать .

Ты спросил:
Я тебе ответил: отслежу по ключику -rdynamic. Если он есть, то добавляем все ф-ции вне зависимости от их реальной используемости(точно так же, как если бы мы собирали .so).


Теперь ты мне говоришь:С моей стороны вопрос: а где я сказал, что что-то исключается? 

---------------------------------------------------------
Я, на всякий случай напомню предмет нашей беседы: тривиальна или нетривиальна задача исключения ненужного кода. Т.е. разговариваем мы с тобой о неком вымышленном тулчайне, в котором такая возможность будет и пытаемся понять возможен ли такой тулчайн в реальности, таким образом, даже если я говорю "что-то там куда-то там исключается", я имею в виду мой вымышленный компоновщик. Угу?

Добавлено через 49 секунд
Или не угу? 

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

Вот даже как . Хорошо ты подытожил, красиво .
Давай я тоже подытожу: я не увидел ни NP-полноты задачи, ни необозримого множества ньансов, которые нужно предусмотреть, так что задача классическая: есть три ф-ции(A, B, C), причём A зависит от B, а B зависит от C, значит A зависит от B и С .

рано   

да


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

вот
с этого и надо было начинать
тогда все стало на свои места   

это теория
она абстрагирует от деталей, в которых обычно и кроются сложности
если все так просто, почему этого до сих пор нет в LD или других компоновщиках (хотя про другие не могу дать 100%-ой гарантии)

А я, с Вашего позволения, пойду подремлю .


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

Обычно я утверждаю то, что знаю   
BCB 6.0
u2.cpp

U1.cpp

Ассемблер (выдержка) для U2.cpp:

Обратите внимание на директиву @func0$qv    segment virtual
Результат - функции func1 в выходном exe'нике нет, желающие могут убедится лично (см атач)

Что касается gcc - то он тоже делает отдельные сегменты и выкидывает ненужные, но только если его попросить:
g++ -fdata-sections -ffunction-sections -Wl,--gc-sections
qq.cc

qq.s

К сожалению мне не удалось заставить ld под cygwin'ом обработать --gc-sections, вероятно слишком древняя версия gcc (3.4.4), если будет желание - могу попробовать на работе, там вроде есть 4.х


Присоединённый файл ( Кол-во скачиваний: 2 )
 p2.rar 5,65 Kb

xvr, 
да, с LD я оказался не прав
признаю свою ошибку
не сопоставил --gc-sections LD с -ffunction-sections GCC
вместе они дают нужный результат
держи заслуженный плюс, а я  

Добавлено через 2 минуты и 51 секунду
archimed7592, 
тебе тоже плюс за остаивание позиции