История изменений
Исправление Iron_Bug, (текущая версия) :
при правильной организации разделения функциональности инлайн вызовы между модулями исключены. это называется проектированием архитектуры ПО. если между разными модулями возникли тесные интимные отношения, значит что-то не так с общей архитектурой и бороться с мелкой фигней бесполезно, надо пересматривать всё сверху.
в крупном проекте может быть много модулей. но, как правило, они относительно независимы и каждый выполняет свой функционал, не дёргая остальных по каждому пустяку. более того, чаще всего их разрабатывают разные разработчики или даже разные компании. если же вопрос по поводу инлайна всё-таки возник, ничто не мешает вынести этот общий функционал в отдельный файл и компилить его с инлайном куда заблагорассудится. однако, повторяю, при нормальном планировании такие вывихи не должны возникать.
и да, я не видела ни одного проекта, где боттлнеком были бы вызовы функции. основные тормоза, как правило, в синхронизации доступа к ресурсам, в операциях ввода-вывода, в сетевом обмене. но никак не в вызовах. поэтому я очень сильно сомневаюсь, что инлайны хоть как-то могут отразиться на оптимизации крупной софтины и прибавить хоть миллионную долю скорости. зато объём кода подрастёт, что не всегда нужно.
Исправление Iron_Bug, :
при правильной организации разделения функциональности инлайн вызовы между модулями исключены. это называется проектированием архитектуры ПО. если между разными модулями возникли тесные интимные отношения, значит что-то не так с общей архитектурой и бороться с мелкой фигней бесполезно, надо пересматривать всё сверху.
в крупном проекте может быть много модулей. но, как правило, они относительно независимы и каждый выполняет свой функционал, не дёргая остальных. более того, чаще всего их разрабатывают разные разработчики или даже разные компании. если же вопрос по поводу инлайна всё-таки возник, ничто не мешает вынести этот общий функционал в отдельный файл и компилить его с инлайном куда заблагорассудится. однако, повторяю, при нормальном планировании такие вывихи не должны возникать.
и да, я не видела ни одного проекта, где боттлнеком были бы вызовы функции. основные тормоза, как правило, в синхронизации доступа к ресурсам, в операциях ввода-вывода, в сетевом обмене. но никак не в вызовах. поэтому я очень сильно сомневаюсь, что инлайны хоть как-то могут отразиться на оптимизации крупной софтины и прибавить хоть миллионную долю скорости. зато объём кода подрастёт, что не всегда нужно.
Исходная версия Iron_Bug, :
при правильной организации разделения функциональности инлайн вызовы между модулями исключены. это называется проектированием архитектуры ПО. если между разными модулями возникли тесные интимные отношения, значит что-то не так с общей архитектурой и бороться с мелкой фигней бесполезно, надо пересматривать всё сверху.
в крупном проекте может быть много модулей. но, как правило, они относительно независимы и каждый выполняет свой функционал, не дёргая остальных. более того, чаще всего их разрабатывают разные разработчики или даже разные компании. если же вопрос по поводу инлайна всё-таки возник, ничто не мешает вынести этот общий функционал в отдельный файл и компилить его с инлайном куда заблагорассудится. однако, повторяю, при нормальном планировании такие вывихи не должны возникать.