Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: Uncle Steve <stevet810@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Malloc Query
Date: Sun, 22 May 2011 19:18:54 -0400
Organization: Friends of the Galactic Collective
Lines: 66
Message-ID: <21ceccb2e03a4dc-edfd3@gmail.com>
References: <ir096a$6vd$1@dont-email.me> <0.9e954b297cf63735a997.20110518193428BST.87zkmjuabv.fsf@bsb.me.uk> <a8b295514ba3fd1-1a35b@gmail.com> <0.3ac369f64d11bcd06d18.20110519002615BST.87ei3vtwtk.fsf@bsb.me.uk> <98a074c87051012-452fb@gmail.com> <0.bf5e9ff46dfbfc1e78d6.20110519032218BST.87tycrsa3p.fsf@bsb.me.uk> <2b5874771e1859c-5f9fd@gmail.com> <22a91a32-b2c6-4ce1-bb2b-23c2455bc195@z13g2000yqg.googlegroups.com> <708913a057f3f9c-34aa7@gmail.com> <0.47b2d301a43a01009630.20110522231836BST.87fwo6nzur.fsf@bsb.me.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
Injection-Info: mx04.eternal-september.org; posting-host="job9yP/rmK/fxQbJrcqEcA"; logging-data="18217"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX188D2h7jUAht4lSTjQEyvNZ"
User-Agent: nn 6.7.3
Content-Length: 2249
Cancel-Lock: sha1:J6PslhqHhGaiaDP4sbTFlDUuuwY=
Xref: x330-a1.tempe.blueboxinc.net comp.lang.c:4534

On Sun, May 22, 2011 at 1u1:18:36PM +0100, Ben Bacarisse wrote:
> Uncle Steve <stevet810@gmail.com> writes:
> 
> > On Sun, May 22, 2011 at 02:49:51AM -0700, luser- -droog wrote:
> >> 
> >> I've been using integer offsets instead of pointers a lot lately and
> >> I think you might be better off using the array formula explicitly:
> >> 
> >>  #define arena_obj_addr(x, n) ((void *) (x->arena + n * x->obj_size))
> 
> Everyone is taking chances here.  The x and n should be in parentheses
> so that the macro expands as expected.  This is one reason why functions
> are usually preferred.

For a long time I've thought macros were preferable to functions for
the reason that a function call has to save registers, stuff it's arguments on the
stack, and so on.  Macros should just fold into the program text, but
today inline functions are just as fast as macros.  It has become a
matter of preference.  gcc even has the ability to use register
calling conventions for function calls in some circumstances.  The
distinction between a macro and a function call is becoming moot.
 
> <snip>
> > #define ARENA_TYPE	struct foo

> > struct arena_s {
> >    size_t        arena_size;
> >    int           free_list;
> >    size_t        free;
> >    ARENA_TYPE *  arena;
> > };
> >
> > And your access macro becomes:
> >
> > #define arena_obj_addr(x, n)   &x->arena[n]
> 
> Here the [n] is OK, but why risk it with x?  The (x) costs nothing and,
> I think, saves time reading the macro since the reader does no have to
> start worrying about what might be passed.

No worries here.  I've edited for brevity in posting, but I always
protect macro arguments from side-effects these days.  It doesn't look
as clean and concise, which is why I omitted those statements from
example code.  No biggie.
 
In this newsgroup is it really preferable to see 

#define arena_object_addr(x, n) ({	\
   struct arena_s X = x;		\
   int N = n;				\
   *X->arena[N]; })			\

for every dumb example that is posted?  Possibly not if people can be
reminded that all code posted in comp.lang.c is generally intended as
an example.



Regards,

Uncle Steve

-- 
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?