6 / 6 / 4
Регистрация: 13.10.2012
Сообщений: 101
|
|
1 | |
реализация класса в .h файле хорошо или плохо?17.08.2013, 21:48. Показов 15003. Ответов 61
Метки нет (Все метки)
все знакомые мне ide разделяют класс на два файла: .h с описанием и .cpp с кодом, но, например, в boost .hpp файлы почти всегда содержат и реализацию классов, т.е. так тоже можно. так в чем тогда разница и когда какой способ нужно применять? заранее благодарен
0
|
17.08.2013, 21:48 | |
Ответы с готовыми решениями:
61
Такой способ создание экземпляра класса хорошо или плохо? Многопоточность - хорошо или плохо? Google: хорошо или плохо? Ссылки - хорошо или плохо? |
1500 / 1146 / 165
Регистрация: 05.12.2011
Сообщений: 2,279
|
|
17.08.2013, 23:41 | 21 |
вы пишите код без ошибок? это очень круто.
вы пишите сразу оптимальный код? это тоже очень круто. вам не приходится писать какие-то временные варианты для проверки какой либо реализации с целью отрефакторить, оптимизнуть, улучшить дебажность на время? не знаю круто это или нет. все это мне часто приходится делать при устаканевшемся публичном интерфейсе класса.
0
|
17.08.2013, 23:47 | 22 |
Да, я и сам собой иногда горжусь.
А вот тут как никогда удобна заголовочная реализация. Я вижу смысл в разделении на .h и .cpp в случае окончательного варианта при больших объемах кода.
0
|
Higher
|
|
18.08.2013, 19:50 | 23 |
Если писать реализацию в цпп, то будет быстрее рекомпиляция, если в хедерах - будет быстрее рантайм за счет инлайнинга. В принципе, можно инлайнить и на стадии линковки, но чем больше становится кода в проекте, тем дороже это удовольствие.
0
|
73 / 73 / 18
Регистрация: 29.11.2011
Сообщений: 356
|
|
19.08.2013, 05:58 | 24 |
Один и тот же код из хедера скомпилится столько раз сколько раз он включен в разные cpp файлы, не? Это как-то не правильно.
0
|
979 / 196 / 33
Регистрация: 26.09.2012
Сообщений: 2,041
|
|
19.08.2013, 09:58 | 25 |
Правильно, если реализацию класса напишешь в .h файле то и что то изменишь то придется все файлы перекомпилировать которые включают этот .h файл в новые объектный код. Так в gcc. А в других компиляторах хз. как.
0
|
castaway
|
19.08.2013, 11:00
#26
|
Не по теме: Складывается такое чувство, что все поголовно пишут проекты в миллион строк и сотни файлов, и компиляция проходит минут по 30, а если вынести реализацию в заголовок то и все 30.5 минут...
1
|
19.08.2013, 11:41 | 29 |
Дело не в полной компиляции проекта, а как раз таки в частичной. Если реализация какого-нибудь очень популярного класса находится в заголовочном файле, то после изменения одной строки в этой реализации, необходимо будет пересобирать практически каждый объектный файл. В обратном случае достаточно будет пересборки только одного объектного файла. А вот тут уже все зависит от размеров проекта. И даже если сборка всего проекта занимает 5 минут, то это все равно несоизмеримо долго по сравнению со сборкой одного файла.
Опять же, make не настолько умен, чтобы самостоятельно определить зависимости и не способен пересобрать все зависимые файлы. Это, в свою очередь, порождает весьма неприятное поведение, когда в один объектный файл заинлайнена уже новая версия класса, а в некоторые другие еще старая. Как говорится, счастливой отладки. Тот факт, что директива #include просто подставляет содержимое указанного файла это давно известная проблема в мире C++.
1
|
19.08.2013, 11:54 | 30 |
fasked, это все прекрасно понятно. Если внимательно прочитать все мои сообщения, то можно легко понять что речь идет о частном случае, когда проект небольшой, когда класс не популярный. Практика показывает что это намного удобней, при этом не замечаешь разницу в миллисекундах, потраченных на сборку проекта.
0
|
19.08.2013, 12:23 | 31 |
Почему в Си++ реализации классов выносят в заголовочные файлы? Все очень просто. Тело метода класса, определённое внутри описания класса, является inline. Реализации многих шаблонов (в том числе и стандартных контейнеров) основаны на том, что после инстанциации шаблона компилятор видит все конструкторы, деструкторы, методы и весь тот хлам, что подцепится в процессе инстанциации. Дальше компилятор сделает длинный паровоз из inline'ов, после чего код, расположенный в тексте в виде 100500 различных функций и методов, в машинном коде окажется коротким и быстрым. Именно ради производительности разработчики Си++ особое внимание уделили inline'у. Ничего не бывает бесплатно, а потому производительность кода сопровождается медленной компиляцией и всеми прелестями, растущими от необходимости перекомпиляции проекта при изменении одного несчастного inline-метода класса.
Как поступать при написании самодельных классов? Все короткие методы/конструкторы/деструкторы имеет смысл написать внутри класса (или снаружи, но с модификатором inline) в заголовочном файле. В эту категорию включаются все Set/Get'ы. Длинные и тяжёлые методы, которые незачем inline'ить, лучше реализовывать в файлах *.cpp Добавлено через 1 минуту Для этого пользуются специальными нанотехнологиями: либо строят всезависимости ручками. либо используют автоматические средства типа таких: https://www.cyberforum.ru/c-linux/thread46096.html
0
|
Ушел с форума
|
|
19.08.2013, 13:18 | 32 |
0
|
Ушел с форума
|
|
19.08.2013, 16:36 | 34 |
Visual C++ и Intel C++ Compiler - нанокомпиляторы ?
0
|
12 / 10 / 1
Регистрация: 12.03.2012
Сообщений: 127
|
||||||
19.08.2013, 16:50 | 35 | |||||
Помойму в C++ про inline говорить глупо, разве
0
|
19.08.2013, 16:54 | 36 |
Продемонстрируй мне, как глядя на код
C++ class A { A(); }; Добавлено через 1 минуту Да. public/provate - это всего лишь свойство на уровне языка. На уровне машинного кода их нет. Для машинного кода private и public методы принципиально ничем не отличаются
0
|
Ушел с форума
|
||||||||||||||||
19.08.2013, 17:19 | 38 | |||||||||||||||
Могут.
Если более конкретно: IPO в Intel C++ http://software.intel.com/site... o_mult.htm LTCG в Visual C++ http://msdn.microsoft.com/en-u... s.90).aspx http://msdn.microsoft.com/en-u... 01698.aspx У GCC также есть соответствующие опции, но я с ним не работаю, поэтому ссылку не приведу. Ну и специально для тех, кто, как и я, верит только глазам. Компилируем в Visual C++ 2008 проект с таким кодом:
Теперь создаем второй проект (чтобы не было подозрений) с таким кодом:
Конфигурация Release, настройки оптимизации по умолчанию. Вызов функции my_function и ее реализация находятся в разных cpp файлах. Формально даже в разных единицах компоновки. Однако вот что получилось в сгенерированном ассемблерном листинге:
3
|
19.08.2013, 17:39 | 39 |
В GCC это называется LTO (Link-Time Optimization). Включается опцией: -flto
Добавлено через 13 минут Если быть точным, то в GCC это называется IPA, а LTO лишь расширяет это понятие.
0
|
19.08.2013, 17:58 | 40 |
Поднимите руку те, кто использовал режим межмодульного inline в реальных больших проектах, состоящих из десятков тысяч файлов, которые в помодульном режиме собираются несколько часов. Думаю, таких извращенцев нет и в ближайшем обозримом будущем не появится
При написании классов ни в коем случае не надо закладываться на подобные режимы. Нормальные люди ими мало пользуются. Теперь возьмём ещё один пример. Мы поставляем библиотеку в виде "бинарник библиотеки + инклюды". Что у нас в этом случае может сделать компилятор в этом нанорежиме? Да ничего не сможет. Если мы поставляем библиотеку в виде бинарника, значит мы не хотим показывать её внутренности, значит мы не будем её компилировать в подобных режимах. А потому нужно нормально в хидера прописать все короткие inline-методы и inline-функции (внутренности которых прятать не критично, т.к. и ежу понятно, что в них написано) Хочется ещё раз подчеркнуть. При разработке софта выбросьте из головы эти идиотские режимы и рассчитывайте эффективность исходя из нормального помодульного режима. А всякие межмодульные inline появились не от хорошей жизни.
0
|
19.08.2013, 17:58 | |
19.08.2013, 17:58 | |
Помогаю со студенческими работами здесь
40
Глобальные указатели. Плохо или хорошо? молодняк получил пр=0 хорошо или плохо? Средний балл - хорошо или плохо Статические функции-члены - хорошо или плохо? Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |