С Новым годом! Форум программистов, компьютерный форум, киберфорум
Наши страницы

С++ для начинающих

Войти
Регистрация
Восстановить пароль
 
 
Рейтинг: Рейтинг темы: голосов - 35, средняя оценка - 4.69
FanOfGun
6 / 6 / 1
Регистрация: 13.10.2012
Сообщений: 101
#1

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

17.08.2013, 21:48. Просмотров 5402. Ответов 61
Метки нет (Все метки)

все знакомые мне ide разделяют класс на два файла: .h с описанием и .cpp с кодом, но, например, в boost .hpp файлы почти всегда содержат и реализацию классов, т.е. так тоже можно. так в чем тогда разница и когда какой способ нужно применять? заранее благодарен
0
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
Similar
Эксперт
41792 / 34177 / 6122
Регистрация: 12.04.2006
Сообщений: 57,940
17.08.2013, 21:48
Здравствуйте! Я подобрал для вас темы с ответами на вопрос реализация класса в .h файле хорошо или плохо? (C++):

Такой способ создание экземпляра класса хорошо или плохо? - C++
Объясните пожалуйста в чем есть плохо создавать экземпляр класса вот так? class A{ /*.....*/ }objA; нежели так :

Глобальные указатели. Плохо или хорошо? - C++
Уважаемые знатоки, хотел уточнить один вопрос. Дело в том, что я использую глобальные указатели на объекты. Сами объекты создаются по...

Переменные на русском языке - хорошо или плохо? - C++
в mvs 2012 заметил возможность в проектах c++ переменным, функциям, классам давать русско-буквенные имена. как вы относитесь к...

Статические функции-члены - хорошо или плохо? - C++
Всем привет. Приведу пример такой архитектуры. Есть базовый интерфейс. От него наследуются много конкретных. И есть фабрика,...

Реализация класса в отдельном файле - C++
Изучаю C++ (вернее только начал) по учебнику "Харви М. Дейтел, Пол Дж. Дейтел - Как программировать на C++" и застрял на создании классов в...

Реализация шаблонов класса в инлайн файле - C++
Пытался написать шаблонны MyClass.h #pragma once #define MYCLASS template <typename T> class MyClass { public:

61
Evg
Эксперт CАвтор FAQ
18384 / 6432 / 441
Регистрация: 30.03.2009
Сообщений: 17,855
Записей в блоге: 28
19.08.2013, 12:23 #31
Почему в Си++ реализации классов выносят в заголовочные файлы? Все очень просто. Тело метода класса, определённое внутри описания класса, является inline. Реализации многих шаблонов (в том числе и стандартных контейнеров) основаны на том, что после инстанциации шаблона компилятор видит все конструкторы, деструкторы, методы и весь тот хлам, что подцепится в процессе инстанциации. Дальше компилятор сделает длинный паровоз из inline'ов, после чего код, расположенный в тексте в виде 100500 различных функций и методов, в машинном коде окажется коротким и быстрым. Именно ради производительности разработчики Си++ особое внимание уделили inline'у. Ничего не бывает бесплатно, а потому производительность кода сопровождается медленной компиляцией и всеми прелестями, растущими от необходимости перекомпиляции проекта при изменении одного несчастного inline-метода класса.

Как поступать при написании самодельных классов? Все короткие методы/конструкторы/деструкторы имеет смысл написать внутри класса (или снаружи, но с модификатором inline) в заголовочном файле. В эту категорию включаются все Set/Get'ы. Длинные и тяжёлые методы, которые незачем inline'ить, лучше реализовывать в файлах *.cpp

Добавлено через 1 минуту
Цитата Сообщение от fasked Посмотреть сообщение
Опять же, make не настолько умен, чтобы самостоятельно определить зависимости и не способен пересобрать все зависимые файлы
Для этого пользуются специальными нанотехнологиями: либо строят всезависимости ручками. либо используют автоматические средства типа таких: Makefile: как с использованием gcc строить автоматические зависимости от .h файлов?
0
Убежденный
Ушел с форума
Эксперт С++
15708 / 7219 / 1139
Регистрация: 02.05.2013
Сообщений: 11,637
Записей в блоге: 1
Завершенные тесты: 1
19.08.2013, 13:18 #32
Цитата Сообщение от Evg Посмотреть сообщение
Дальше компилятор сделает длинный паровоз из inline'ов, после чего код, расположенный в тексте в виде 100500 различных функций и методов, в машинном коде окажется коротким и быстрым.
Компилятор может сделать это и без inline.
0
Evg
Эксперт CАвтор FAQ
18384 / 6432 / 441
Регистрация: 30.03.2009
Сообщений: 17,855
Записей в блоге: 28
19.08.2013, 16:28 #33
Цитата Сообщение от Убежденный Посмотреть сообщение
Компилятор может сделать это и без inline
Угу, особенно если не видит реализации функции (т.к. они находятся в другом *.cpp). Типа нанокомпилятор
0
Убежденный
Ушел с форума
Эксперт С++
15708 / 7219 / 1139
Регистрация: 02.05.2013
Сообщений: 11,637
Записей в блоге: 1
Завершенные тесты: 1
19.08.2013, 16:36 #34
Visual C++ и Intel C++ Compiler - нанокомпиляторы ?
0
kvadro
11 / 9 / 1
Регистрация: 12.03.2012
Сообщений: 127
19.08.2013, 16:50 #35
Помойму в C++ про inline говорить глупо, разве

C++
1
2
3
4
5
6
struct Foo
{
    int getBar() { return bar; }
  private:
    int bar;
}
Заинлайнит getBar(), если bar приватный?
0
Evg
Эксперт CАвтор FAQ
18384 / 6432 / 441
Регистрация: 30.03.2009
Сообщений: 17,855
Записей в блоге: 28
19.08.2013, 16:54 #36
Цитата Сообщение от Убежденный Посмотреть сообщение
Visual C++ и Intel C++ Compiler - нанокомпиляторы ?
Продемонстрируй мне, как глядя на код

C++
class A
{
  A();
};
и не видя тело конструктора, указанные компиляторы могут что-то проинлайнить

Добавлено через 1 минуту
Цитата Сообщение от kvadro Посмотреть сообщение
Заинлайнит getBar(), если bar приватный?
Да. public/provate - это всего лишь свойство на уровне языка. На уровне машинного кода их нет. Для машинного кода private и public методы принципиально ничем не отличаются
0
kamre
126 / 130 / 4
Регистрация: 25.12.2011
Сообщений: 443
19.08.2013, 17:04 #37
Цитата Сообщение от Evg Посмотреть сообщение
не видя тело конструктора, указанные компиляторы могут что-то проинлайнить
MSDN:
When /LTCG is used to link modules compiled by using /Og, /O1, /O2, or /Ox, the following optimizations are performed:
  • Cross-module inlining
  • Interprocedural register allocation (64-bit operating systems only)
  • Custom calling convention (x86 only)
  • Small TLS displacement (x86 only)
  • Stack double alignment (x86 only)
  • Improved memory disambiguation (better interference information for global variables and input parameters)
0
Убежденный
Ушел с форума
Эксперт С++
15708 / 7219 / 1139
Регистрация: 02.05.2013
Сообщений: 11,637
Записей в блоге: 1
Завершенные тесты: 1
19.08.2013, 17:19 #38
Цитата Сообщение от Evg Посмотреть сообщение
Продемонстрируй мне, как глядя на код
...
и не видя тело конструктора, указанные компиляторы могут что-то проинлайнить
Могут.

Если более конкретно:
IPO в Intel C++
http://software.intel.com/sites/prod...s_ipo_mult.htm

LTCG в Visual C++
http://msdn.microsoft.com/en-us/library/xbf3tbeh(v=vs.90).aspx
http://msdn.microsoft.com/en-us/magazine/cc301698.aspx

У GCC также есть соответствующие опции, но я с ним не работаю, поэтому ссылку не приведу.

Ну и специально для тех, кто, как и я, верит только глазам.

Компилируем в Visual C++ 2008 проект с таким кодом:
C++
1
2
3
4
int my_function()
{
    return 0x12345;
}
В итоге получаем объектный файл (.obj).

Теперь создаем второй проект (чтобы не было подозрений) с таким кодом:
C++
1
2
3
4
5
6
int my_function();
 
int main()
{
    return (my_function());
}
И подключаем к нему собранный ранее объектник.
Конфигурация Release, настройки оптимизации по умолчанию.

Вызов функции my_function и ее реализация находятся в разных cpp файлах.
Формально даже в разных единицах компоновки. Однако вот что получилось в
сгенерированном ассемблерном листинге:
Assembler
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
; Listing generated by Microsoft (R) Optimizing Compiler Version 15.00.30729.01 
 
    TITLE   d:\Dev\App\Test\main.cpp
    .686P   .XMM
    include listing.inc
    .model  flat
 
INCLUDELIB OLDNAMES
 
PUBLIC  _main
; Function compile flags: /Ogtpy
; File d:\dev\app\test\main.cpp
;   COMDAT _main
_TEXT   SEGMENT
_main   PROC                        ; COMDAT
 
; 5    :     return (my_function());
 
    mov eax, 74565              ; 00012345H
 
; 6    : }
 
    ret 0
_main   ENDP
_TEXT   ENDS
END
3
castaway
Эксперт С++
4916 / 3024 / 370
Регистрация: 10.11.2010
Сообщений: 11,081
Записей в блоге: 10
Завершенные тесты: 1
19.08.2013, 17:39 #39
Цитата Сообщение от Убежденный Посмотреть сообщение
У GCC также есть соответствующие опции, но я с ним не работаю, поэтому ссылку не приведу.
В GCC это называется LTO (Link-Time Optimization). Включается опцией: -flto

Добавлено через 13 минут
Если быть точным, то в GCC это называется IPA, а LTO лишь расширяет это понятие.
0
Evg
Эксперт CАвтор FAQ
18384 / 6432 / 441
Регистрация: 30.03.2009
Сообщений: 17,855
Записей в блоге: 28
19.08.2013, 17:58 #40
Поднимите руку те, кто использовал режим межмодульного inline в реальных больших проектах, состоящих из десятков тысяч файлов, которые в помодульном режиме собираются несколько часов. Думаю, таких извращенцев нет и в ближайшем обозримом будущем не появится

При написании классов ни в коем случае не надо закладываться на подобные режимы. Нормальные люди ими мало пользуются.

Теперь возьмём ещё один пример. Мы поставляем библиотеку в виде "бинарник библиотеки + инклюды". Что у нас в этом случае может сделать компилятор в этом нанорежиме? Да ничего не сможет. Если мы поставляем библиотеку в виде бинарника, значит мы не хотим показывать её внутренности, значит мы не будем её компилировать в подобных режимах. А потому нужно нормально в хидера прописать все короткие inline-методы и inline-функции (внутренности которых прятать не критично, т.к. и ежу понятно, что в них написано)

Хочется ещё раз подчеркнуть. При разработке софта выбросьте из головы эти идиотские режимы и рассчитывайте эффективность исходя из нормального помодульного режима. А всякие межмодульные inline появились не от хорошей жизни.
0
castaway
Эксперт С++
4916 / 3024 / 370
Регистрация: 10.11.2010
Сообщений: 11,081
Записей в блоге: 10
Завершенные тесты: 1
19.08.2013, 18:17 #41
Ну почему же? Например, функция LTO в GCC позволяет на несколько процентов уменьшить размер исполняемого файла. Я не вижу смысла использовать эту функцию в мелких проектах, но наоборот, вижу смысл в больших. Ведь LTO не только инлайнит такие методы, но и выполняет другие оптимизации, например такие как удаление неиспользованных функций. Поскольку оптимизация выполняется на уровне линковки, то я не думаю что время сборки в целом увеличится в разы.
0
Убежденный
Ушел с форума
Эксперт С++
15708 / 7219 / 1139
Регистрация: 02.05.2013
Сообщений: 11,637
Записей в блоге: 1
Завершенные тесты: 1
19.08.2013, 19:01 #42
Цитата Сообщение от Evg Посмотреть сообщение
Поднимите руку те, кто использовал режим межмодульного inline в реальных больших проектах, состоящих из десятков тысяч файлов, которые в помодульном режиме собираются несколько часов. Думаю, таких извращенцев нет и в ближайшем обозримом будущем не появится
Во-первых, при чем здесь большие проекты ? Или Вы считаете, что только те фичи имеют
право на существование, которые сертифицированы для использования на космических станциях ?
Так можно сказать, что и прекомпилированные заголовки не нужны, и разворачивание циклов, и
profile-guided optimization, и т.д.

Во-вторых, полезность или вредность данного вида (оптимизации ?) для больших проектов не очевидна.
Или поделитесь ссылкой на соответствующие исследования/статистику, или замечание ни о чем.

Цитата Сообщение от Evg Посмотреть сообщение
При написании классов ни в коем случае не надо закладываться на подобные режимы. Нормальные люди ими мало пользуются.
А аргументы ? Забыли ?

Цитата Сообщение от Evg Посмотреть сообщение
Теперь возьмём ещё один пример. Мы поставляем библиотеку в виде "бинарник библиотеки + инклюды". Что у нас в этом случае может сделать компилятор в этом нанорежиме? Да ничего не сможет. Если мы поставляем библиотеку в виде бинарника, значит мы не хотим показывать её внутренности, значит мы не будем её компилировать в подобных режимах. А потому нужно нормально в хидера прописать все короткие inline-методы и inline-функции (внутренности которых прятать не критично, т.к. и ежу понятно, что в них написано)
Дело вкуса. Лично я предпочту отдать клиентам четко разделенные интерфейс и реализацию,
чем хидеры, содержащие частичные определения. Пусть и ценой определенных уступок.
А размазывая определения по хидерам и cpp-файлам, можно наступить на мину под названием
"нарушение ODR". Особенно в тех самых "больших" проектах. Компилятор прожует и не поморщится.

Цитата Сообщение от Evg Посмотреть сообщение
Хочется ещё раз подчеркнуть. При разработке софта выбросьте из головы эти идиотские режимы и рассчитывайте эффективность исходя из нормального помодульного режима. А всякие межмодульные inline появились не от хорошей жизни.
Наоборот. Используйте их. И вам не придется думать о том, что компилятор не сможет
где-то что-то заинлайнить только потому, что у него нет доступа к определению.
А вообще, и то и другое попахивает преждевременной оптимизацией.
0
Evg
Эксперт CАвтор FAQ
18384 / 6432 / 441
Регистрация: 30.03.2009
Сообщений: 17,855
Записей в блоге: 28
19.08.2013, 19:46 #43
Цитата Сообщение от Убежденный Посмотреть сообщение
Во-первых, при чем здесь большие проекты ? Или Вы считаете, что только те фичи имеют
право на существование, которые сертифицированы для использования на космических станциях ?
На гипертрофированных примерах лучше видно. Возьмём проект из 1000 файлов *.cpp. Соберём их помодульно. Допустим, ушёл час времени. Поменяем один файл *.cpp (изменим реализацию интерфейса, что является наиболее частой операцией). Перекомпилируем. Пересборка займёт, условно говоря, несколько секунд, т.к. перекомпилироваться будет 1 файл, а не 1000. В случае режима с межмодульным инлайном при любом изменении в любом файле финальная межмодульная стадия компиляции будет работать по полной программе и займёт, условно говоря, столько же времени, сколько и полная сборка с нуля

Пока твой проект состоит из 10 файлов, разница между помодульным режимом в абсолютном времени будет небольшая. В проекте из 1000 файлов - разница будет огромная. Не говоря о том, что режим с межмодульным инлайном по времени работает далеко не линейно по отношению к количеству файлов. Увеличили количество файлов в 2 раза - время компиляции увеличится в 3, 5, 10 или хз сколько раз, но заведомо больше, чем в 2 раза. В противном случае межмодульная часть компилятора попросту работает некачественно

Цитата Сообщение от Убежденный Посмотреть сообщение
Так можно сказать, что и прекомпилированные заголовки не нужны, и разворачивание циклов, и
profile-guided optimization, и т.д.
Не надо путать оптимизации и режим работы. Раскрутка циклов - это оптимизация. Инлайн - это оптимизация. Режим IPO - это НЕ оптимизация, это режим, при котором у тебя попросту 100500 исходников склеиваются в один прозрачным для пользователя способом

Цитата Сообщение от Убежденный Посмотреть сообщение
Или поделитесь ссылкой на соответствующие исследования/статистику, или замечание ни о чем.
Конкретной ссылкой поделиться не могу. Но я с этим режимом работал задолго до того, как он появился у gcc и у интеловского компилятора. Могу даже объяснить причину, по которой этот режим вообще на свет появился:

1. (самая главная причина) Опубликовать цифры производительности. Все разработчики (будь то компиляторов, будь-то аппаратуры) публикуют цифры производительности по всяким бенчмаркам. Это стандартный узаконненный способ вешать лапшу на уши пользователям. Т.е. все замеры можно повторить и они покажут те же цифры. Но на реальных задачах (а не на бенчмарках) таких цифр с большой вероятностью не добиться. Режим межмодульного инлайна - ещё одна статья для увеличения цифр производительности, в котором компилятору можно получить бОльшее раздолье для всяких эвристических оптимизаций, которые хорошо ведут себя на бенчмарах, но плохо на реальных задачах
2. (полезная причина) Есть много старого софта, который был написан во времена, когда компиляторы были слабые, а потому никто не задумывался о том, чтобы написать софт правильно. Или программа на Си, в котором не было удобных и эффективных средств по части inline, которые есть на Си++. Может быть, что-то ещё.
3. (маркетинговая причина) Сделать режим для криворуких программистов, которые вообще не понимают (и не хотят понимать), как работает компилятор в первом приближении и как устроены машинные коды. На банере яркими буквами пишется, что, дескать, программируйте и не задумывайтесь ни о чём, наш супер-пупер межмодульный режим сделает вас абсолютно щастливыми

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

Цитата Сообщение от Убежденный Посмотреть сообщение
А размазывая определения по хидерам и cpp-файлам, можно наступить на мину под названием
"нарушение ODR". Особенно в тех самых "больших" проектах. Компилятор прожует и не поморщится
Пример можно? Имеется в виду пример того, как наступишь, а потом долго ищешь причину

Цитата Сообщение от Убежденный Посмотреть сообщение
Наоборот. Используйте их. И вам не придется думать о том, что компилятор не сможет
где-то что-то заинлайнить только потому, что у него нет доступа к определению.
А вообще, и то и другое попахивает преждевременной оптимизацией.
"И то, и другое" - это что?
0
Убежденный
Ушел с форума
Эксперт С++
15708 / 7219 / 1139
Регистрация: 02.05.2013
Сообщений: 11,637
Записей в блоге: 1
Завершенные тесты: 1
19.08.2013, 20:47 #44
Цитата Сообщение от Evg Посмотреть сообщение
Возьмём проект из 1000 файлов *.cpp. Соберём их помодульно. Допустим, ушёл час времени. Поменяем один файл *.cpp (изменим реализацию интерфейса, что является наиболее частой операцией). Перекомпилируем. Пересборка займёт, условно говоря, несколько секунд, т.к. перекомпилироваться будет 1 файл, а не 1000. В случае режима с межмодульным инлайном при любом изменении в любом файле финальная межмодульная стадия компиляции будет работать по полной программе и займёт, условно говоря, столько же времени, сколько и полная сборка с нуля

Пока твой проект состоит из 10 файлов, разница между помодульным режимом в абсолютном времени будет небольшая. В проекте из 1000 файлов - разница будет огромная. Не говоря о том, что режим с межмодульным инлайном по времени работает далеко не линейно по отношению к количеству файлов. Увеличили количество файлов в 2 раза - время компиляции увеличится в 3, 5, 10 или хз сколько раз, но заведомо больше, чем в 2 раза. В противном случае межмодульная часть компилятора попросту работает некачественно
Скажите, как давно Вы последний раз работали с этим режимом ?
Спрашиваю, потому что написанное выше не соответствует действительности (а может, никогда
ей не соответствовало). При IPO повторная компиляция не выполняется. В Visual C++, например,
IPO - это некий промежуточный режим между компиляцией, когда код уже перенесен в промежуточное и
независимое от процессорной архитектуры представление, и компоновкой.

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

Цитата Сообщение от Evg Посмотреть сообщение
Не надо путать оптимизации и режим работы. Раскрутка циклов - это оптимизация. Инлайн - это оптимизация. Режим IPO - это НЕ оптимизация, это режим, при котором у тебя попросту 100500 исходников склеиваются в один прозрачным для пользователя способом
IPO - это такая же оптимизация, как и все остальное.
Как формально (буква "О" в названии говорит сама за себя), так и по факту.
Но мы же не формалисты, нас ведь интересует практическое применение, а не навешивание ярлыков ?

Цитата Сообщение от Evg Посмотреть сообщение
Это стандартный узаконненный способ вешать лапшу на уши пользователям.
Разумеется.
А знаете, в чем прелесть IPO ? В том, что для его использования не нужно прикладывать
никаких усилий. Он просто включен по умолчанию. Думаю, большинство пользователей, особенно
начинающих, вообще не знают, что их компилятор использует IPO. И тем не менее, получают
все выгоды от него.

Цитата Сообщение от Evg Посмотреть сообщение
Режим межмодульного инлайна - ещё одна статья для увеличения цифр производительности, в котором компилятору можно получить бОльшее раздолье для всяких эвристических оптимизаций, которые хорошо ведут себя на бенчмарах, но плохо на реальных задачах
Доказательства "плохости" есть ? Если нет - значит, ни о чем.

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

Цитата Сообщение от Evg Посмотреть сообщение
Про время компиляции и неудобство разработки уже говорил.
Время компиляции увеличивается незначительно. Не факт, что при использовании реализации в
хидерах оно было бы меньше. При прочих равных условиях. Ну а неудобство... В чем оно ?
Я могу писать код в хидерах. А могу в cpp-файлах. И, что хорошо, сгенерированный
машинный код будет практически эквивалентным. Где здесь неудобство ?
Вижу только одно "неудобство" - программисты, выросшие на современных компиляторах,
не знают что такое инлайнинг по своей сути. И как его правильно готовить. Хотя это неудобство -
оно для кого ? Для корифеев, которые ноют "вот раньше были времена, а сейчас молодежь не та" ?
Ну так может пора ему уже на свалку, этому инлайнингу, раз он не играет существенной роли в
оптимизации ?

Цитата Сообщение от Evg Посмотреть сообщение
Есть ещё такая вещь, как преносимость. Т.е. пока мы живём на компиляторе, в котором этот режим есть, у нас программа более-меднее производительно работает. Как только перешли на другую платформу, где этого режима нет, получили дерьмовый код.
Это совсем не довод.
Вы же не сидите с утра до ночи на чемоданах, в ожидании "а вдруг уехать придется" ?
Надо будет переходить на другую платформу - будем принимать соответствующие меры.
"Всепогодный" код а-ля Boost, который должен работать везде и всегда, нужен лишь в особых
случаях, и это обычно оговаривается сразу. Сейчас я живу на Windows, здесь три наиболее
ярких компилятора - это Visual C++, Intel C++ и MinGW. Все они поддерживают IPO уже
не первый год, поэтому не вижу смысла искать здесь причины, чтобы его не использовать.

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

Цитата Сообщение от Evg Посмотреть сообщение
"И то, и другое" - это что?
Я имел в виду, что писать код, заранее прикидывая степень его "заинлайненности" -
это преждевременная оптимизация. Как в случае IPO, так и в случае реализации в хидерах.
0
castaway
Эксперт С++
4916 / 3024 / 370
Регистрация: 10.11.2010
Сообщений: 11,081
Записей в блоге: 10
Завершенные тесты: 1
19.08.2013, 21:42 #45

Не по теме:

Я конечно извиняюсь что влезаю в Ваш диалог, но мне, как двоечнику по школе очень интересно, почему англоязычное слово header все переводят (произносят) как хидер ?



Добавлено через 32 минуты

Не по теме:

Меня что, все в "игнор добавили"? Неужели я успел "насолить" всем...

0
19.08.2013, 21:42
MoreAnswers
Эксперт
37091 / 29110 / 5898
Регистрация: 17.06.2006
Сообщений: 43,301
19.08.2013, 21:42
Привет! Вот еще темы с ответами:

Реализация шаблонов класса в инлайн файле - C++
Пытался написать шаблонный класс, реализуя как обычно объявление класса в h файле и определение элемент-функций в с++. Компилятор постоянно...

Можно ли Хорошо посмотреть информацию о графическом файле в разных библиотеках? - C++
Есть имя (понятно с правильным путем, но это неважно). Надо узнать Размер этого графического файла. Разумеется можно файл Прочесть и для...

Реализация класса на базе класса Stack с возможностью !индексирования! - C++
Помогите пожалуйста!!! Нужно реализовать на базе класса stack другой класс с возможностью индексирования, а именно: Например 1 - й...

Перегрузка оператора индексации для класса плохо себя ведёт - C++
Собственно, есть такое дело. #include <iostream> #include <stdio.h> #include <vector> #include <string> using namespace std; ...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
45
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2017, vBulletin Solutions, Inc.