Добрый день господа форумчане!
Настроил среду разработки Eclipse как сказано тут http://makesystem.net/?p=988
Использую toolchain Codebench Lite!
Написал простенький список (приложен ниже) и скомпилировал проект когда посмотрел на размер кода был немного обескуражен!
Размер кода стал равен 87384 Байт!
В оптимизаторе поставил генерировать отдельные секции и в линкере удалять неиспользуемые секции, но не помогает!
В чём тут может быть дело?
PS Может поменять компилятор, вернее версию??? Что то где-то слышал что помогает!
Вот только на какую менять???
Полная версия этой страницы: Снова к вопросу о разбухании кода arm-gcc
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > GNU/OpenSource средства разработки
Ну смотри - ты приложил хидер с шаблоном. Шаблон после компиляции любым компилятором занимает ровно 0 байт 
Место занимают конкретные инстанцирования этого шаблона.
Так что чтобы что-то тебе сказать, надо посмотреть на все остальное - приложи компилябельный проект целиком.
#include "exception.h" намекает на использование исключений. Исключения требуют довольно жирного рантайма - может быть дело в этом.
У меня минимальный elf занимает порядка 100 байт или около того - int main() { while (1); } с отключенным стартовым кодом.
Если добавить стартовый код, размер станет несколько больше. Если добавить поддержку исключений - станет килобайт 60 или около того.
Место занимают конкретные инстанцирования этого шаблона.Так что чтобы что-то тебе сказать, надо посмотреть на все остальное - приложи компилябельный проект целиком.
#include "exception.h" намекает на использование исключений. Исключения требуют довольно жирного рантайма - может быть дело в этом.
У меня минимальный elf занимает порядка 100 байт или около того - int main() { while (1); } с отключенным стартовым кодом.
Если добавить стартовый код, размер станет несколько больше. Если добавить поддержку исключений - станет килобайт 60 или около того.
Прошу прошения что то не подумал выложить проект! Исключения самописанные!
Вот проект целиком
Вот проект целиком
дык а map ты не пытался сгенерить? Сгенери, посмотри кто у тебя самый толстый...
Да сгенерил только ничего не понял из него в нём куча всего!
Да вы правы к сожалению всё дело в исключениях!
они в моём случае добавляют около 70 кб!
А есть ли способ обойти это или только отказом от исключений?
Да и поэкспериментировав я наткнулся на то что оператор new тоже много чего тянет за собой!
Да вы правы к сожалению всё дело в исключениях!
они в моём случае добавляют около 70 кб!
А есть ли способ обойти это или только отказом от исключений?
Да и поэкспериментировав я наткнулся на то что оператор new тоже много чего тянет за собой!
Насчет исключений не подскажу, полагаю, что поддержка их зарыта глубоко в компиляторе и просто так переписать библиотеку не получится.
QUOTE (glonium @ May 30 2012, 12:12) 
Да и поэкспериментировав я наткнулся на то что оператор new тоже много чего тянет за собой!
Да, тянет. Используйте свой менеджер памяти, например вот этот.
Спасибо за ответ! Интересное предложение. А со своим диспетчером памяти у меня механизм виртуальных функций будет работать, а так же dunamic_cast<>???
QUOTE (glonium @ May 30 2012, 16:06)
А со своим диспетчером памяти у меня механизм виртуальных функций будет работать, а так же dynamic_cast<>???
Виртуальные функции работают (проверено, использую), за них конструктор отвечает. А он вызывается после выделения памяти оператором new(). А про dynamic_cast я только краем уха слышал, может кто-то другой подскажет. Хотя навряд ли она завязана на менеджер памяти - он лишь выделяет кусок памяти запрошенного размера. Если dynamic_cast работает с placement new(), то и с этим работать должен.
Поэкспериментировав с перегрузкой операторов new и delete пришёл к интересным заключениям!
Вариант 1 :
Компилиться в 4 Кб с использованием стандартных free и malloc!
2 Случай
Компилиться в 80Кб!
Почему такая разница? Вроде стандартный new и delete опирается на стандартные malloc и free!
Вариант 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;
}
#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;
}
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;
}
.....
*/
int main (void)
{
int *a=new(std::nothrow) int(10);
while (1){};
return 0;
}
Цитата
А если так:
CODE
#include <new>
.....
*/
int main (void)
{
int *a=new(std::nothrow) int(10);
while (1){};
return 0;
}
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++ другой аллокатор памяти потяжелее чем в с!
Да и вообще у меня подозрение что в c++ другой аллокатор памяти потяжелее чем в с!
glonium, вы не могли бы проект целиком выложить. Интересно бы посмотреть, а то у меня вообще не собирается.
P.S. И какой компилятор?.
Цитата
P.S. И какой компилятор?.
Использую CodeBench руководствовался это статьёй при установке IDE http://makesystem.net/?p=988
Цитата
glonium, вы не могли бы проект целиком выложить. Интересно бы посмотреть, а то у меня вообще не собирается.
Чтобы не подтягивались исключения, надо компилировать с ключом -fno-exceptions.
При использовании чисто виритуальных функций иногда подключаются исключения и с этим ключиком. В этом случае спасает вот этот файл. Просто добавьте его к своему проекту.
При использовании чисто виритуальных функций иногда подключаются исключения и с этим ключиком. В этом случае спасает вот этот файл. Просто добавьте его к своему проекту.
Цитата
Чтобы не подтягивались исключения, надо компилировать с ключом -fno-exceptions.
Поставил ключик -fno-exceptions все равно размер кода не уменьшается, при этом виртуальные функции не использую!
PS видать это вовсе не исключения так весят а аллокатор памяти!
Цитата(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()
{
..
}
{
...
}
void operator delete(void * pobject, const std::nothrow_t&) throw()
{
..
}
И добавьте всё же к своему проекту файл из моего предыдущего сообщения.
Цитата
Посмотрите map-файл, и увидите, что это всё-таки исключения.
Я если честно не до конца разобрался как пользоваться map и как от туда узнать что сколько весит (непонятные имена функций)
Подскажите пожалуйста где можно прочитать про map!
Заранее спасибо!
А чего там уметь-то? Смотрите, видите "eh_exception.o" - значит, исключения присутствуют
Ну а так, там в самом начале есть строчка:
Archive member included because of file (symbol)
То есть, формат такой
подключенная_библиотека (имя_объекта_из_этой_библиотеки.o) имя_файла_из_за_которого_подключили_этот_библиотечный_объект (имя_функции_из_за_которой_подключили)
Попробуйте сделать, как я сказал в предыдущем сообщении, думаю, что поможет.
Кстати, не забудьте остальные варианты new/delete:
Ну а так, там в самом начале есть строчка:
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); }
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); }
Да очень жаль конечно что всё это весит много!
В проекте планировалось использовать dunamic_cast<> (RTTI) для реализации подобия интерфейсов.
Народ а может кто подсказать если я использую RTTI и throw то к программе добавляется кусок порядка 80кБ, есть ли гарантия что он не вырастет необоснованно? Т.е один раз приклеился и всё больше ничего не надо!
В проекте планировалось использовать dunamic_cast<> (RTTI) для реализации подобия интерфейсов.
Народ а может кто подсказать если я использую RTTI и throw то к программе добавляется кусок порядка 80кБ, есть ли гарантия что он не вырастет необоснованно? Т.е один раз приклеился и всё больше ничего не надо!
Цитата(glonium @ Jun 8 2012, 15:12)
В проекте планировалось использовать dunamic_cast<> (RTTI) для реализации подобия интерфейсов.
А что такого вам даёт RTTI?
Интерфейсы в С++ ведь реализуются с помощью абстрактных классов с наследованием. Этого недостаточно?
так то так но вот предположим у нас есть список объектов базоаого класса в виде указателей на них, при помощи dynamic_cast<*Iface> можно определить поддерживает ли данный инстанс интерфейс Iface и заодно преобразовать к классу интерфейса, если не поддерживает dynamic_cast вернёт NULL!
Конечно можно поступить и менее красиво, держать в классе флаги поддержки интерфейса и по их значениям кастовать!
Или ещё вариант но тоже менее красивый завести виртуальные функции которые кастуют к конкретному интерфейсу!
Конечно можно поступить и менее красиво, держать в классе флаги поддержки интерфейса и по их значениям кастовать!
Или ещё вариант но тоже менее красивый завести виртуальные функции которые кастуют к конкретному интерфейсу!
Цитата(glonium @ Jun 8 2012, 17:12)
Народ а может кто подсказать если я использую RTTI и throw то к программе добавляется кусок порядка 80кБ, есть ли гарантия что он не вырастет необоснованно? Т.е один раз приклеился и всё больше ничего не надо!
Если Вы имеете в виду библиотечный код - то гарантия полная. Библиотечный модуль может быть загружен линкером только один раз.
Цитата(glonium @ Jun 10 2012, 13:56)
так то так но вот предположим у нас есть список объектов базоаого класса в виде указателей на них, при помощи dynamic_cast<*Iface> можно определить поддерживает ли данный инстанс интерфейс Iface и заодно преобразовать к классу интерфейса, если не поддерживает dynamic_cast вернёт NULL!
Конечно можно поступить и менее красиво, держать в классе флаги поддержки интерфейса и по их значениям кастовать!
Или ещё вариант но тоже менее красивый завести виртуальные функции которые кастуют к конкретному интерфейсу!
Конечно можно поступить и менее красиво, держать в классе флаги поддержки интерфейса и по их значениям кастовать!
Или ещё вариант но тоже менее красивый завести виртуальные функции которые кастуют к конкретному интерфейсу!
"флаги поддержки интерфейса" в классе - это призанак "моей первой программы на С++", часто появляются, когда люди много писали на простом Си.
Опрос возможностей с помощью dynamic_cast - это уже "вторая программа на С++" - осознание недостаатков первой.
Вариант с виртуальными функциями чуть лучше, но всё равно опрос возможностей или попытка узнать конкретный тип объекта почти всегда являются признаками неудачного проектирования. Этот самый тип объекта просто не нужно терять, чтоб потом не нужно было его динамически узнавать. Единственное адекватное применение опроса типа или возможностей объекта, dynamic_cast в частности и RTTI вообще - это ИМХО разработка своей библиотеки сериализации.
Рекомендую по этому по этому вопросу почитать книжку: Стефан К. Дьюхэрст "Скользкие места С++". Там очень хорошо этот вопрос расписан.
Спасибо за книгу интересные моменты обсуждаются!
Интересная картина получается!!!
Чтобы избежать проблем со множественным наследованием используем интерфейсы костыльным методом,
реализация интерфейсов предпологает нисходящее преобразование типов (как быть иначе я пока не вижу, вернее как узнать поддерживает ли данный инстанс интерфейс или нет), что в свою очередь нежелательно!
Все методы корректного нисходящего преобразования это ошибка проектирования, а множественное наследование штука тоже не из хороших,
а как тогда быть? Ведь невозможно провести классификацию сложных объектов без множественного наследования или хотя бы интерфейсов!
Интересная картина получается!!!
Чтобы избежать проблем со множественным наследованием используем интерфейсы костыльным методом,
реализация интерфейсов предпологает нисходящее преобразование типов (как быть иначе я пока не вижу, вернее как узнать поддерживает ли данный инстанс интерфейс или нет), что в свою очередь нежелательно!
Все методы корректного нисходящего преобразования это ошибка проектирования, а множественное наследование штука тоже не из хороших,
а как тогда быть? Ведь невозможно провести классификацию сложных объектов без множественного наследования или хотя бы интерфейсов!
Вот! Именно для этого есть принципы SOLID. Очень рекомендую.
Это конечно всё понятно принципы SOLID!
Вот только я не могу связать теорию с практикой, а именно пусть у нас есть список инстансов приведённых к базовому классу, есть базовый интерфейс в виде виртуальных функций, но каждый объект наследник базового класса обладает ведь по определению расширенным функционалом специфичным только ему, и как им воспользоваться следуя вышеприведённым принципам не понятно! Реализация механизма обработки событий тоже требует оператора switch только внутри каждого из наследников при обработке события! Прошу Вас подсказать как действовать в этой ситуации не нарушая принципов ООП?
Вот только я не могу связать теорию с практикой, а именно пусть у нас есть список инстансов приведённых к базовому классу, есть базовый интерфейс в виде виртуальных функций, но каждый объект наследник базового класса обладает ведь по определению расширенным функционалом специфичным только ему, и как им воспользоваться следуя вышеприведённым принципам не понятно! Реализация механизма обработки событий тоже требует оператора switch только внутри каждого из наследников при обработке события! Прошу Вас подсказать как действовать в этой ситуации не нарушая принципов ООП?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.