Здравствуйте, Sheridan, Вы писали:

Либо ты не работал над реальными огромными проектами, а так, демками из книжек баловался. На второй неделе, ага

Здравствуйте, CreatorCray, Вы писали:

H>>Ну, когда вынужден ради функции int GetValue() {return a;} создавать отдельный файл — да, плохой знак.
CC>Зачем отдельный? Что мешает её оставить в .h?
Маленький, наглый и громкий внутренний перфекционист.

Так как ты предлагаешь — можно писать, да. Можно даже всё в одном файле написать, но зачем?
Смотри, есть две крайности:
1. Всё в одном файле
2. Каждый метод реализуется в отдельном файле.
Ты волен выбирать любой вариант в промежутке между 1 и 2, включая 1 и 2.

Здравствуйте, Homunculus, Вы писали:

H>Либо ты не работал над реальными огромными проектами, а так, демками из книжек баловался. На второй неделе, ага
Ладно-ладно, уговорил, на второй час уже можно с инклудом разобраться чтобы ни циклических, ни множественных не было.

Здравствуйте, Sheridan, Вы писали:

S>Так как ты предлагаешь — можно писать, да. Можно даже всё в одном файле написать, но зачем?
На то есть рациональные причины.

S>Смотри, есть две крайности:
S>1. Всё в одном файле
Дык крайности по определению плохо.

S>2. Каждый метод реализуется в отдельном файле.
И сразу теряем на возможности инлайнинга, чтобы вернуть которую надо включать WPO а что по сути является переносом компиляции всего на этап линковки и требует "много нефти" (tm), ибо технически сводится к первой крайности
Этот подход имеет своё применение при написании либ, когда методы большие и надо точно быть уверенным что компилятор не поместит их в один сегмент.

Здравствуйте, Константин Б., Вы писали:

КБ>Какие именно умеют? В студии и CLion ничего такого не нашел.

Про студию я не в курсе, а в CLion в рамках рефакторинга всё это есть.

Здравствуйте, CreatorCray, Вы писали:

S>>Так как ты предлагаешь — можно писать, да. Можно даже всё в одном файле написать, но зачем?
CC>На то есть рациональные причины.
Расскажи о них. Лично я вижу только одну: сплошные шаблоны. Да и то настолько всё плохо, что нельзя реализацию шаблонов в отдельном файле написать и включить его в заголовок (да, наоборот).


S>>Смотри, есть две крайности:
S>>1. Всё в одном файле
CC>Дык крайности по определению плохо.
Именно.


S>>2. Каждый метод реализуется в отдельном файле.
CC>И сразу теряем на возможности инлайнинга, чтобы вернуть которую надо включать WPO а что по сути является переносом компиляции всего на этап линковки и требует "много нефти" (tm), ибо технически сводится к первой крайности
CC>Этот подход имеет своё применение при написании либ, когда методы большие и надо точно быть уверенным что компилятор не поместит их в один сегмент.
А тебе ли не положить как оно там компилирует и насколько оно напрягается для компиляции?
Ты уверен что нужно облегчать работу железной голове, жертвуя своим удобством?

Здравствуйте, Sheridan, Вы писали:

S>>>Так как ты предлагаешь — можно писать, да. Можно даже всё в одном файле написать, но зачем?
CC>>На то есть рациональные причины.
S>Расскажи о них.
Да тот же инлайнинг.
Функция-геттер, которая тупо возвращает значение может быть заинлайнена.
В c/cpp файл есть смысл выносить что то большое.

S>Да и то настолько всё плохо, что нельзя реализацию шаблонов в отдельном файле написать и включить его в заголовок (да, наоборот).
Почему это вдруг нельзя? Или ты тут что то другое имел в виду на самом деле.

S>А тебе ли не положить как оно там компилирует и насколько оно напрягается для компиляции?
Нет, не положить. Мне важен результат. Я ещё и на сгенерённый код порой смотрю.

S>Ты уверен что нужно облегчать работу железной голове, жертвуя своим удобством?
Я уверен что не надо пессимизировать на ровном месте.

Здравствуйте, CreatorCray, Вы писали:


S>>>>Так как ты предлагаешь — можно писать, да. Можно даже всё в одном файле написать, но зачем?
CC>>>На то есть рациональные причины.
S>>Расскажи о них.
CC>Да тот же инлайнинг.
CC>Функция-геттер, которая тупо возвращает значение может быть заинлайнена.
inline уже deprecated? Ну и вот тут тоже почитай

CC>В c/cpp файл есть смысл выносить что то большое.
Ну как по мне — либо к умным, либо к красивым. Но без фанатизма

S>>Да и то настолько всё плохо, что нельзя реализацию шаблонов в отдельном файле написать и включить его в заголовок (да, наоборот).
CC>Почему это вдруг нельзя? Или ты тут что то другое имел в виду на самом деле.
Ну я так понял что ты вообще всё хочешь в хидере писать. Видимо неправильно понял.

S>>А тебе ли не положить как оно там компилирует и насколько оно напрягается для компиляции?
CC>Нет, не положить. Мне важен результат. Я ещё и на сгенерённый код порой смотрю.
Ну лично я бы предпочёл пользоваться возможностями языка и делать удобно себе, а не компутеру.

S>>Ты уверен что нужно облегчать работу железной голове, жертвуя своим удобством?
CC>Я уверен что не надо пессимизировать на ровном месте.
Преждевременно оптимизировать тоже не стоит. Компилятор, ВНЕЗАПНО, может сгенерировать более оптимальный код по умолчанию.

Здравствуйте, Sheridan, Вы писали:

CC>>Функция-геттер, которая тупо возвращает значение может быть заинлайнена.
S>inline уже deprecated? Ну и вот тут тоже почитай
Когда имплементация затолкана в отдельный с/cpp хоть обвешайся inline, но вне этого c/cpp ничего есессна заинлайнено не будет.
Чтоб хоть как то попытаться это поправить придётся расчехлять PGO а это будет как из Доры по сусликам хреначить. Суслика в итоге может быть и накроет, но вот какой ценой?
Куда проще будет сразу сделать правильно.

CC>>В c/cpp файл есть смысл выносить что то большое.
S>Ну как по мне — либо к умным, либо к красивым. Но без фанатизма
Бессмыслица какая то.

S>Ну я так понял что ты вообще всё хочешь в хидере писать. Видимо неправильно понял.
Да просто капец как неправильно.

CC>>Нет, не положить. Мне важен результат. Я ещё и на сгенерённый код порой смотрю.
S>Ну лично я бы предпочёл пользоваться возможностями языка и делать удобно себе, а не компутеру.


S>Компилятор, ВНЕЗАПНО, может сгенерировать более оптимальный код по умолчанию.
Внезапно, надо таки понимать как используемый инструмент работает.
К примеру вумные люди говорят что бензопилой пилить куда сподручнее если в неё таки залить бензин.
А ещё ловчее выходит если после этого её ещё и завести.

Так шта если компилеру вбрасывать гаечные ключи в шестерёнки то он при всём старании чудес совершить не сможет.
Так что не надо совершать детские ошибки и класть в лесопилку железный лом.

Здравствуйте, Sheridan, Вы писали:

S>inline уже deprecated? Ну и вот тут тоже почитай

Вообще то модификатор inline совсем для другого работает. Более того, если ты посмотришь на пример кода по своей же собственной ссылке, то увидишь, что там функция с этим модификатором расположена опять же в h файле. )))

Здравствуйте, alex_public, Вы писали:

_>Вообще то модификатор inline совсем для другого работает. Более того, если ты посмотришь на пример кода по своей же собственной ссылке, то увидишь, что там функция с этим модификатором расположена опять же в h файле. )))
Так?

Здравствуйте, Sheridan, Вы писали:

_>>Вообще то модификатор inline совсем для другого работает. Более того, если ты посмотришь на пример кода по своей же собственной ссылке, то увидишь, что там функция с этим модификатором расположена опять же в h файле. )))
S>Так?

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

Реальный же инлайн функций, как известно, полностью определяется настройками компилятора, а не какими-то там модификаторами. Но при этом очевидно, что для его хотя бы потенциальной возможности совершенно необходимо наличие в единице трансляции исходного кода функции, которую мы хотим заинлайнить. В случае размещения кода внутри определения класса это выполняется автоматически. А в случае размещения кода функции в cxx файлах (с модификатором inline на случай если компилятор откажется делать реальный инлайн), тебе ради шанса на инлайн придётся скопировать этот код руками в каждый из них, где используется твой класс. Очевидно, что подобную глупость никто и никогда не делает, а всегда размещают такой код один раз, в том же hpp файле, что и определение класса.

Здравствуйте, alex_public, Вы писали:

_>Смотри, наличие модификатора inline и размещение кода метода внутри определения класса — это по сути синонимы ...
А тут как раз разговор про оформление кода — пользовать inline и размещать реализацию в cpp или не пользовать и реализовывать метод сразу в заголовке. Я предпочту inline.

Здравствуйте, Sheridan, Вы писали:

_>>Смотри, наличие модификатора inline и размещение кода метода внутри определения класса — это по сути синонимы ...
S>А тут как раз разговор про оформление кода — пользовать inline и размещать реализацию в cpp

от такого применения инлайна толку 0 целых хрен десятых

Здравствуйте, Sheridan, Вы писали:

_>>Смотри, наличие модификатора inline и размещение кода метода внутри определения класса — это по сути синонимы ...
S>А тут как раз разговор про оформление кода — пользовать inline и размещать реализацию в cpp или не пользовать и реализовывать метод сразу в заголовке. Я предпочту inline.

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

Ну разве что ты не будешь делать #include этого самого cpp файла, во всех остальные cpp файлы... Вот при такой архитектуре твой подход будет работать... )))

Здравствуйте, alex_public, Вы писали:

_>Так я же тебе вроде чётко описал в предыдущем сообщение, что такое использование inline просто не будет делать ничего. И будет гарантировать отсутствие реального инлайна функций.
Угу, компилятор тупой. Ок.

Здравствуйте, Sheridan, Вы писали:

_>>Так я же тебе вроде чётко описал в предыдущем сообщение, что такое использование inline просто не будет делать ничего. И будет гарантировать отсутствие реального инлайна функций.
S>Угу, компилятор тупой. Ок.

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

Здравствуйте, Sheridan, Вы писали:

S>пользовать inline и размещать реализацию в cpp

Здравствуйте, PM, Вы писали:

S>>Угу, компилятор тупой. Ок.
PM>Наоборот же, компилятор слишком умный и имеет больше информации, чем программист расставляющий бесполезные inline.

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

И в принципе эта его тупость вроде как легко излечивается с помощью включения LTO.

Однако на практике это работает только для простеньких проектов: хотел бы я посмотреть на тех, кто попытается собрать например Chromium или Qt с включённой LTO...

Здравствуйте, alex_public, Вы писали:

S>>>Угу, компилятор тупой. Ок.
PM>>Наоборот же, компилятор слишком умный и имеет больше информации, чем программист расставляющий бесполезные inline.

_>На самом деле в данном случае компилятор действительно тупой, т.к. не может сделать определённые полезные оптимизации без помощи от программиста (в виде размещения нужного кода в hpp файле).

А ну в этом смысле да, программисту приходится пока писать код руками, а в C++ так вообще иногда надо выбирать, где ссылку для аргумента функции использовать, где по значению передавать.

_>И в принципе эта его тупость вроде как легко излечивается с помощью включения LTO.

_>Однако на практике это работает только для простеньких проектов: хотел бы я посмотреть на тех, кто попытается собрать например Chromium или Qt с включённой LTO...

Так вроде же в Гугле делали ThinLTO как раз для сборки Хрома, или я что-то путаю?