Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #4565

Re: Malloc Query

Show all headers | View raw

On Mon, May 23, 2011 at 02:44:18PM +0100, Ben Bacarisse wrote:
> Uncle Steve <stevet810@gmail.com> writes:
> 
> > On Mon, May 23, 2011 at 01:04:37AM +0100, Ben Bacarisse wrote:
> >> Uncle Steve <stevet810@gmail.com> writes:
> >> 
> >> > 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.
> >> 
> >> I should also have said especially if the macro does not have an
> >> ALL_CAPS name flagging it's macrosity.
> >
> > But as some feel here, macrosity is a vanishing distinction.
> 
> There you go again.  I won't say why not another time.  Ian's also said
> why the distinction is changing bit certainly not vanishing.  Presumably
> you don't accept the arguments, presumably because you never make a
> mistake with your macros.  Sorry, I just spotted "some".  Who?  You seem
> to suggest you don't hold this view anymore.

Look.  There are coding idioms that I use habitually; macros figure
prominently in specific roles.  That's my coding standard, FWIW, and
as I've no supervisor dictating some other arbitrary standard, I am
perfectly happy with my style more or less as-is.  My brain is not
composed of granite, so I am free to change my coding standards at
any time if I see a need to do so.
 
> >  I use
> > all-caps macro names for constant expressions and the like.  If I
> > think a macro will be more readable in lower-case, I'll do just that.
> > Shouted macro definitions interrupt the flow of source text when a
> > human is reading it, and I don't think I need that kind of distraction
> > in the code as much as some do.
> 
> Ah.  You code is for your eye only.  Not only should it not be commented
> on because you've edited for brevity, it should not be commented on for
> readability or clarity because only you'll read it.  I get it.  Nothing
> in you posted code should be commented on.

See below.
 
> >> > 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,
> >> 
> >> They should, but the onus is on the programmer to make that reasonable
> >> (and where there are side effects in the expressions used in the macro
> >> "call" this may not be possible). 
> >> 
> >> > but
> >> > today inline functions are just as fast as macros.
> >> 
> >> Yes, using an inline function is better yet.  You seemed dead against
> >> them which is why I commented on the macro.  Use a function and the
> >> issue disappears.
> >
> > I'm not "dead against" function calls for simple things.  I'm merely
> > predisposed against them.
> 
> It no longer matters.  Your code is for your eyes only and it does not
> have any of the errors that plague other people when they use macros.
> Any evidence to the contrary here is due to your thought posting code
> edited versions for brevity.

...
 
> >> >  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.
> >> 
> >> I don't see how you can say that.  The speed advantage that used to be
> >> one of the main reasons to take the risk with macros has gone, but all
> >> the potential bugs that function-like macros can hide are still there.
> >
> > Sorry, I should say 'moot' in consideration of the now historic
> > performance advantage of macros over function calls.  In reality,
> > function calls /are/ slower than macro instances but the compiler
> > masks this when it inlines a function by omitting function preamble
> > and jinking the basic blocks of code to flow together as if they were
> > part of the immediate text.  
> 
> I am very happy to have the slowness of something "masked" by the
> compiler making if fast.  In fact, I'd go so far as to say that it's not
> slow anymore but you that's just my way of looking at it.

Right.

> >> >> <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.
> >> 
> >> OK.  I'll try to remember to assume any errors in future code were added
> >> for brevity and I'll save time by not commenting on it.
> >
> > Please do.  I find it's the cut-and-paste-modify step that introduces
> > errors into program code more so than writing it in the first place.
> >  
> >> > 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?
> >> 
> >> The correct version of the macro is simpler than the one you seem to
> >> think you'd write to make it safe.  Why would you write the above (it's
> >> wrong, so it's obviously not what you really use) instead of
> >> 
> >>  *(x)->arena[n]
> >
> > That's only correct if the macro is a simple one-liner.  If (x) is
> > used more than once and has side-effects, such as in (x++), you're
> > toast.
> 
> You posted an incorrect one-liner.  You then said it's OK because you
> really use 4 lines and an non-C construct to do these things.  The seems
> daft to me.  If the code is short (and this code was short) just write
> the short version correctly.  Errors happen, so more lines are often
> worse than fewer.  I know, errors don't happen in your real code so you
> can be as verbose as you like, but for other people reading this shorter
> macros are almost always better.

I didn't say it was ok that I made an error; I merely explained the
cause.  Then you jumped on me for using a gccism.  I've already spent
about four hours in the last twenty-four writing messages to this
newsgroup.  How slowly should I write to Usenet?
 
> >> ?  Also, why would you use a non-standard feature when it's not needed?  There
> >> might be a reason to use ({...}) when a macro parameter is used more
> >> than once that's not the case here.  I suppose if you know you'll never
> >> use another compiler, tying code to language extensions is not a problem.
> >
> > I'm a creature of habit, I guess.  Note that while I didn't learn C
> > under gcc, it's about the only compiler I've used in the last
> > seventeen years.  Consequently, avoiding its extensions is not an
> > automatic process.  I'm making an effort to avoid non-portable code,
> > but it is slow going.
> 
> gcc -std=c99 -pedantic if you want to avoid extensions.  gcc -ansi
> -pedantic is you want to avoid more non-portable features.  I am sure
> you know this, and using it in your real builds, but I comment in case
> anyone else could use a reminder of how to make gcc limit itself to
> standard C.

Actually, I'm not using that for my 'real' builds since I'm hardly
building anything at all right now.  Instead I am writing and
designing.  Trust me, I have enough details up in the air right now.
I don't even care if my code is compilable right at this moment as
designing it properly is a higher priority.  If I had learned standard
C previously instead of gcc C, I wouldn't have this problem.  So at
some point when the code base is stable, /then/ (and only then) will
I go through it to remove gccisms in the older stuff. 

> >> >  Possibly not if people can be
> >> > reminded that all code posted in comp.lang.c is generally intended as
> >> > an example.
> >> 
> >> One of the bug-bears of Usenet is "oh that's not the real code".  This
> >> translates to "you've just wasted your time".  I'd vote for real code
> >> (at the last code that's gone though a compiler) every time.
> >
> > I look at the majority of the example code posted in Usenet messages
> > as being contrived for the purposes of demonstration.
> 
> Maybe, but it's real code in the sense that people want comments on it.

True enough, but that also implies that people are doing just as I am,
and shortening their code to make their queries and examples more
concise.
 
> >  When I was a
> > total noob, comp.sources.unix and a few others were places where real
> > code was made available to Usenet readers.  So called real code is no
> > longer posted to newsgroups.  I'm not ecstatic that my contrived
> > examples are not perfect, but the alternative is to post my 'real
> > code' and annoy people who would prefer the exemplar pared down to the
> > bare minimum.
> 
> Maybe just prefix the posting with "This is not real code.  If there
> are mistakes they are probably not there in the original so don't spend
> time on the details.  Stick to the gist of it."
> 
> > The arena allocator I've been on about is instantiated as a .h file
> > and is over 500 lines of code at this time.
> 
> Hmmm.... I wonder if that affects the performance.  Maybe not.

Quite a bit of it is documentation.
 
> >  It carries with it all
> > the 'baggage' of my development environment and would make the
> > discussion of its data structures and algorithm very awkward.  A
> > reasonable compromise would be to ensure that posted code compiles
> > and works as expected, but even than that won't correct for all
> > possible errors:  note that I buggered up the for() loop in the
> > arena_creat() function without triggering the error during testing.
> >
> > I'll endeavor to post better code in subsequent messages, but it is
> > not always practical to test quick one-off constructs completely when
> > so many things compete for my (and your) time.  I suppose I might
> > sound more intelligent and authoritative if my messages never
> > contained errors, but then I might never post at all if that were a
> > basic prerequisite for Usenet participation.  Somewhere there is a
> > happy medium that will satisfy everyone here.  I'll look more closely
> > for it. :)
> 
> Don't worry to much about it.  No one else seems to mind, and I've got a
> solution that works for me.

Ok, I won't.



Regards,

Uncle Steve

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

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Malloc Query Pushpa <pushpa@nospam.invalid> - 2011-05-17 19:39 +0000
  Re: Malloc Query blp@cs.stanford.edu (Ben Pfaff) - 2011-05-17 12:55 -0700
    Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-18 12:05 +0100
      Re: Malloc Query Pushpa <pushpa@nospam.invalid> - 2011-05-18 17:11 +0000
        Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-18 22:42 +0100
        Re: Malloc Query Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-18 21:10 -0400
      Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-18 19:34 +0100
        Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-18 17:10 -0400
          Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 00:26 +0100
            Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-18 21:25 -0400
              Re: Malloc Query James Kuyper <jameskuyper@verizon.net> - 2011-05-18 21:38 -0400
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-19 14:11 -0400
                Re: Malloc Query James Kuyper <jameskuyper@verizon.net> - 2011-05-19 22:55 -0400
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-20 12:14 -0400
              Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 03:22 +0100
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-19 14:20 -0400
                Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 23:51 +0100
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-19 20:01 -0400
                Re: Malloc Query luser- -droog <mijoryx@yahoo.com> - 2011-05-22 02:49 -0700
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-22 10:46 -0400
                Re: Malloc Query Shao Miller <sha0.miller@gmail.com> - 2011-05-22 12:37 -0500
                Re: Malloc Query Shao Miller <sha0.miller@gmail.com> - 2011-05-22 13:02 -0500
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-22 14:12 -0400
                Re: Malloc Query Shao Miller <sha0.miller@gmail.com> - 2011-05-23 03:06 -0500
                Re: Malloc Query luser- -droog <mijoryx@yahoo.com> - 2011-05-23 00:42 -0700
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 11:10 -0400
                Re: Malloc Query Keith Thompson <kst-u@mib.org> - 2011-05-23 09:06 -0700
                Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-22 23:18 +0100
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-22 19:18 -0400
                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-23 11:22 +1200
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 01:57 -0400
                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-23 19:24 +1200
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 14:20 -0400
                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-24 07:41 +1200
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 16:24 -0400
                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-24 09:20 +1200
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 18:05 -0400
                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-24 10:37 +1200
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 19:34 -0400
                Re: Malloc Query "robertwessel2@yahoo.com" <robertwessel2@yahoo.com> - 2011-05-23 17:48 -0700
                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-24 12:56 +1200
                Re: Malloc Query James Kuyper <jameskuyper@verizon.net> - 2011-05-24 07:19 -0400
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-24 11:32 -0400
                Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-23 01:04 +0100
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 02:36 -0400
                Re: Malloc Query luser- -droog <mijoryx@yahoo.com> - 2011-05-23 00:39 -0700
                Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-23 14:44 +0100
                Re: Malloc Query Seebs <usenet-nospam@seebs.net> - 2011-05-23 15:16 +0000
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-23 11:41 -0400
                Re: Malloc Query David Thompson <dave.thompson2@verizon.net> - 2011-06-01 16:33 -0400
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-19 18:34 -0400
                Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-20 02:36 +0100
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-20 12:26 -0400
                Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-20 23:32 +0100
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-20 21:17 -0400
                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-21 14:30 +1200
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-21 11:13 -0400
                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-22 08:50 +1200
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-21 20:03 -0400
                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-22 13:23 +1200
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-22 10:01 -0400
                Re: Malloc Query "io_x" <a@b.c.invalid> - 2011-05-26 08:12 +0200
                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-26 19:16 +1200
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-26 15:03 -0400
                Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-27 09:16 +1200
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-26 17:55 -0400
                Re: Malloc Query "io_x" <a@b.c.invalid> - 2011-05-27 05:47 +0200
                Re: Malloc Query Uncle Steve <stevet810@gmail.com> - 2011-05-26 15:02 -0400
        Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-18 22:31 +0100
          Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-18 23:37 +0100
            Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-19 01:50 +0100
              Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 02:50 +0100
                Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-19 12:14 +0100
                Re: Malloc Query Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-19 15:10 +0100
                Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-19 15:48 +0100
      Re: Malloc Query cri@tiac.net (Richard Harter) - 2011-05-18 19:31 +0000
      Re: Malloc Query Ike Naar <ike@iceland.freeshell.org> - 2011-05-18 21:43 +0000
        Re: Malloc Query "BartC" <bc@freeuk.com> - 2011-05-18 22:58 +0100
  Re: Malloc Query Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-17 14:01 -0600
  Re: Malloc Query Columbus sailed the ocean China Blue <chine.bleu@yahoo.com> - 2011-05-17 13:21 -0700
  Re: Malloc Query BGB <cr88192@hotmail.com> - 2011-05-17 14:08 -0700
    Re: Malloc Query Michael Press <rubrum@pacbell.net> - 2011-05-17 19:49 -0700
  Re: Malloc Query Lauri Alanko <la@iki.fi> - 2011-05-18 00:50 +0000
  Re: Malloc Query Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-17 21:21 -0400
    Re: Malloc Query "io_x" <a@b.c.invalid> - 2011-05-18 19:31 +0200
    Re: Malloc Query Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-05-18 21:36 +0000
      Re: Malloc Query Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-05-18 21:26 -0400
    Re: Malloc Query Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-19 02:07 -0700
      Re: Malloc Query Ian Collins <ian-news@hotmail.com> - 2011-05-19 21:13 +1200
  Re: Malloc Query Nobody <nobody@nowhere.com> - 2011-05-18 07:08 +0100
  Re: Malloc Query David Resnick <lndresnick@gmail.com> - 2011-05-19 07:51 -0700
    Re: Malloc Query Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-19 09:12 -0600

csiph-web