В проекте (MSVC++ 7.1) есть класс, представляющий арифметический тип данных, и очень активно использующийся в вычислениях. Соответственно, у него есть куча перегруженных операторов (+, -, *, / и т. д.), возвращающих естественно объект этого класса. Большинство из них очень просты, а так как очень важна производительность, то хотелось бы сделать их встроенными. Но компилятор не может их встраивать при включенной поддержке C++ Exceptions, т.е. MSDN говорит:
Even with __forceinline, the compiler cannot inline code in all circumstances. The compiler cannot inline a function if:
...
The function returns an unwindable object by value, when compiled with /GX, /EHs, or /EHa.
С выключенными C++ Exceptions проверено, все нормально, он их встраивает в места вызова.
Пробовал указывать явно операторам и членам классов, что они не вызывают исключения (throw() и __declspec(nothrow)), но видимо это никакой роли не играет, важно что проект компилируется с /EHs. Установить отдельные опции компиляции на нужные файлы не получается, потому что определения функций должны находиться в заголовочных файлах, чтобы компилятор имел определение этих функций в каждом месте использования еще до линковки.
Вопрос. Как же всё-таки сделать функцию, возвращающую объект некоторого класса, встроенной, не выключаю поддержку C++ исключений для всего проекта?
Здравствуйте, twisted_mind, Вы писали:
_>В проекте (MSVC++ 7.1) есть класс, представляющий арифметический тип данных, и очень активно использующийся в вычислениях. Соответственно, у него есть куча перегруженных операторов (+, -, *, / и т. д.), возвращающих естественно объект этого класса. Большинство из них очень просты, а так как очень важна производительность, то хотелось бы сделать их встроенными. Но компилятор не может их встраивать при включенной поддержке C++ Exceptions, т.е. MSDN говорит:
_>Even with __forceinline, the compiler cannot inline code in all circumstances. The compiler cannot inline a function if: _>... _>The function returns an unwindable object by value, when compiled with /GX, /EHs, or /EHa.
_>С выключенными C++ Exceptions проверено, все нормально, он их встраивает в места вызова.
_>Пробовал указывать явно операторам и членам классов, что они не вызывают исключения (throw() и __declspec(nothrow)), но видимо это никакой роли не играет, важно что проект компилируется с /EHs. Установить отдельные опции компиляции на нужные файлы не получается, потому что определения функций должны находиться в заголовочных файлах, чтобы компилятор имел определение этих функций в каждом месте использования еще до линковки.
_>Вопрос. Как же всё-таки сделать функцию, возвращающую объект некоторого класса, встроенной, не выключаю поддержку C++ исключений для всего проекта?
1) Никогда не оптимизируйте
2) Если уж взялись оптимизировать — см. пункт 1
Г.Саттер "Решение сложных задач на с++"
Почитай, будет полезно. Если серьезно, то молится на чьи-то мысли не всегда хорошо, однако он говорит об умных вещах — "сначала смотреть профайлером".
Здравствуйте, twisted_mind, Вы писали:
_>Вопрос. Как же всё-таки сделать функцию, возвращающую объект некоторого класса, встроенной, не выключаю поддержку C++ исключений для всего проекта?
Предоставь это дело компилятору: в общем случае он лучше тебя знает, что и как надо оптимизировать.
За подробностями, как уже писали, можешь обратиться к Саттеру.
КЛ>1) Никогда не оптимизируйте КЛ>2) Если уж взялись оптимизировать — см. пункт 1
КЛ>Г.Саттер "Решение сложных задач на с++"
КЛ>Почитай, будет полезно. Если серьезно, то молится на чьи-то мысли не всегда хорошо, однако он говорит об умных вещах — "сначала смотреть профайлером".
Это мнение Саттера для меня не новое, и на этом форуме по-моему уже вызывало жаркие споры.
Я сравнивал код, который генерируется в случае встроенной функции и в случае вызова — на то, чтобы положить адреса в стек и вызвать функцию тратится больше времени, чем собственно на вычисления.
А вообще меня этот вопрос уже интересует больше с академической точки зрения. Я просто не верю, что у этой проблемы нет нормального решения
Здравствуйте, Dmitry Kotlyarov, Вы писали:
DK>Здравствуйте, twisted_mind, Вы писали:
_>>Вопрос. Как же всё-таки сделать функцию, возвращающую объект некоторого класса, встроенной, не выключаю поддержку C++ исключений для всего проекта?
DK>Предоставь это дело компилятору: в общем случае он лучше тебя знает, что и как надо оптимизировать. DK>За подробностями, как уже писали, можешь обратиться к Саттеру.
В том то и дело, что он НЕ МОЖЕТ сделать их встроенными в принципе при включенной поддержке исключений. Соответственно, можно сказать, что компилятор их не встраивает ТОЛЬКО ПОТОМУ, что у него нету другого выбора. А я хочу этот выбор ему предоставить. Тогда можно говорить о том, что предлагаете Вы.
ИМХО, если не определять деструктор у класса (оставить его на откуп компилятору), то компилятор сможет произвести встраивание вышеописанных операторов. Конечно, если нужен именно явно определенный деструктор (т.е. генерируемый компилятором не подходит по каким-либо причинам), то придется смириться с дополнительными накладными расходами на невстроенные вызовы операторов.
Здравствуйте, Aznog, Вы писали:
A>Здравствуйте, twisted_mind, Вы писали:
A>ИМХО, если не определять деструктор у класса (оставить его на откуп компилятору), то компилятор сможет произвести встраивание вышеописанных операторов. Конечно, если нужен именно явно определенный деструктор (т.е. генерируемый компилятором не подходит по каким-либо причинам), то придется смириться с дополнительными накладными расходами на невстроенные вызовы операторов.
Спасибо. Это действительно помогло. А не могли бы Вы пояснить, с чем связано такое поведение компилятора. В частности, какие требованию к деструктору здесь являются определяющими и можно ли как-то определить свой деструктор, сохранив такое поведение?
Здравствуйте, twisted_mind, Вы писали:
_>Спасибо. Это действительно помогло.
Пожалуйста
_>А не могли бы Вы пояснить, с чем связано такое поведение компилятора.
ИМХО, наверняка это связано с особенностями реализации обработки исключений данным компилятором.
_>В частности, какие требованию к деструктору здесь являются определяющими и можно ли как-то определить свой деструктор, сохранив такое поведение?
Еще раз ИМХО.
Единственно требование в данной ситуации — это отсутствие явно определенного деструктора (в этом случае компилятор сам генерирует деструктор, точно зная, какие действия этот деструктор выполняет, что может повлиять на то, как будет происходить раскрутка стека при исключении).
