This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Usefulness of CYGFUN_INFRA_EMPTY_DELETE_FUNCTIONS
- From: "Christopher Cordahi" <christopher dot cordahi at gmail dot com>
- To: ecos-discuss at ecos dot sourceware dot org
- Date: Tue, 6 Feb 2007 13:29:12 -0500
- Subject: [ECOS] Usefulness of CYGFUN_INFRA_EMPTY_DELETE_FUNCTIONS
Hi group,
I'm wondering about the actual usefulness of the
CYGFUN_INFRA_EMPTY_DELETE_FUNCTIONS cdl option.
If you use new which calls malloc, then you
also have free linked in even if you never call it.
$ arm-elf-size.exe heap_with_delete.elf
text data bss dec hex filename
58320 1968 27732 88020 157d4 heap_with_delete.elf
$ arm-elf-size.exe heap_no_delete.elf
text data bss dec hex filename
58304 1968 27732 88004 157c4 heap_no_delete.elf
$ arm-elf-size.exe no_heap_with_delete.elf
text data bss dec hex filename
48640 1528 25556 75724 127cc no_heap_with_delete.elf
$ arm-elf-size.exe no_heap_no_delete.elf
text data bss dec hex filename
48640 1528 25556 75724 127cc no_heap_no_delete.elf
This option with its default setting saves a few bytes of memory
at the expense of the C++ delete operator not working.
If this option is to be preserved, I would think that empty
delete functions should be a user optimization not
an unexpected default.
Also the description of the option is much too complicated
and I don't even think it's correct, since virtual destructors
don't seem to have any influence on the code linked in.
# Provide empty C++ delete functions
# To deal with virtual destructors, where the correct delete()
# function must be called for the derived class in question, the
# underlying delete is called when needed, from destructors. This
# is regardless of whether the destructor is called by delete itself.
# So there is a reference to delete() from all destructors. The
# default builtin delete() attempts to call free() if there is
# one defined. So, if you have destructors, and you have free(),
# as in malloc() and free(), any destructor counts as a reference
# to free(). So the dynamic memory allocation code is linked
# in regardless of whether it gets explicitly called. This
# increases code and data size needlessly.
# To defeat this undesirable behaviour, we define empty versions
# of delete and delete. But doing this prevents proper use
# of dynamic memory in C++ programs via C++'s new and delete
# operators.
# Therefore, this option is provided
# for explicitly disabling the provision of these empty functions,
# so that new and delete can be used, if that is what is required.
#
cdl_option CYGFUN_INFRA_EMPTY_DELETE_FUNCTIONS {
# Flavor: bool
# No user value, uncomment the following line to provide one.
# user_value 1
# value_source default
# Default value: 1
};
--
Chris
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss