Снова к вопросу о разбухании кода arm-gcc Опции

[glonium]

Добрый день господа форумчане!
Настроил среду разработки Eclipse как сказано тут http://makesystem.net/?p=988
Использую toolchain Codebench Lite!
Написал простенький список (приложен ниже) и скомпилировал проект когда посмотрел на размер кода был немного обескуражен!
Размер кода стал равен 87384 Байт!
В оптимизаторе поставил генерировать отдельные секции и в линкере удалять неиспользуемые секции, но не помогает!
В чём тут может быть дело?

PS Может поменять компилятор, вернее версию??? Что то где-то слышал что помогает!
Вот только на какую менять???

Сообщение отредактировал glonium - May 30 2012, 06:17

Прикрепленные файлы

 list.rar ( 1.64 килобайт ) Кол-во скачиваний: 21

 

[glonium]

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

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

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

[neiver]

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

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

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

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