Плохая ли практика в h прописывать логику а потом дергать её в других местах программы?

в с++ нет понятия - логика.

Понял. Плохо ли сразу писать название функции и её реализацию в H файле? Просто у меня уже 10099020292 тон кода написано в h…

насколько я помню, при изменении логики будет перекомпилироваться все, куда инклудится этот h

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

Но вообще за реализацию функции в h бьют по рукам?

не обязательно. такая функция может рассматриваться компилятором как инлайн функция. это полезно для особо высоких требований по скорости кода. но если же функция объемна(и компилятор ее инлайнить не будет), то это вредно во всех отношениях.

Зависит от ситуации, инлайн функции и шаблоны пишутся в хидерах целиком.

За это бьют битой обернутой в полотенце, привязывают к стулу, кладут полотенце на лицо и поливают бензином.

По крайней мере у меня в отделе, если это не static inline функция

В отделе или в отделении?

В бригаде

Это очень плохо?

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

Во-вторых, лишняя писанина в h-файлах увеличивает время компиляции проекта в целом.

В-третьих, если надо инлайнить, то альтернатив особых нет.

В-четвертых, есть такая херовина - ODR. За её нарушение полагается UB. Смотри не оступись.

Про электрошокер забыли

Но вообще за реализацию функции в h бьют по рукам?

К нам в команду на собеседование как-то пришел программист с, буквально, кривыми пальцами.

Менеджер его спрашивает - что с руками?

А тот отвечает, что пальцы ему переломали коллеги на позапрошлой работе, за UB в лямбде. И заплакал.

На работу мы его, естественно, не пригласили.

Что такое UB???

Если вы этого не знаете, то вам не стоит писать на С-подобных языках

Да пофиг. Главное, чтобы канпелятар ворнингами не плевался.

Что такое UB???

Можешь начать отсюда - https://blog.regehr.org/archives/213

в с++ нет понятия - логика.

Главное, есть человеческие понятия хорошо и плохо (well/ill formed).

В пятых небольшие header only либы проще юзать.

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

в с++ есть понятие - реализация. а не «логика».

Раздельная компиляция появилась как вынужденная мера кода компьютеры были большие и медленные.

Что за ерунда. Раздельная компиляция помогает разрывать циклические зависимости. Без неё красивая архитектура софтины (сложнее хеллоу ворлда) превратится в кусок говна с бессмысленным выносом части логики и данных в базовые классы, часть этих сущностей вообще бы не была создана в случае раздельной компиляции.

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

Без неё красивая архитектура софтины (сложнее хеллоу ворлда) превратится в кусок говна с бессмысленным выносом части логики и данных в базовые классы…

раздельной компиляции 100 лет в обед. она была еще в первых ассемблерах, до появления всяких там си и тем более ооп.

Это хорошо или плохо?

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

хорошо конечно.

Воспользуюсь случаем, проведите ликбез для непосвященных - а можно вообще без всех этих .h писать? Как в питоне, в одном файле всё (про питонычьи модули понятно, это опциональное разбиение, не рассматриваем)?

раздельной компиляции 100 лет в обед. она была еще в первых ассемблерах, до появления всяких там си и тем более ооп.

Тут речь про конкретный язык, который выбрал для себя конкретную модель, и выбор это правильный, скорость компиляции не единственный фактор.

Если вы с товарищем выше согласны, то я не против, пишите свои поделки в hpp целиком, после килограма другого съеденного кактуса, вомзможно что-то начнет доходить даже до самых упорных. Невозможно комфортно что-то более менее сложное написать без раздельной компиляции

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

Можно, если что то простое.

Сходу — eigen, autodiff, gmm++ — нефига не тривиальные header-only либы с кучей шаблонов.

Контейнеры STL — header-only либы. Вообще для шаблонов плюсовых это норма.

Раздельная компиляция помогает разрывать циклические зависимости.

Вообще никак не связанные вещи. Единственное что в этом плане дает раздельная компиляция - глобальные static переменные в разных единицах трансляции, но это такое себе…

Так то да, удобно когда можно значимую часть кода вынести в .cpp оставив лаконичный хидер. Но это не является обязательным/догматичным требованием и уж вообще никаким боком к циклическим зависимостям не относится. Если Вам для разрыва таких зависимостей требуется раздельная компиляция у Вас явно какая то беда с архитектурой. И в голове путаница.

Вообще никак не связанные вещи.

Связанные, вот есть

class A {
   void set_link(B *);
};

class B {
   void set_link(A *);
};

Например, выкрутился, вынес реализацию за объявление классов, но вот появляется class С, который тоже имеет циклическую зависимость с A. Очевидно, что неудобно всё пихать в один файл (теперь ещё и C нужно добавить), и мы выносим реализации в отдельный hpp (a.hpp - a_impl.hpp, b.hpp - b_impl.hpp, …), и всё это в правильном порядке подключаем в отдельном hpp-агрегаторе. Можно вынести общую часть в отдельную сущность. Можно закостылить многопроходной компилятор.

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

Очевидно, что неудобно всё пихать в один файл (теперь ещё и C нужно добавить), и мы выносим реализации в отдельный hpp (a.hpp - a_impl.hpp, b.hpp - b_impl.hpp, …), и всё это в правильном порядке подключаем в отдельном hpp-агрегаторе.

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

В случае с шаблонами выхода нет, но в остальных случаях добровольный отказ от раздельной компиляции - идиотизм

А потом делаем эти классы шаблонами и переносим их опять в .hpp

В приведённом примере вообще достаточно задекларировать три класса сначала и фсе.

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

В приведённом примере вообще достаточно задекларировать три класса сначала и фсе.

Нет, вы даже не въехали.

A::set_link(B *b) {b->set_informer(this);}

Толку от forward декларации нет, нужно знать полноценную в момент имплементации.

На этом заканчиваю, вообще вещи очевидные, странно их доказывать

В-четвертых, есть такая херовина - ODR. За её нарушение полагается UB. Смотри не оступись.

Почему ub, а не ошибка компиляции?

Господи, надеюсь это шутка.

Почему ub, а не ошибка компиляции?

Спроси у коммитета

Господи, надеюсь это шутка.

Разумеется

Можно и в хедерах, но по хорошему в них пишут только небольшие функции или шаблоны.

Забавно, что на мой комментарий у вас такого вопроса не возникло.

Почему ub, а не ошибка компиляции?

Спроси у коммитета

Я не помню кейса, когда нарушение odr позволяло собрать проект и приводило к ub. Можешь привести пример?

Я не заметил его.

Например, когда в разных compilation units один и тот же тип имеет разный размер, и они начинают передавать друг дружке указатель на экземпляр и работать с ним. Но стандарт говорит, что нарушение ODR само по себе является UB, afaik.

Бггг, это Вы не въехали, хватит уже тупить!

Раздельная компиляция НИКАК не влияет на разрыв кольцевых зависимостей. Раздельная компиляция не более чем ОДИН ИЗ способов организации кода.

В случае кольцевых зависимостей в любом случае придётся разносить определение классов и реализацию их методов.

вещи очевидные, странно их доказывать

Ваши фантазии очевидно останутся фантазиями сколько их не доказывай.

Буквально две недели назад в спешке накосячил со сборкой и очень больно об это стукнулся - думал уже реально крыша едет…

Я называю это «заметанием мусора под ковёр». С++ программисты гордятся что божественный ООП позволяет писать красивый и простой код. Вот только заглянешь в хидеры, а там ад и погибель беспорядочное нагромождение темплейтов на темплейте и всё это нечитаемое безобразие никак не прокомментировано.

Что за программист из тебя - мне ясно, всего хорошего, повелитель хеллоу ворлдов.

Буквально две недели назад

Нубина )))

это вообще описание всех крестов в принципе.

разглядывая код некоторых опенсорсных проектов хочется разбить себе лицо

Например, когда в разных compilation units один и тот же тип имеет разный размер, и они начинают передавать друг дружке указатель на экземпляр и работать с ним

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

А почему именно static?

getter и setter несем в cpp в надежде что компилятор сам проинлайнит? Компилим только с LTO?