[AHTOXA 15]

PS видать это вовсе не исключения так весят а аллокатор памяти!

Посмотрите map-файл, и увидите, что это всё-таки исключения. К сожалению, ключик -fno-exceptions не всегда соблюдается.

Попробуйте объявить new/delete как

void * operator new (size_t size, const std::nothrow_t&) throw()
{
...
}

void operator delete(void * pobject, const std::nothrow_t&) throw()
{
..
}

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

[glonium 0]

Посмотрите map-файл, и увидите, что это всё-таки исключения.

Я если честно не до конца разобрался как пользоваться map и как от туда узнать что сколько весит (непонятные имена функций)

Подскажите пожалуйста где можно прочитать про map!

Заранее спасибо!

[AHTOXA 15]

А чего там уметь-то? Смотрите, видите "eh_exception.o" - значит, исключения присутствуют:)

Ну а так, там в самом начале есть строчка:

Archive member included because of file (symbol)

То есть, формат такой

подключенная_библиотека (имя_объекта_из_этой_библиотеки.o) имя_файла_из_за_которого_подключили_этот_библиотечный_объект (имя_функции_из_за_которой_подключили)

 

Попробуйте сделать, как я сказал в предыдущем сообщении, думаю, что поможет.

Кстати, не забудьте остальные варианты new/delete:

void * operator new(size_t size){ return operator new(size, std::nothrow); }
void operator delete(void * pobject){ operator delete(pobject, std::nothrow); }
void * operator new[](size_t size){ return operator new(size, std::nothrow); }
void operator delete[](void * pobject){ operator delete[](pobject, std::nothrow); }
void * operator new[](size_t size, const std::nothrow_t&) throw(){ return operator new(size, std::nothrow); }
void operator delete[](void * pobject, const std::nothrow_t&) throw(){ operator delete(pobject, std::nothrow); }

[glonium 0]

Да очень жаль конечно что всё это весит много!

В проекте планировалось использовать dunamic_cast<> (RTTI) для реализации подобия интерфейсов.

Народ а может кто подсказать если я использую RTTI и throw то к программе добавляется кусок порядка 80кБ, есть ли гарантия что он не вырастет необоснованно? Т.е один раз приклеился и всё больше ничего не надо!

[Артём__ 0]

В проекте планировалось использовать dunamic_cast<> (RTTI) для реализации подобия интерфейсов.

А что такого вам даёт RTTI?

Интерфейсы в С++ ведь реализуются с помощью абстрактных классов с наследованием. Этого недостаточно?

[glonium 0]

так то так но вот предположим у нас есть список объектов базоаого класса в виде указателей на них, при помощи dynamic_cast<*Iface> можно определить поддерживает ли данный инстанс интерфейс Iface и заодно преобразовать к классу интерфейса, если не поддерживает dynamic_cast вернёт NULL!

 

Конечно можно поступить и менее красиво, держать в классе флаги поддержки интерфейса и по их значениям кастовать!

 

Или ещё вариант но тоже менее красивый завести виртуальные функции которые кастуют к конкретному интерфейсу!

[alx2 0]

Народ а может кто подсказать если я использую RTTI и throw то к программе добавляется кусок порядка 80кБ, есть ли гарантия что он не вырастет необоснованно? Т.е один раз приклеился и всё больше ничего не надо!

Если Вы имеете в виду библиотечный код - то гарантия полная. Библиотечный модуль может быть загружен линкером только один раз.

[neiver 0]

так то так но вот предположим у нас есть список объектов базоаого класса в виде указателей на них, при помощи dynamic_cast<*Iface> можно определить поддерживает ли данный инстанс интерфейс Iface и заодно преобразовать к классу интерфейса, если не поддерживает dynamic_cast вернёт NULL!

 

Конечно можно поступить и менее красиво, держать в классе флаги поддержки интерфейса и по их значениям кастовать!

 

Или ещё вариант но тоже менее красивый завести виртуальные функции которые кастуют к конкретному интерфейсу!

"флаги поддержки интерфейса" в классе - это призанак "моей первой программы на С++", часто появляются, когда люди много писали на простом Си.

Опрос возможностей с помощью dynamic_cast - это уже "вторая программа на С++" - осознание недостаатков первой.

Вариант с виртуальными функциями чуть лучше, но всё равно опрос возможностей или попытка узнать конкретный тип объекта почти всегда являются признаками неудачного проектирования. Этот самый тип объекта просто не нужно терять, чтоб потом не нужно было его динамически узнавать. Единственное адекватное применение опроса типа или возможностей объекта, dynamic_cast в частности и RTTI вообще - это ИМХО разработка своей библиотеки сериализации.

Рекомендую по этому по этому вопросу почитать книжку: Стефан К. Дьюхэрст "Скользкие места С++". Там очень хорошо этот вопрос расписан.

[glonium 0]

Спасибо за книгу интересные моменты обсуждаются!

Интересная картина получается!!!

Чтобы избежать проблем со множественным наследованием используем интерфейсы костыльным методом,

реализация интерфейсов предпологает нисходящее преобразование типов (как быть иначе я пока не вижу, вернее как узнать поддерживает ли данный инстанс интерфейс или нет), что в свою очередь нежелательно!

Все методы корректного нисходящего преобразования это ошибка проектирования, а множественное наследование штука тоже не из хороших,

а как тогда быть? Ведь невозможно провести классификацию сложных объектов без множественного наследования или хотя бы интерфейсов!

[neiver 0]

Вот! Именно для этого есть принципы SOLID. Очень рекомендую.

[glonium 0]

Это конечно всё понятно принципы SOLID!

Вот только я не могу связать теорию с практикой, а именно пусть у нас есть список инстансов приведённых к базовому классу, есть базовый интерфейс в виде виртуальных функций, но каждый объект наследник базового класса обладает ведь по определению расширенным функционалом специфичным только ему, и как им воспользоваться следуя вышеприведённым принципам не понятно! Реализация механизма обработки событий тоже требует оператора switch только внутри каждого из наследников при обработке события! Прошу Вас подсказать как действовать в этой ситуации не нарушая принципов ООП?

Изменено 21 июня, 2012 пользователем glonium