Расположение определения функций в заголовочных файлах

grizlik78,
Часто вижу что приватную секцию указывают внизу, интересно, зачем?
Вроде удобнее расположить приватные члены класса в самом начале ещё до того как будет указан какой либо из модификаторов доступа...

Добавлено через 3 минуты
mhg,
Покажите место где используете экземпляр данного класса

0

Удобнее в том смысле, что не надо писать ключевое слово private? Так я считаю, что его стоит писать даже если приватные члены расположены вначале. А так дело вкуса. Просто многим удобнее когда сначала идёт интерфейс класса, а потом уже закрытые детали.

0

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

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

Сори за оффтоп

0

Сообщение от Undisputed По поводу интерфейса можно в принципе поделить на хедер и cpp... Кстати иногда даже сложно читать такой код... Обычно код читается сверху вниз... Если не видим полей, но в методах к ним обращаемся, приходится кутить вниз чтоб узнать что это за поле а потом опять крутить вверх что бы продолжить читать код метода... Как то не очень удобно

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

Что касается "неудобства", которые ты описываешь - оно прекрасно убирается нотациями именования членов, префиксом m_ или суффиксом _, становится прекрасно видно, что данная переменная принадлежит классу. Кроме того, если в классе столько переменных, что при разработке становится их сложно запомнить, то это звоночек по дизайну - "а не пишем ли мы класс-великий всемогутор"?

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

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

И да, крутить так потребуется только в случае, если большинство методов класса inline и они определены прямо в его теле. Причем крутить надо будет все равно, только не вниз, а вверх, в случае, если таких методов много. А это, надо сказать, вырожденный случай, преимущественно характерный для шаблонов. А обычный код редко так пишут. Обычный код все-таки делится на h\cpp и так или иначе приходится смотреть и туда и туда, и здесь уже становится все равно в начале указан private или в конце. Специальные нотации именования и подсказки IDE здесь решают все удобство.

Добавлено через 8 минут
И еще - разработка класса таки должна начинаться с интерфейса, так мы фиксируем контракт и уже можем начинать писать тесты. С этой позиции тем более выгоднее писать публичную секцию вначале.

3

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

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

Но есть случаи когда железно надо делить, например при использовании динамически подключаемых библиотек... Вот это я понимаю обоснование.
ИМХО все остальные аргументы так себе и имеют минусы не слабее чем плюсы

Да кстати, интересно что ты обо всем этом думаешь

0

Сообщение от Undisputed Да я именно говорил про тот случай когда тело методов пишется внутри класса...

Так почти никогда не делают. Связность повышается, время компиляции повышается. В inline выносят точечно, после профилирования.

Сообщение от Undisputed но меня печалит то что если потом инклюдить хедер, то про инлайн как правило можно забыть а это плохо сказывается на производительности...

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

Сообщение от Undisputed Тут можно поделить и инклюдить сам сппшник

Так никто не делает.

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

Ерунда какая.

Сообщение от Undisputed ИМХО все остальные аргументы так себе

Просто ты еще не осознал.

0

Сообщение от DrOffset Просто ты еще не осознал.

Может быть, вот пытаюсь осознать

Сообщение от DrOffset Так почти никогда не делают. Связность повышается, время компиляции повышается.

Связность повышается? Всмысле? Между чем эта связь повышается? Если бы мы говорили про настоящие интерфейсы в качестве базового класса то я бы понял.
А в данном случае не очень понятно в чем проблема...

Сообщение от DrOffset В inline выносят точечно, после профилирования.

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

Сообщение от DrOffset Решение о потере производительности принимают после профилирования, а не на основе интуиции.

Почему сразу интуиции? Например нужна быстрая программа и заранее известно что определенные методы будут вызываться например в цикле который держит программу в рабочем состоянии и таких методов много и они в свою очередь тоже вызывают другие методы. Тут уже не интуиция а мы явно знаем что пишем горячую точку. В таком случае не обязательно профилировать потому что и так все ясно что с инлайном будет быстрее

Сообщение от DrOffset Ерунда какая.

Может быть. Я не проверял, но где то вроде читал подобное...

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

Сообщение от DrOffset Так почти никогда не делают.

Я пользовался студией и gcc, и когда смотрел реализацию STL - там именно так и делают Сразу внутри класса пишут

0

Сообщение от Undisputed Связность повышается? Всмысле? Между чем эта связь повышается? Если бы ты предложил использовать настоящие интерфейсы в качестве базового класса то я бы понял. А в данном случае не очень понятно в чем проблема...

Связность между исходниками. Изменение инлайн метода в таком заголовочном файле приводит к перекомпиляции всех зависимых от этого файла исходников.

Сообщение от Undisputed Почему сразу интуиции? Например нужна быстрая программа и заранее известно что определенные методы будут вызываться например в цикле который держит программу в рабочем состоянии и таких методов много и они в свою очередь тоже вызывают другие методы. Тут уже не интуиция а мы явно знаем что пишем горячую точку. В таком случае не обязательно профилировать потому что и так все ясно что с инлайном будет быстрее

Какой-то конь в вакууме. Однако, действительно, бывает сразу понятно, что несколько "горячих" методов можно заинлайнить, но если это программа сложнее hello world, то заранее предсказать, что этого будет достаточно, нельзя. Профилирование все равно нужно, к тому же замедление может быть вовсе не из-за наличия\отсутствия inline, а из-за алгоритмов, что бывает гораздо чаще. А вот делать абсолютно все методы инлайн сразу - однозначно неправильно, и как раз является хрестоматийным примером преждевременной оптимизации.

Вот тебе реальные цифры из недавней работы по оптимизации картографического рендера под ARM:
Микропотимизации (inline, исключение лишних временных объектов, битовая магия и т.п.) - прирост производительности ~3%
Алгоритмическая оптимизация - прирост производительности ~40% в тривиальнейшей реализации.

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

При чем тут стиль написания inline-методов и вопрос производительности? Если речь о стиле, то вынести в inline можно точно так же, как и все остальное -в том же стиле. Объявление в теле - определение ниже или в отдельном impl файле. За примерами далеко ходить не надо, можно посмотреть стандартную библиотеку.

Сообщение от Undisputed Может быть, вот пытаюсь осознать

Больше похоже на то, что пытаешься поспорить в вопросе, в котором разбираешься поверхностно

Добавлено через 54 секунды

Сообщение от Undisputed Сразу внутри класса пишут

Там шаблоны. Про шаблоны я сразу оговорился, что настолько концентрированный шаблонный код в продакшене не пишут (или пишут очень редко).

1

Сообщение от DrOffset Изменение инлайн метода в таком заголовочном файле приводит к перекомпиляции всех зависимых от этого файла исходников.

Теперь понял. Думал речь о зависимостях в самом коде.

Сообщение от DrOffset Профилирование все равно нужно, к тому же замедление может быть вовсе не из-за наличия\отсутствия inline, а из-за алгоритмов, что бывает гораздо чаще.

Согласен... я же не отказывался от профилирования)

Сообщение от DrOffset Объявление в теле - определение ниже или в отдельном impl файле.

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

Сообщение от DrOffset Больше похоже на то, что пытаешься поспорить в вопросе, в котором разбираешься поверхностно

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

0

Сообщение от Undisputed В первую очередь хочется писать реализацию в классе для однообразности...

Хочется-не хочется, а обычно делают-то как раз наоборот.
Да и все-таки по исходному вопросу.
а) Проектирование класса начинается с определения операций, которые доступны с его объектами. Это всегда публичный интерфейс (в общем смысле слова).
б) Пользователям класса безразличны его приватные данные. Есть даже паттерны (pimpl), которые специально дополнительно скрывают их. Цели у них две - повышение инкапсуляции и понижение связности ⁽¹⁾.
Собственно, это основные причины, почему публичную секцию пишут вначале. Остальные вопросы, вроде стиля и т.п., второстепенны.

_____
⁽¹⁾ например, техника pimpl в Qt позволила стабилизировать ABI и сделать его независимым от приватных данных класса. Если разработчики что-то меняют в них, то это никак не отражается на уже скомпилированных бинарниках, в пределах широкого диапазона версий.

Сообщение от Undisputed хотя может какой то компилятор так может

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

1

Сообщение от DrOffset Проектирование класса начинается с определения операций, которые доступны с его объектами. Это всегда публичный интерфейс (в общем смысле слова).

+1 сам стараюсь так делать но думаю это не требует наличия хедер файла... но с ним конечно лучше (можно хранить интерфейс отдельно и даже писать комментарии к чему нужен этот метод) - удобно.. типа справочный файл

Сообщение от DrOffset Пользователям класса безразличны его приватные данные. Есть даже паттерны (pimpl), которые специально дополнительно скрывают их. Цели у них две - повышение инкапсуляции и понижение связности

В целом согласен. Но если на то пошло - программисты которые открыли исходники редко смотрят просто хедер файл и все. В зависимости от степени интереса таким товарищам может быть интересно все вплоть до приватных полей А пользователи какой нибудь либы смотрят доки на каком нибудь сайте где есть список методов и их сигнатура... Но на уровне доков уже без разницы как оно там внутри разделено Думаю основной аргумент пимпла это все же снижение времени компиляции но как приятный побочный эффект - получается более чистый хедер ввиду отсутствия полей кроме указателя impl...

В принципе основную мысль я уловил (хоть местами меня кое что не устраивает) но суть то стала более менее ясна.
Спасибо

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

Сообщение от Undisputed типа справочный файл

Ну и время компиляции конечно же снижается

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

Сообщение от DrOffset Это называется генерация кода на этапе линковки (тут есть примеры), и так сейчас могут почти все, со специальным ключом.

А инлайн с таким ключиком гарантируется или "если смогу то сделаю" ?

0

Сообщение от Undisputed но думаю это не требует наличия хедер файла

Изначально речи про заголовочные файлы вообще не шло И я на этом внимание не акцентировал.

Сообщение от Undisputed В зависимости от степени интереса таким товарищам может быть интересно все вплоть до приватных полей

Нет резонных оснований думать, что перестановка местами секций им существенно поможет. Напротив, чем более традиционно будет оформлен код, тем проще его изучать. Поэтому раз уж ты и сам заметил, что так делают многие, то можно предположить, что это и есть ожидаемое оформление.
А в остальном быстро изучить исходник помогут различные доступные сейчас утилиты, не 90й год, как-никак.

Сообщение от Undisputed Спасибо

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

Сообщение от Undisputed А инлайн с таким ключиком гарантируется или "если смогу то сделаю" ?

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

2

DrOffset,
Вот в данный момент я пишу класс который очень горячий ))
Его экземпляры создаются и используются в цикле и хочется все вызовы заинлайнить вплоть до конструкторов (один шаблонный).
Но когда я делю на хедер и спп то код не компилируется потому что в сппшник надо инклюдить хедер а в хедер сппшник то бы в нем было определение методов и таком образом чтоб был инлайн... возникает двойное объявление класса и код не компилируется.

Ты как советуешь в таком случае поступить?
Я пока думаю инклюдить сппшник в хедер но в сппшник хедер не добавлять и при этом исключить из компиляции сам сппшник
Таким образом я ожидаю что в хедер при помощи инклюда попадет реализация при этом отдельно она компилироватся не будет

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

Добавлено через 11 минут
Ну и еще естественно можно убрать сппшник и написать реализацию вне класса...
Или как изначально мне хотелось - написать все внутри)) но ты меня отговорил поэтому хотелось бы узнать как сделать лучше учитывая то что писать реализацию внутри класса нежелательно))

0

Undisputed, Очевидно, писать их в cpp. Выносить в inline после доказательств, что встраивание улучшает ситуацию. Если код шаблонный - возможны варианты, писать в теле класса (обычно этот вариант выбирают, когда много коротких функций, а вынос функций повлечет написание множество "лишнего" кода - особенно актуально для многоуровневых шаблонов) или выносить в отдельный включаемый файл (этот способ выбирают, когда сами шаблонные функции достаточно крупные). И тот и другой варианты представлены в реализации std::.

По поводу inline, можно почитать классиков здесь (или в его книгах).
Советы те же, только более развернуто.

Еще можно посмотреть вот это видео.

1

Сообщение от DrOffset Очевидно, писать их в cpp. Выносить в inline после доказательств, что встраивание улучшает ситуацию.

Вот предположим что уже доказано и все надо инлайнить

Сообщение от DrOffset Если код шаблонный - возможны варианты,

Там два конструктора один из которых шаблонный

Методы мелкие. 1-5 строк
Спасибо за ссылки

0

Сообщение от Undisputed Вот предположим что уже доказано и все надо инлайнить

Ладно
Тогда в вопросе "как писать" все упирается в корпоративные стандарты (или твои собственные стандарты, если работаешь один).

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

1

Сообщение от Undisputed ИМХО все остальные аргументы так себе

Аргумент, который заставил меня делить на два файла (а то и на три (шаблонные методы)) каждый класс - циклические зависимости.

Сообщение от Undisputed Но хотелось бы делить на хедер и спп и чтоб работал инлайн

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

Сообщение от Undisputed Но когда я делю на хедер и спп то код не компилируется потому что в сппшник надо инклюдить хедер а в хедер сппшник то бы в нем было определение методов и таком образом чтоб был инлайн... возникает двойное объявление класса и код не компилируется.

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

1

Сообщение от Lyosha12 но в проект его не включаем

Да можно и включить, если это, конечно, не файл cpp (чего в общем-то не делают).

0