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

@FanOfGun · Регистрация: 13.10.2012

Author24 — интернет-сервис помощи студентам

все знакомые мне ide разделяют класс на два файла: .h с описанием и .cpp с кодом, но, например, в boost .hpp файлы почти всегда содержат и реализацию классов, т.е. так тоже можно. так в чем тогда разница и когда какой способ нужно применять? заранее благодарен

Jupiter · 17.08.2013, 21:49

Сообщение от FanOfGun

но, например, в boost .hpp файлы почти всегда содержат и реализацию классов

потому что в бусте в основном шаблоны

Сообщение от FanOfGun

так в чем тогда разница и когда какой способ нужно применять?

шаблоны и inline-функции пишут только в хедерах.
разделение на два файла позволяет скрыть реализацию предоставив "клиентам" лишь интерфейс (хедер файл с прототипами) и бинарник (dll/lib/so/a...).

@FanOfGun · 17.08.2013, 21:57 **[ТС]**

Jupiter, т.е. если класс исключительно для себя(и 100% в будущем не будет выноситься в отдельную библиотеку) можно кидать реализацию прямо в хедер(я, как человек, пишущий в осносном на c#, был бы очень рад такой возможности

) без особых проблем в будущем?

Jupiter · 17.08.2013, 22:00

Сообщение от FanOfGun

можно кидать реализацию прямо в хедер

нет просто кидать нельзя, можно просто писать тело метода внутри класса, как в шарпе, но читать такие простыни потом неудобно, в шарпе хоть с помощью partial можно спастись

C++

class MyClass
{
  void foo()
  {
  ...
  }
   
  void bar()
  {
  ...
  }
  ...
};

@castaway · 17.08.2013, 22:13

Jupiter, извини, но я с тобой не соглашусь.
Если класс небольшой, то его лучше реализовать в одном заголовочном файле. Причины просты: проще читать/редактировать/искать ошибки, меньше файлов, меньше кода (нет прототипов, нет forward declaration).

@DU · 17.08.2013, 22:33

нет прототипов, нет forward declaration

ага. и больше зависимостей. не сталкивались с проектами, где какое-то микроизменение в одном файле приводит к нескольким часам ребилда из-за такого подхода?

@castaway · 17.08.2013, 22:44

Сообщение от DU

и больше зависимостей.

С какой стати их стало больше?

Сообщение от DU

не сталкивались с проектами, где какое-то микроизменение в одном файле приводит к нескольким часам ребилда из-за такого подхода?

Сталкивался. Это изменение относится не только к классу реализованному одним заголовочным файлом, это изменение относится ко всем исходным файлам проекта. Поэтому вообще не понятно к чему вы это сказали.

@FanOfGun · 17.08.2013, 22:49 **[ТС]**

castaway, если изменить хеадер -- нужно перекомпилировать весть код, включающий его, а при реализации класса в хедере любое изменение логики будет приводить к перекомпиляции
если логика отдельно от описания, нужно перекомпилировать только ее

@bumbaram · 17.08.2013, 22:52

Сообщение от castaway

Сталкивался. Это изменение относится не только к классу реализованному одним заголовочным файлом, это изменение относится ко всем исходным файлам проекта. Поэтому вообще не понятно к чему вы это сказали.

Если твой класс разбит на .h и .cpp файл, то в нем явно разделены интерфейс и реализация. При этом небольшое изменение реализации требует пересборки только одного конкретного класса. При изменении .h файла, требуется пересборка всех классов в которые он был включен, а потом всех в которые были включены они и так далее...

Писать реализацию в .h файл необходимо только для inline методов или шаблонов, остальное - дурной тон.

@castaway · 17.08.2013, 22:56

Сообщение от FanOfGun

castaway, если изменить хеадер -- нужно перекомпилировать весть код, включающий его, а при реализации класса в хедере любое изменение логики будет приводить к перекомпиляции
если логика отдельно от описания, нужно перекомпилировать только ее

Давай я повторюсь и заодно открою для тебя один секрет - изменение любого кода в любом исходном файле (в том числе не заголовочном файле) влечет за собой такие же последствия. За это тебе ставлю минус.

Croessmah · 17.08.2013, 22:58

Сообщение от castaway

влечет за собой такие же последствия.

Скорее всего перекомпилируется только измененная часть + все зависимости, остальное просто останется не тронутым, а дальше работа линкера

@castaway · 17.08.2013, 23:03

bumbaram, это один небольшой минус, об этом я упомянул. Тоже -

Сообщение от castaway

Если класс небольшой, ...

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

Сообщение от Croessmah

Скорее всего перекомпилируется только измененная часть + все зависимости, остальное просто останется не тронутым, а дальше работа линкера

Не правильно понял мысль, которую мне хотели донести. Опять же, кто читал внимательно:

Сообщение от castaway

Если класс небольшой, ...

Тут есть причины не "разделять класс".

@FanOfGun · 17.08.2013, 23:05 **[ТС]**

Сообщение от castaway

Давай я повторюсь и заодно открою для тебя один секрет - изменение любого кода в любом исходном файле (в том числе не заголовочном файле) влечет за собой такие же последствия. За это тебе ставлю минус.

я, конечно, только начал с С++ работать, но все .cpp файлы компилируются в .o(или .obj или еще какие) файлы, этот процесс и занимает большую часть времени, после чего они линкуются в один исполняемый файл(быстро), и если изменяется один .cpp, нужно перекомпилировать только один .o файл, если меняется 10 .cpp -- 10 .o файлов. вот и вся математика. это работает в gcc, и скорей всего, во всех остальных

Добавлено через 1 минуту
а изменение .h файла влечет за собой изменеие всех .h и .cpp файлов, которые его включают, правильно ведь пишу?

@DU · 17.08.2013, 23:08

какая разница, большой класс или нет. если правится реализация, котрая в h файле - то тут перекомпиляция всего, что включает этот файл прямо или косвенно. хотя этого могло и не быть, если бы реализация была в cpp. так же, правится может приватная часть. сигнатуры, мемберы. последствия те же.

@Uzer5 · 17.08.2013, 23:24

Сообщение от FanOfGun

Jupiter, т.е. если класс исключительно для себя(и 100% в будущем не будет выноситься в отдельную библиотеку) можно кидать реализацию прямо в хедер(я, как человек, пишущий в осносном на c#, был бы очень рад такой возможности

) без особых проблем в будущем?

Вообще, можно программирование сравнить с кулинарией: если делаешь для всех, то надо стараться придерживаться рецепта, а если для себя, то хоть селёдку в оливье нареж и пивком залей, ктож осудит?

Убежденный · 17.08.2013, 23:27

Сообщение от Uzer5

а если для себя, то хоть селёдку в оливье нареж и пивком залей, ктож осудит?

Сам потом себя и осудишь

Croessmah · 17.08.2013, 23:29

Не по теме:

Сообщение от Uzer5

если делаешь для всех, то надо стараться придерживаться рецепта

Скажите это в армии :D

Убежденный · 17.08.2013, 23:29

FanOfGun, на заметочку: почитайте про паттерн "мост".
Там тема изоляции интерфейса класса от его реализации выражена рельефно.
Что касается вопроса про разделение на h и cpp - я время от времени
переписываю свои же классы (из h в h + cpp) и тихо матерюсь: ну почему,
почему я не сделал этого сразу...

Croessmah · 17.08.2013, 23:30

Не по теме:

Сообщение от Uzer5

ктож осудит?

Что-то вспомнилось:
У печени бы руки были - они бы горло задушили :D

@castaway · 17.08.2013, 23:33

DU, и часто случаются случаи когда надо править заголовочный файл, а реализацию в .cpp править не надо?

Croessmah Неэпический 17869 / 10634 / 2054 Регистрация: 27.09.2012 Сообщений: 26,736 Записей в блоге: 1
	17.08.2013, 22:58	11
	Сообщение от castaway влечет за собой такие же последствия. Скорее всего перекомпилируется только измененная часть + все зависимости, остальное просто останется не тронутым, а дальше работа линкера 0

@DU 1500 / 1146 / 165 Регистрация: 05.12.2011 Сообщений: 2,279
	17.08.2013, 23:08	14
	какая разница, большой класс или нет. если правится реализация, котрая в h файле - то тут перекомпиляция всего, что включает этот файл прямо или косвенно. хотя этого могло и не быть, если бы реализация была в cpp. так же, правится может приватная часть. сигнатуры, мемберы. последствия те же. 0

@Uzer5 4 / 4 / 1 Регистрация: 22.09.2012 Сообщений: 12
	17.08.2013, 23:24	15
	Сообщение от FanOfGun Jupiter, т.е. если класс исключительно для себя(и 100% в будущем не будет выноситься в отдельную библиотеку) можно кидать реализацию прямо в хедер(я, как человек, пишущий в осносном на c#, был бы очень рад такой возможности) без особых проблем в будущем? Вообще, можно программирование сравнить с кулинарией: если делаешь для всех, то надо стараться придерживаться рецепта, а если для себя, то хоть селёдку в оливье нареж и пивком залей, ктож осудит? 0

Убежденный Ушел с форума 16473 / 7436 / 1187 Регистрация: 02.05.2013 Сообщений: 11,617 Записей в блоге: 1
	17.08.2013, 23:27	16
	Сообщение от Uzer5 а если для себя, то хоть селёдку в оливье нареж и пивком залей, ктож осудит? Сам потом себя и осудишь 0

Убежденный Ушел с форума 16473 / 7436 / 1187 Регистрация: 02.05.2013 Сообщений: 11,617 Записей в блоге: 1
	17.08.2013, 23:29	18
	FanOfGun, на заметочку: почитайте про паттерн "мост". Там тема изоляции интерфейса класса от его реализации выражена рельефно. Что касается вопроса про разделение на h и cpp - я время от времени переписываю свои же классы (из h в h + cpp) и тихо матерюсь: ну почему, почему я не сделал этого сразу... 1

@FanOfGun 6 / 6 / 4 Регистрация: 13.10.2012 Сообщений: 101
		1
	реализация класса в .h файле хорошо или плохо? 17.08.2013, 21:48. Показов 14997. Ответов 61 Метки нет (Все метки) все знакомые мне ide разделяют класс на два файла: .h с описанием и .cpp с кодом, но, например, в boost .hpp файлы почти всегда содержат и реализацию классов, т.е. так тоже можно. так в чем тогда разница и когда какой способ нужно применять? заранее благодарен 0

Jupiter Каратель 6609 / 4028 / 401 Регистрация: 26.03.2010 Сообщений: 9,273 Записей в блоге: 1
	17.08.2013, 21:49	2
	Сообщение от FanOfGun но, например, в boost .hpp файлы почти всегда содержат и реализацию классов потому что в бусте в основном шаблоны Сообщение от FanOfGun так в чем тогда разница и когда какой способ нужно применять? шаблоны и inline-функции пишут только в хедерах. разделение на два файла позволяет скрыть реализацию предоставив "клиентам" лишь интерфейс (хедер файл с прототипами) и бинарник (dll/lib/so/a...). 2

@FanOfGun 6 / 6 / 4 Регистрация: 13.10.2012 Сообщений: 101
	17.08.2013, 21:57 [ТС]	3
	Jupiter, т.е. если класс исключительно для себя(и 100% в будущем не будет выноситься в отдельную библиотеку) можно кидать реализацию прямо в хедер(я, как человек, пишущий в осносном на c#, был бы очень рад такой возможности) без особых проблем в будущем? 0

@castaway 4985 / 3092 / 456 Регистрация: 10.11.2010 Сообщений: 11,169 Записей в блоге: 10
	17.08.2013, 22:13	5
	Jupiter, извини, но я с тобой не соглашусь. Если класс небольшой, то его лучше реализовать в одном заголовочном файле. Причины просты: проще читать/редактировать/искать ошибки, меньше файлов, меньше кода (нет прототипов, нет forward declaration). 0

@DU 1500 / 1146 / 165 Регистрация: 05.12.2011 Сообщений: 2,279
	17.08.2013, 22:33	6
	нет прототипов, нет forward declaration ага. и больше зависимостей. не сталкивались с проектами, где какое-то микроизменение в одном файле приводит к нескольким часам ребилда из-за такого подхода? 0

@castaway 4985 / 3092 / 456 Регистрация: 10.11.2010 Сообщений: 11,169 Записей в блоге: 10
	17.08.2013, 22:44	7
	Сообщение от DU и больше зависимостей. С какой стати их стало больше? Сообщение от DU не сталкивались с проектами, где какое-то микроизменение в одном файле приводит к нескольким часам ребилда из-за такого подхода? Сталкивался. Это изменение относится не только к классу реализованному одним заголовочным файлом, это изменение относится ко всем исходным файлам проекта. Поэтому вообще не понятно к чему вы это сказали. 1

@FanOfGun 6 / 6 / 4 Регистрация: 13.10.2012 Сообщений: 101
	17.08.2013, 22:49 [ТС]	8
	castaway, если изменить хеадер -- нужно перекомпилировать весть код, включающий его, а при реализации класса в хедере любое изменение логики будет приводить к перекомпиляции если логика отдельно от описания, нужно перекомпилировать только ее 0

@bumbaram 47 / 47 / 9 Регистрация: 13.02.2012 Сообщений: 176
	17.08.2013, 22:52	9
	Сообщение от castaway Сталкивался. Это изменение относится не только к классу реализованному одним заголовочным файлом, это изменение относится ко всем исходным файлам проекта. Поэтому вообще не понятно к чему вы это сказали. Если твой класс разбит на .h и .cpp файл, то в нем явно разделены интерфейс и реализация. При этом небольшое изменение реализации требует пересборки только одного конкретного класса. При изменении .h файла, требуется пересборка всех классов в которые он был включен, а потом всех в которые были включены они и так далее... Писать реализацию в .h файл необходимо только для inline методов или шаблонов, остальное - дурной тон. 0

@castaway 4985 / 3092 / 456 Регистрация: 10.11.2010 Сообщений: 11,169 Записей в блоге: 10
	17.08.2013, 22:56	10
	Сообщение от FanOfGun castaway, если изменить хеадер -- нужно перекомпилировать весть код, включающий его, а при реализации класса в хедере любое изменение логики будет приводить к перекомпиляции если логика отдельно от описания, нужно перекомпилировать только ее Давай я повторюсь и заодно открою для тебя один секрет - изменение любого кода в любом исходном файле (в том числе не заголовочном файле) влечет за собой такие же последствия. За это тебе ставлю минус. 1

@castaway 4985 / 3092 / 456 Регистрация: 10.11.2010 Сообщений: 11,169 Записей в блоге: 10
	17.08.2013, 23:03	12
	bumbaram, это один небольшой минус, об этом я упомянул. Тоже - Сообщение от castaway Если класс небольшой, ... Добавлено через 2 минуты Сообщение от Croessmah Скорее всего перекомпилируется только измененная часть + все зависимости, остальное просто останется не тронутым, а дальше работа линкера Не правильно понял мысль, которую мне хотели донести. Опять же, кто читал внимательно: Сообщение от castaway Если класс небольшой, ... Тут есть причины не "разделять класс". 0

	17.08.2013, 23:33

@FanOfGun 6 / 6 / 4 Регистрация: 13.10.2012 Сообщений: 101
	17.08.2013, 23:05 [ТС]	13
	Сообщение от castaway Давай я повторюсь и заодно открою для тебя один секрет - изменение любого кода в любом исходном файле (в том числе не заголовочном файле) влечет за собой такие же последствия. За это тебе ставлю минус. я, конечно, только начал с С++ работать, но все .cpp файлы компилируются в .o(или .obj или еще какие) файлы, этот процесс и занимает большую часть времени, после чего они линкуются в один исполняемый файл(быстро), и если изменяется один .cpp, нужно перекомпилировать только один .o файл, если меняется 10 .cpp -- 10 .o файлов. вот и вся математика. это работает в gcc, и скорей всего, во всех остальных Добавлено через 1 минуту а изменение .h файла влечет за собой изменеие всех .h и .cpp файлов, которые его включают, правильно ведь пишу? 0

Croessmah
	17.08.2013, 23:29 #17
	Не по теме: Сообщение от Uzer5 если делаешь для всех, то надо стараться придерживаться рецепта Скажите это в армии :D 0

Croessmah
	17.08.2013, 23:30 #19
	Не по теме: Сообщение от Uzer5 ктож осудит? Что-то вспомнилось: У печени бы руки были - они бы горло задушили :D 0