Форум программистов, компьютерный форум CyberForum.ru
Наши страницы

реализация класса в .h файле хорошо или плохо? - C++

Войти
Регистрация
Восстановить пароль
Другие темы раздела
C++ Ошибка с полем в классе http://www.cyberforum.ru/cpp-beginners/thread939514.html
Пишу класс.Сюда его выкладывать не хочу,ибо он достаточно обширный.В классе доступе private задаю поле дескриптора файла.Тоесть что-то типо того: Class Myclass { private: HANDLE file; ......
C++ Сообщения между win32 приложениями Как отправить сообщение (аналог системных типа WM_DESTROY только свои) и обработать приемником? приёмник это обычное консольное win32 приложение(когда в визуале пустой проект win32 создаешь) http://www.cyberforum.ru/cpp-beginners/thread939505.html
Как назвать классы? C++
Сразу замечу, что дело происходит в 2D без физики, как таковой. 1) У меня есть классы: Mixer - звуковой движок Graphics - графический движок У звукового движка есть базовый класс: ...
C++ Не удается подключить к приложению gtest и свою статическую либу VS 2010
Здравствуйте, господа. Возникла проблема с линкером в VS 2010 после подключения к консольному приложению собственной же статической библиотеки. В солюшене 2 проекта: 1 - статическая библиотека, 2...
C++ Консоль для ведения логов http://www.cyberforum.ru/cpp-beginners/thread939483.html
Не уверен, что пишу туда, куда нужно, но есть только один способ узнать. Интересуют существующие решения по сабжу. Требования простые: - Минимум зависимостей - Цветной текст и фон - Динамические...
C++ Крутящееся колесо Может ли кто написать (срочно) программу крутящееся колесо, исходник чтобы был с комментариями. подробнее

Показать сообщение отдельно
Evg
Эксперт CАвтор FAQ
17953 / 6184 / 413
Регистрация: 30.03.2009
Сообщений: 16,974
Записей в блоге: 27
19.08.2013, 23:13
Цитата Сообщение от Убежденный Посмотреть сообщение
Скажите, как давно Вы последний раз работали с этим режимом ?
В районе 2000 года (наверное даже пораньше). Интеловским компилятором не пользовался. Имею примерное представление о том, как устроен режим в gcc. Нынешнее устройство режима gcc в общей концепции совпадает с тем, с чем я работал 10 лет назад. Исхожу из того, что интеловский компилятор ведёт себя примерно так же. Потому что в конечном итоге вся межмодульная компиляция сводится к тому, что N файлов объединяются в один на уровне промежуточного представления

Цитата Сообщение от Убежденный Посмотреть сообщение
Время сборки увеличивается, но далеко не в такой прогрессии, как Вы указали.
Например, беру свой текущий проект: примерно 500 cpp-файлов, сборка под x86/amd64.
Общее время сборки порядка 3 минут (на Core-i5 2500). При этом треть этого времени составляет
сборка драйверов и компонентов, не относящихся к C++ и IPO. Да, и я имел дело с header-only
библиотеками, при подключении которых время сборки увеличивалось чуть ли не на порядок.
Не давая, по сути, ничего взамен. Ну кроме простоты сборки, разумеется, это вне вопросов
Надеюсь, что правильно понял описанное. Что из себя представляют эти 500 файлов в плане inline. Т.е. насколько глубоко построено дерево вызовов между модулями? Эффект по производительности от межмодульного режима в рамках проекта (без библиотек) по отношению к модульному замерялся? Я почему спрашиваю - коль скоро ты непосредственно с этим работаешь, то тебе не составит большого труда сделать замер. 3 минуты компиляции меня сильно смущают. Либо там файлы короткие, либо инлайн не глубокий (и, соответственно, не сильно эффективный).

Цитата Сообщение от Убежденный Посмотреть сообщение
Доказательства "плохости" есть ? Если нет - значит, ни о чем
Опять-таки на руках нет. Когда с этим работал непосредственно - было их хоть отбавляй. На коммерческих компиляторах от intel'а и sun microsystems. gcc в те времена ещё слабоват по производительности был, а потому его производительность не мерили. Методика была простая: брались стандартные тестовые пакеты spec92 и spec95, мерили на них производительность на ref-данных. Потом брались реальные задачи, которые работают в пакетном режиме и для которых сравнительно просто померить производительность. Это были sun'овские программы типа архиваторов, компиляторов и всякой подобной лабуды, которые свободно не распространялись, а следовательно, для компилятора это были условно неизвестные задачи. Практически по всем задачам производительность существенно отличалась от того, что было замерено на spec'ах. По тем временам в spec'ах разрешалось подавать дофига произвольных опций, а потому все компиляции spec'ов проводились в специально подобранных пиковых режимах, которые годами вылизывались у разработчиков компиляторов. Как только мы переключаемся на реальную задачу и базовые режимы (без всяких тонких настроек, которые нужно очень долго вылизывать), производительность сразу же резко начинала отличаться.

Моё мнение, что межмодульные режимы - это в том числе и продолжение тех тенденций в погоне за публикуемыми цифрами

Цитата Сообщение от Убежденный Посмотреть сообщение
А знаете, в чем прелесть IPO ? В том, что для его использования не нужно прикладывать
никаких усилий. Он просто включен по умолчанию. Думаю, большинство пользователей, особенно
начинающих, вообще не знают, что их компилятор использует IPO. И тем не менее, получают
все выгоды от него
Чтобы не завязнуть в терминологии, я просто называю этот режим межмодульным. Термином IPO обычно называют межпроцедурные оптимизации (inter-procedural optimisations), ты его упомянул в названии режима (ссылка там не открылась), поэтому я подумал, что таким термином они назвали именно режим с межмодульными оптимизациями. Помодульный IPO нас не интересует, только межмодульный

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

Цитата Сообщение от Убежденный Посмотреть сообщение
Ну а неудобство... В чем оно ?
В том, что модификация одного файла *.cpp (т.е. не хидера) вызывает перекомпиляцию всего проекта. Заявленные тобой 3 минуты на проект из 500 файлов, как я уже говорил, меня смущают. Когда руки доберутся, проверю всё-таки на gcc

Цитата Сообщение от Убежденный Посмотреть сообщение
Ну так может пора ему уже на свалку, этому инлайнингу, раз он не играет существенной роли в оптимизации ?
Ну дак если есть счётная задача на Си++, написанная при помощи stl-контейнеров с использованием пользовательских классов (типа список из экземпляров класса MyClass), то взять и скомпилировать с включенным и выключенным инлайном. Разница будет

Цитата Сообщение от Убежденный Посмотреть сообщение
Это совсем не довод
Для тебя, сидящего на одной архитектуре, не довод. Для тех, кто сразу де пишет программы под несколько платформ - довод

Цитата Сообщение от Убежденный Посмотреть сообщение
Да пожалуйста - разные версии хидера и библиотечного файла. Или разные определения одного и того же метода в h и cpp. Это не во всех ситуациях отслеживается компилятором, а потом такую ошибку можно искать очень долго. При единообразном подходе (реализация или только в cpp, или только в h) она менее вероятна
Эта проблема слишком искусственная. Возникает только в том случае если *.cpp не подключает соотвествующий *.h. Другими словами, нужно иметь очень кривые руки. Проблема того же порядка, что использование указателей. Тот, кто умеет ими пользоваться - будет пользоваться и радоваться жизни, кто не умеет - будет огребать геморрой с утра до ночи

Цитата Сообщение от Убежденный Посмотреть сообщение
Я имел в виду, что писать код, заранее прикидывая степень его "заинлайненности" -
это преждевременная оптимизация
А не надо прикидывать. Нужно просто взять за правило, что всё короткое (Set, Get, перегруженные операторы, конструкторы-деструкторы) нужно делать инлайном и выносить в хидера. А понадобитя оно, или нет - это забота компилятора. Понятно, что есть ряд случаев, когда конструкторы или операторы оказываются нетривиальными и большими и незачем их вытаскивать в хидера

Цитата Сообщение от Убежденный Посмотреть сообщение
Все они поддерживают IPO уже не первый год, поэтому не вижу смысла искать здесь причины, чтобы его не использовать
Для меня самая главная причина, почему не нужно использовать межмодульные оптимизации - это слишком долгая пересборка. После озвученных тобой цифр всё-таки попробую поэкспериментировать на gcc. В твой результат мне не верится. Точнее, верится, но только в том случае, когда межмодульный режим не даёт прироста производительности
0
 
КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Рейтинг@Mail.ru