Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Снова к вопросу о разбухании кода arm-gcc
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > GNU/OpenSource средства разработки
glonium
Добрый день господа форумчане!
Настроил среду разработки Eclipse как сказано тут http://makesystem.net/?p=988
Использую toolchain Codebench Lite!
Написал простенький список (приложен ниже) и скомпилировал проект когда посмотрел на размер кода был немного обескуражен!
Размер кода стал равен 87384 Байт!
В оптимизаторе поставил генерировать отдельные секции и в линкере удалять неиспользуемые секции, но не помогает!
В чём тут может быть дело?

PS Может поменять компилятор, вернее версию??? Что то где-то слышал что помогает!
Вот только на какую менять???
Непомнящий Евгений
Ну смотри - ты приложил хидер с шаблоном. Шаблон после компиляции любым компилятором занимает ровно 0 байт sm.gif Место занимают конкретные инстанцирования этого шаблона.

Так что чтобы что-то тебе сказать, надо посмотреть на все остальное - приложи компилябельный проект целиком.

#include "exception.h" намекает на использование исключений. Исключения требуют довольно жирного рантайма - может быть дело в этом.

У меня минимальный elf занимает порядка 100 байт или около того - int main() { while (1); } с отключенным стартовым кодом.

Если добавить стартовый код, размер станет несколько больше. Если добавить поддержку исключений - станет килобайт 60 или около того.
glonium
Прошу прошения что то не подумал выложить проект! Исключения самописанные!
Вот проект целиком
Непомнящий Евгений
дык а map ты не пытался сгенерить? Сгенери, посмотри кто у тебя самый толстый...
glonium
Да сгенерил только ничего не понял из него в нём куча всего!

Да вы правы к сожалению всё дело в исключениях!
они в моём случае добавляют около 70 кб!
А есть ли способ обойти это или только отказом от исключений?

Да и поэкспериментировав я наткнулся на то что оператор new тоже много чего тянет за собой!
Сергей Борщ
Насчет исключений не подскажу, полагаю, что поддержка их зарыта глубоко в компиляторе и просто так переписать библиотеку не получится.
QUOTE (glonium @ May 30 2012, 12:12) *
Да и поэкспериментировав я наткнулся на то что оператор new тоже много чего тянет за собой!
Да, тянет. Используйте свой менеджер памяти, например вот этот.
glonium
Спасибо за ответ! Интересное предложение. А со своим диспетчером памяти у меня механизм виртуальных функций будет работать, а так же dunamic_cast<>???
Сергей Борщ
QUOTE (glonium @ May 30 2012, 16:06) *
А со своим диспетчером памяти у меня механизм виртуальных функций будет работать, а так же dynamic_cast<>???
Виртуальные функции работают (проверено, использую), за них конструктор отвечает. А он вызывается после выделения памяти оператором new(). А про dynamic_cast я только краем уха слышал, может кто-то другой подскажет. Хотя навряд ли она завязана на менеджер памяти - он лишь выделяет кусок памяти запрошенного размера. Если dynamic_cast работает с placement new(), то и с этим работать должен.
glonium
Поэкспериментировав с перегрузкой операторов new и delete пришёл к интересным заключениям!
Вариант 1 :
Код
#include "stmlib/stm32f10x.h"
#include <stdlib.h>

void *operator new (size_t size)
{
    return malloc(size);
}
void operator delete (void *p)
{
    free(p);
    return;
}

int main (void)
{
    int *a=new int(10);
    while (1){};
    return 0;
}

Компилиться в 4 Кб с использованием стандартных free и malloc!
2 Случай
Код
/*
void *operator new (size_t size)
{
    return malloc(size);
}
void operator delete (void *p)
{
    free(p);
    return;
}
*/
int main (void)
{
    int *a=new int(10);
    while (1){};
    return 0;
}

Компилиться в 80Кб!
Почему такая разница? Вроде стандартный new и delete опирается на стандартные malloc и free!
Сергей Борщ
А если так:
CODE
#include <new>
.....
*/
int main (void)
{
    int *a=new(std::nothrow)  int(10);
    while (1){};
    return 0;
}

glonium
Цитата
А если так:
CODE
#include <new>
.....
*/
int main (void)
{
int *a=new(std::nothrow) int(10);
while (1){};
return 0;
}

Так тоже порядка 80Кб!

Да и вообще у меня подозрение что в c++ другой аллокатор памяти потяжелее чем в с!
_Артём_
Цитата(glonium @ Jun 1 2012, 18:00) *
Так тоже порядка 80Кб!

Да и вообще у меня подозрение что в c++ другой аллокатор памяти потяжелее чем в с!


glonium, вы не могли бы проект целиком выложить. Интересно бы посмотреть, а то у меня вообще не собирается.

P.S. И какой компилятор?.
glonium
Цитата
P.S. И какой компилятор?.

Использую CodeBench руководствовался это статьёй при установке IDE http://makesystem.net/?p=988

Цитата
glonium, вы не могли бы проект целиком выложить. Интересно бы посмотреть, а то у меня вообще не собирается.

AHTOXA
Чтобы не подтягивались исключения, надо компилировать с ключом -fno-exceptions.
При использовании чисто виритуальных функций иногда подключаются исключения и с этим ключиком. В этом случае спасает вот этот файл. Просто добавьте его к своему проекту.
glonium
Цитата
Чтобы не подтягивались исключения, надо компилировать с ключом -fno-exceptions.

Поставил ключик -fno-exceptions все равно размер кода не уменьшается, при этом виртуальные функции не использую!

PS видать это вовсе не исключения так весят а аллокатор памяти!
AHTOXA
Цитата(glonium @ Jun 1 2012, 22:37) *
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
Цитата
Посмотрите map-файл, и увидите, что это всё-таки исключения.

Я если честно не до конца разобрался как пользоваться map и как от туда узнать что сколько весит (непонятные имена функций)
Подскажите пожалуйста где можно прочитать про map!
Заранее спасибо!
AHTOXA
А чего там уметь-то? Смотрите, видите "eh_exception.o" - значит, исключения присутствуютsm.gif
Ну а так, там в самом начале есть строчка:
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
Да очень жаль конечно что всё это весит много!
В проекте планировалось использовать dunamic_cast<> (RTTI) для реализации подобия интерфейсов.
Народ а может кто подсказать если я использую RTTI и throw то к программе добавляется кусок порядка 80кБ, есть ли гарантия что он не вырастет необоснованно? Т.е один раз приклеился и всё больше ничего не надо!
_Артём_
Цитата(glonium @ Jun 8 2012, 15:12) *
В проекте планировалось использовать dunamic_cast<> (RTTI) для реализации подобия интерфейсов.

А что такого вам даёт RTTI?
Интерфейсы в С++ ведь реализуются с помощью абстрактных классов с наследованием. Этого недостаточно?
glonium
так то так но вот предположим у нас есть список объектов базоаого класса в виде указателей на них, при помощи dynamic_cast<*Iface> можно определить поддерживает ли данный инстанс интерфейс Iface и заодно преобразовать к классу интерфейса, если не поддерживает dynamic_cast вернёт NULL!

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

Или ещё вариант но тоже менее красивый завести виртуальные функции которые кастуют к конкретному интерфейсу!
alx2
Цитата(glonium @ Jun 8 2012, 17:12) *
Народ а может кто подсказать если я использую RTTI и throw то к программе добавляется кусок порядка 80кБ, есть ли гарантия что он не вырастет необоснованно? Т.е один раз приклеился и всё больше ничего не надо!

Если Вы имеете в виду библиотечный код - то гарантия полная. Библиотечный модуль может быть загружен линкером только один раз.
neiver
Цитата(glonium @ Jun 10 2012, 13:56) *
так то так но вот предположим у нас есть список объектов базоаого класса в виде указателей на них, при помощи dynamic_cast<*Iface> можно определить поддерживает ли данный инстанс интерфейс Iface и заодно преобразовать к классу интерфейса, если не поддерживает dynamic_cast вернёт NULL!

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

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

"флаги поддержки интерфейса" в классе - это призанак "моей первой программы на С++", часто появляются, когда люди много писали на простом Си.
Опрос возможностей с помощью dynamic_cast - это уже "вторая программа на С++" - осознание недостаатков первой.
Вариант с виртуальными функциями чуть лучше, но всё равно опрос возможностей или попытка узнать конкретный тип объекта почти всегда являются признаками неудачного проектирования. Этот самый тип объекта просто не нужно терять, чтоб потом не нужно было его динамически узнавать. Единственное адекватное применение опроса типа или возможностей объекта, dynamic_cast в частности и RTTI вообще - это ИМХО разработка своей библиотеки сериализации.
Рекомендую по этому по этому вопросу почитать книжку: Стефан К. Дьюхэрст "Скользкие места С++". Там очень хорошо этот вопрос расписан.
glonium
Спасибо за книгу интересные моменты обсуждаются!
Интересная картина получается!!!
Чтобы избежать проблем со множественным наследованием используем интерфейсы костыльным методом,
реализация интерфейсов предпологает нисходящее преобразование типов (как быть иначе я пока не вижу, вернее как узнать поддерживает ли данный инстанс интерфейс или нет), что в свою очередь нежелательно!
Все методы корректного нисходящего преобразования это ошибка проектирования, а множественное наследование штука тоже не из хороших,
а как тогда быть? Ведь невозможно провести классификацию сложных объектов без множественного наследования или хотя бы интерфейсов!
neiver
Вот! Именно для этого есть принципы SOLID. Очень рекомендую.
glonium
Это конечно всё понятно принципы SOLID!
Вот только я не могу связать теорию с практикой, а именно пусть у нас есть список инстансов приведённых к базовому классу, есть базовый интерфейс в виде виртуальных функций, но каждый объект наследник базового класса обладает ведь по определению расширенным функционалом специфичным только ему, и как им воспользоваться следуя вышеприведённым принципам не понятно! Реализация механизма обработки событий тоже требует оператора switch только внутри каждого из наследников при обработке события! Прошу Вас подсказать как действовать в этой ситуации не нарушая принципов ООП?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.