public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Christopher Cordahi <christopher.cordahi@gmail.com>
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Usefulness of CYGFUN_INFRA_EMPTY_DELETE_FUNCTIONS
Date: Tue, 06 Feb 2007 19:36:00 -0000	[thread overview]
Message-ID: <20070206193608.GK5224@lunn.ch> (raw)
In-Reply-To: <a1a7967e0702061029h35bedbbaw219944f754059c3f@mail.gmail.com>

On Tue, Feb 06, 2007 at 01:29:12PM -0500, Christopher Cordahi wrote:
> 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.

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.

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

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

              Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

  reply	other threads:[~2007-02-06 19:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-06 18:29 Christopher Cordahi
2007-02-06 19:36 ` Andrew Lunn [this message]
2007-02-06 21:24   ` Christopher Cordahi
2007-02-06 21:38     ` Andrew Lunn
2007-02-07 16:33       ` Christopher Cordahi
2007-02-06 21:42     ` Gary Thomas
2007-02-07 11:20     ` [ECOS] " Sergei Organov
     [not found]       ` <a1a7967e0702070906q156698d1i748a35f0d2053469@mail.gmail.com>
2007-02-07 17:39         ` osv
2007-02-07 21:55           ` Christopher Cordahi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070206193608.GK5224@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=christopher.cordahi@gmail.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).