C/C++ инклюд

Тема в разделе "ASM, С/С++, Delphi, Java", создана пользователем Darkness, 16 май 2014.

Статус темы:
Закрыта.
  1. Darkness

    Darkness Постоялец

    Регистр.:
    21 янв 2013
    Сообщения:
    146
    Симпатии:
    69
    Во многих примерах можно часто встретить следующую схему инклюда.
    Реализация:
    Код:
    /* myprogram.c */
    #include "myprogram.h"
    int div(int a, int b) {
    	return a / b;
    }
    Заголовок описания реализации:
    Код:
    /* myprogram.h */
    int div(int, int);
    Но в главном файле почему то инклюдится описание реализации, то есть заголовочный файл myprogram.h, но не сама реализация.
    Код:
    /* main.c */
    #include "myprogram.h"
    int c;
    c = div(4, 2);
    Вопрос почему?
     
  2. Darkness

    Darkness Постоялец

    Регистр.:
    21 янв 2013
    Сообщения:
    146
    Симпатии:
    69
    Ну что же, никто не ответил, пожалуй отвечу я.
    Миф о том, что компиляторы подхватят файлы кода при подключении только одних заголовочных файлов основывается на том, что во многих студиях файлы в проекты можно инклюдить в настройках проекта, то есть в самом редакторе проекта.
    На самом деле при добавлении файлов реализации в студию и подключение только заголовочных файлов в главном файле, студия создаст файл конфигурации сборки и запишет туда отдельно все имена файлов с реализацией исходников, при компиляции все файлы будут транслироваться отдельно и только потом сливаться в один бинарник линкером. Что в принципе правильно, особенно это ощутимо при отладке, так как данный способ ускоряет сборку проекта, потому что те файлы которые уже были раз скомпилированные и их исходный код не был с этого момента модифицирован не перекомпилируются и передаются сразу в линкер.
    Но это может отразится на глобальной и межпроцедурной оптимизации, так как большая часть оптимизация происходит на этапе трансляции, в следствии чего при релиз сборке лучше проинклюдить все файлы с реализацией в главном файле напрямую, это замедлит процесс компиляции и потребует для этого больше ресурсов, как памяти, так и нагрузка на CPU, но это улучшить оптимизацию программы в целом, так как при оптимизации весь код будет обрабатываться сразу целиком.
     
    latteo нравится это.
  3. Darkness

    Darkness Постоялец

    Регистр.:
    21 янв 2013
    Сообщения:
    146
    Симпатии:
    69
    На самом деле, многие не используют межпроцедурную оптимизацию и тем более глобальную, зачастую оптимизации кода уделяется минимальное внимание или даже вообще не уделяется, все полагаются на компилятор и считают что компилятор сделает все сам, но это не так, зачастую по умолчанию компилятор работает в режиме совместимости со старыми архитектурами процессоров, многие флаги не используются и все собирается с флагом -O0, максимально с -O1 и без векторизации кода, ко всему последнее время я стал замечать, что у многих релиз Debug от релиза Release отличается только по названию.
     
    latteo нравится это.
Статус темы:
Закрыта.