2 вопроса по С++
виртуальные — увеличивают на размер таблички с указателями.
невиртуальные — нет, может даже в стандарте это гарантируется.
невиртуальные — нет, может даже в стандарте это гарантируется.
виртуальные — увеличивают на размер таблички с указателями.Нет, на размер одного указателя, который будет ссылаться на табличку с указателями.
Потому что неперехваченные и неожиданные исключения - разные вещи.
Спссибо всем ответившим. А почему нельзя обойтись лишь неожиданными? Если честно, не понял отличий.
так это в стандарте прописано? там вроде по разному можно было делать.
В стандарте может быть и не прописано, но обычно реализуется так. Может быть можно всю таблицу в объекте хранить, это будет на одно разыменование указателя быстрее.
ну я просто помню, что в каком-то компиляторе так сделано.
Это прописано в C++ ABI. ABI на данный момент в виде стандарта есть только для IA-64, но де-факто для IA-32 все так же с поправкой на размеры указателей.
в стандарте не обговаривается. В том числе и реализация полиморфизма тоже не регламентирована. Но в известных мне случаях полиморфизм реализуется через vtables, там чем их больше (чем множественнее наследование виртуальных функций) тем больше размер объекта.
Ну, э, неожиданное исключение - которое произошло не по спецификации твоей функции.
Неперехваченное - которое не перехвачено к моменту, когда весь стек нафик раскручен, и надо решать, что делать дальше. Почему ты обязан хотеть для них одинаковой обработки?
Неперехваченное - которое не перехвачено к моменту, когда весь стек нафик раскручен, и надо решать, что делать дальше. Почему ты обязан хотеть для них одинаковой обработки?
А приведи пример ситуации с неперехваченным исключением, плз.
Кому достаются неперехваченные исключения? Тому, кто дальше пользуется твоим кодом?
Кому достаются неперехваченные исключения? Тому, кто дальше пользуется твоим кодом?
int main
{
throw 5;
}
В данном случае будет вызван обработчик неперехваченных исключений, который вызовет terminate и прога твоя сдохнет самым некрасивым образом.
Почитай все же Страуструпа.
{
throw 5;
}
В данном случае будет вызван обработчик неперехваченных исключений, который вызовет terminate и прога твоя сдохнет самым некрасивым образом.
Почитай все же Страуструпа.
Кому достаются неперехваченные исключения? Тому, кто дальше пользуется твоим кодом?
Вообще да, если дальше кто-то есть.
В данном случае будет вызван обработчик неперехваченных исключений, который вызовет terminate и прога твоя сдохнет самым некрасивым образом.Читал, но не до конца въехал. Значит - обработчик неперехваченных исключений нужен лишь для того, чтобы в тех местах, где будет использоваться этот код, все было поэлегантней?
Почитай все же Страуструпа.
Эээ... Несколько не понял вопроса.
Если ты пишешь библиотеку, то это не твое дело, как ее пользователи будут использовать твои исключения, и использовать ли вообще. По-моему, в этом суть такого стиля обработки ошибок.
Если ты пишешь библиотеку, то это не твое дело, как ее пользователи будут использовать твои исключения, и использовать ли вообще. По-моему, в этом суть такого стиля обработки ошибок.
Оставить комментарий
zrab
1) Зачем нужен обработчик неперехваченных исключений, если есть обработчик неожиданных исключений?2) Увеличивают ли методы класса размер конкретного объекта (с типом этого класса)? (Мне кажется, что незначительно, но почему?)