This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Usefulness of CYGFUN_INFRA_EMPTY_DELETE_FUNCTIONS


On 06/02/07, Andrew Lunn <andrew@lunn.ch> wrote:
On Tue, Feb 06, 2007 at 01:29:12PM -0500, Christopher Cordahi wrote:
> 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.

That should be wrong. If you don't use something, the linker does not
include it. If you are seeing free included but not used find out why?
Get a linker cross reference and find out where it is being referenced
from. If you really find it is included but without a reference your
linker might be broken and producing bloated binaries.

I'm sorry if I'm incorrect, but from my understanding of the linker, it includes entire modules not functions. Since malloc and free are in the same module, if new is used, both are automatically linked in. Am I incorrect? Is there an option for the linker to link at the function/variable level? I would greatly appreciate it.

> This option with its default setting saves a few bytes of memory
> at the expense of the C++ delete operator not working.

Generally, if somebody is wanting to write small code, they use C and
avoid C++. So to me, this is the right way around. I'm typically using
a system with 64Kbytes of RAM and 256Kbytes of FLASH. Every byte
counts and i avoid C++ like the plague.

I agree 100%. If you don't want the overhead of C++, don't use it, but if you do use delete you would expect it to work properly.

To quote you "If you don't use something, the linker does not
include it".  If you don't call delete, delete won't be linked in and
hence free won't be linked in without any need for the option.

> If this option is to be preserved, I would think that empty
> delete functions should be a user optimization not
> an unexpected default.

You are taking the wrong tone here. "is to be preserved" makes it
sound like you have already decided to take it out and are letting
people argue it should be kept. In fact it is the other way
around. You need to convince us that the default value should be
changed and that the bloat added by changing the default really is
insignificant to all users.

Sorry if I sound presumptive, but I'm trying to get the reasoning for the option since it doesn't seem to work according to its confusing description and purpose.

I created and destroyed a C++ object with a virtual destructor that
was on the stack and the the free function wasn't included in the
object code since there wasn't any dynamic memory.

--
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]