Многовато кода генерируется компилятором, не правда ли? Именно из-за такого разбухания кода, в некоторых крупных корпорациях (не будем тыкать пальцем в Google) при разработке на С++ запрещено использование исключений. Еще одним примером могут послужить правила разработки для GCC начиная с версии 4.8 (да, GCC теперь разрабатывается с использованием С++, см изменения для 4.8).
В этом Google C++ Style Guide пункт про размер бинарника идёт четвёртым из пяти аргументов против, а в GCC Coding Conventions вовсе отсутствует.
Очевидно, разбухание кода не является столь важной проблемой для корпораций, как это подано в статье. Кроме того, эксепшены и весь сопутствующий механизм ориентированы на минимизацию оверхеда в случае, когда они не бросаются.
Но, кстати, в плане стандартной библиотеки, многое (в gnu stl например) просто перетащено из буста, где уже и без этих нововведений в некотором виде существовало.
Вообще ведь все эти эксепшены ориентированы не на ситуацию, когда после них программа тупо падает, даже выводя чего-нибудь информативное.
Их суть в удобной обработке редко возникающих ошибок. Именно обработке, после которой программа продолжает нормальную работу, без утечек памяти и прочих неприятностей.
Так что, на мой взгляд, отсутствие в стандарте функции стэк трейса неудивительно. Для этого, как сказали выше, можно использовать всякие сторонние средства.
В простых программах никто не требует эти нововведения использовать.
А если программа достаточно сложна, чтобы в них нуждаться, то это лишь упрощает код (уменьшает объём, повышает читаемость или т.п), ну или даёт бонус в производительности, для некоторых нововведений.
Вообще, все эти нововведения весьма подробно аргументируются, по крайней мере те, что я читал. Ничего бесполезного, на мой взгляд, в C++ не попадает.
Но, в общем то, польза в формальной спецификации exception-safety есть. Как минимум, когда я пишу exception-safety код, я обращаю внимание на спецификацию вызываемых функций. Это даёт возможность не использовать лишний раз RAII, при должном кодировании.
Также nothrow спецификация move конструкторов требуется в контейнерах, чтобы гарантировать безопасное перемещение элементов.
Безусловно, лучше не писать nothrow, если нет уверенности. В C++ полно вещей, которыми можно отстреливать ноги :)
А сам nothrow лишь возможность вынести спецификации на уровень языка (и дать возможность анализировать её компилятору) и избавиться от, как минимум, возможных утечек памяти, и, как максимум, от Undefined behavior.
market.yandex.ru/model.xml?hid=723088&modelid=4914742
у этой мыши есть функция быстрой прокрутки, когда колесо ничем не блокируется (кроме трения), и может от одного толчка крутиться очень долго (и быстро).
Удобно
ru.wikipedia.org/wiki/Инфракрасная_фотография
В этом Google C++ Style Guide пункт про размер бинарника идёт четвёртым из пяти аргументов против, а в GCC Coding Conventions вовсе отсутствует.
Очевидно, разбухание кода не является столь важной проблемой для корпораций, как это подано в статье. Кроме того, эксепшены и весь сопутствующий механизм ориентированы на минимизацию оверхеда в случае, когда они не бросаются.
Но, кстати, в плане стандартной библиотеки, многое (в gnu stl например) просто перетащено из буста, где уже и без этих нововведений в некотором виде существовало.
Их суть в удобной обработке редко возникающих ошибок. Именно обработке, после которой программа продолжает нормальную работу, без утечек памяти и прочих неприятностей.
Так что, на мой взгляд, отсутствие в стандарте функции стэк трейса неудивительно. Для этого, как сказали выше, можно использовать всякие сторонние средства.
А если программа достаточно сложна, чтобы в них нуждаться, то это лишь упрощает код (уменьшает объём, повышает читаемость или т.п), ну или даёт бонус в производительности, для некоторых нововведений.
Вообще, все эти нововведения весьма подробно аргументируются, по крайней мере те, что я читал. Ничего бесполезного, на мой взгляд, в C++ не попадает.
Также nothrow спецификация move конструкторов требуется в контейнерах, чтобы гарантировать безопасное перемещение элементов.
Безусловно, лучше не писать nothrow, если нет уверенности. В C++ полно вещей, которыми можно отстреливать ноги :)
А сам nothrow лишь возможность вынести спецификации на уровень языка (и дать возможность анализировать её компилятору) и избавиться от, как минимум, возможных утечек памяти, и, как максимум, от Undefined behavior.
?
Всё правильно делают
megaswf.com/serve/1001478/
megaswf.com/serve/1031310/
Но очень интересно наблюдается
www.rutor.org/torrent/58161
Та 60fps нарезка кадров из Аватара отсюда.
ru.wikipedia.org/wiki/Deinterlacing
Хорош тем, что будет работать абсолютно везде
у этой мыши есть функция быстрой прокрутки, когда колесо ничем не блокируется (кроме трения), и может от одного толчка крутиться очень долго (и быстро).
Удобно