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

Groups > comp.lang.c > #62800 > unrolled thread

Making C more beautiful by not using macros with arguments

Back to article view | Back to comp.lang.c

Contents

  Making C more beautiful by not using macros with arguments David Kleinecke <dkleinecke@gmail.com> - 2015-05-29 10:36 -0700
    Re: Making C more beautiful by not using macros with arguments Bartc <bc@freeuk.com> - 2015-05-29 19:04 +0100
      Re: Making C more beautiful by not using macros with arguments David Kleinecke <dkleinecke@gmail.com> - 2015-05-30 07:30 -0700
        Re: Making C more beautiful by not using macros with arguments Bartc <bc@freeuk.com> - 2015-05-30 15:51 +0100
    Re: Making C more beautiful by not using macros with arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-29 19:26 +0100
      Re: Making C more beautiful by not using macros with arguments David Kleinecke <dkleinecke@gmail.com> - 2015-05-30 07:38 -0700
        Re: Making C more beautiful by not using macros with arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-30 21:44 +0100
          Re: Making C more beautiful by not using macros with arguments Bartc <bc@freeuk.com> - 2015-05-30 23:58 +0100
            Re: Making C more beautiful by not using macros with arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-31 00:27 +0100
              Re: Making C more beautiful by not using macros with arguments Bartc <bc@freeuk.com> - 2015-05-31 10:21 +0100
                Re: Making C more beautiful by not using macros with arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-31 11:00 +0100
                  Re: Making C more beautiful by not using macros with arguments David Kleinecke <dkleinecke@gmail.com> - 2015-05-31 09:45 -0700
                    Re: Making C more beautiful by not using macros with arguments Bartc <bc@freeuk.com> - 2015-05-31 18:20 +0100
                      Re: Making C more beautiful by not using macros with arguments Keith Thompson <kst-u@mib.org> - 2015-05-31 13:04 -0700
                        Re: Making C more beautiful by not using macros with arguments Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-05-31 16:11 -0400
                        Re: Making C more beautiful by not using macros with arguments Bartc <bc@freeuk.com> - 2015-05-31 21:48 +0100
                          Re: Making C more beautiful by not using macros with arguments Keith Thompson <kst-u@mib.org> - 2015-05-31 14:22 -0700
                      Re: Making C more beautiful by not using macros with arguments David Kleinecke <dkleinecke@gmail.com> - 2015-06-01 11:33 -0700
                    Re: Making C more beautiful by not using macros with arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-31 20:37 +0100
                      Re: Making C more beautiful by not using macros with arguments Keith Thompson <kst-u@mib.org> - 2015-05-31 14:18 -0700
                        Re: Making C more beautiful by not using macros with arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-31 22:44 +0100
                      Re: Making C more beautiful by not using macros with arguments Bartc <bc@freeuk.com> - 2015-05-31 23:16 +0100
                      Re: Making C more beautiful by not using macros with arguments David Kleinecke <dkleinecke@gmail.com> - 2015-06-01 11:58 -0700
                        Re: Making C more beautiful by not using macros with arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-02 01:14 +0100
                          Re: Making C more beautiful by not using macros with arguments Bartc <bc@freeuk.com> - 2015-06-02 10:31 +0100
                            Re: Making C more beautiful by not using macros with arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-02 11:06 +0100
                              Re: Making C more beautiful by not using macros with arguments Bartc <bc@freeuk.com> - 2015-06-02 11:39 +0100
                                Re: Making C more beautiful by not using macros with arguments "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-02 04:02 -0700
                                Re: Making C more beautiful by not using macros with arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-02 12:24 +0100
                                  Re: Making C more beautiful by not using macros with arguments Noob <root@127.0.0.1> - 2015-06-02 15:41 +0200
                                    Re: Making C more beautiful by not using macros with arguments Richard Heathfield <rjh@cpax.org.uk> - 2015-06-02 15:00 +0100
                                      Re: Trolls/Cranks/Kooks Noob <root@127.0.0.1> - 2015-06-02 16:41 +0200
                                        Re: Trolls/Cranks/Kooks Richard Heathfield <rjh@cpax.org.uk> - 2015-06-02 15:56 +0100
                                          Re: Trolls/Cranks/Kooks Noob <root@127.0.0.1> - 2015-06-02 17:09 +0200
                                            Re: Trolls/Cranks/Kooks Richard Heathfield <rjh@cpax.org.uk> - 2015-06-02 16:17 +0100
                                    Re: Making C more beautiful by not using macros with arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-02 15:58 +0100
                            Re: Making C more beautiful by not using macros with arguments Dr Nick <nospam-4@temporary-address.org.uk> - 2015-06-02 19:32 +0100
                          Re: Making C more beautiful by not using macros with arguments David Kleinecke <dkleinecke@gmail.com> - 2015-06-02 11:00 -0700
                            Re: Making C more beautiful by not using macros with arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-02 20:13 +0100
        Re: Making C more beautiful by not using macros with arguments Keith Thompson <kst-u@mib.org> - 2015-05-30 15:17 -0700
          Re: Making C more beautiful by not using macros with arguments David Kleinecke <dkleinecke@gmail.com> - 2015-05-31 09:12 -0700
            Re: Making C more beautiful by not using macros with arguments Keith Thompson <kst-u@mib.org> - 2015-05-31 13:29 -0700
        Re: Making C more beautiful by not using macros with arguments David Brown <david.brown@hesbynett.no> - 2015-05-31 17:28 +0200
    Re: Making C more beautiful by not using macros with arguments Morris Dovey <mrdovey@iedu.com> - 2015-05-29 13:35 -0500
    Re: Making C more beautiful by not using macros with arguments "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-05-29 13:19 -0700
      Re: Making C more beautiful by not using macros with arguments "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-05-29 13:25 -0700
    Re: Making C more beautiful by not using macros with arguments Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-05-29 14:23 -0600
    Re: Making C more beautiful by not using macros with arguments Keith Thompson <kst-u@mib.org> - 2015-05-29 14:16 -0700
      Re: Making C more beautiful by not using macros with arguments David Kleinecke <dkleinecke@gmail.com> - 2015-05-30 07:46 -0700
        Re: Making C more beautiful by not using macros with arguments Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-05-30 18:28 -0400
          Re: Making C more beautiful by not using macros with arguments David Kleinecke <dkleinecke@gmail.com> - 2015-05-31 09:27 -0700
            Re: Making C more beautiful by not using macros with arguments Bartc <bc@freeuk.com> - 2015-05-31 17:59 +0100
              Re: Making C more beautiful by not using macros with arguments David Kleinecke <dkleinecke@gmail.com> - 2015-06-01 11:24 -0700
                Re: Making C more beautiful by not using macros with arguments Keith Thompson <kst-u@mib.org> - 2015-06-01 12:15 -0700
                  Re: Making C more beautiful by not using macros with arguments David Kleinecke <dkleinecke@gmail.com> - 2015-06-01 12:21 -0700
                    Re: Making C more beautiful by not using macros with arguments Keith Thompson <kst-u@mib.org> - 2015-06-01 12:53 -0700
            Re: Making C more beautiful by not using macros with arguments Keith Thompson <kst-u@mib.org> - 2015-05-31 13:36 -0700
            Re: Making C more beautiful by not using macros with arguments David Brown <david.brown@hesbynett.no> - 2015-05-31 23:26 +0200
              Re: Making C more beautiful by not using macros with arguments Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-31 23:09 +0100
              Re: Making C more beautiful by not using macros with arguments luser droog <luser.droog@gmail.com> - 2015-05-31 15:51 -0700
                Re: Making C more beautiful by not using macros with arguments David Kleinecke <dkleinecke@gmail.com> - 2015-06-01 12:08 -0700
          Re: Making C more beautiful by not using macros with arguments James Kuyper <jameskuyper@verizon.net> - 2015-06-01 12:38 -0400
            Re: Making C more beautiful by not using macros with arguments Dr Nick <nospam-4@temporary-address.org.uk> - 2015-06-01 19:20 +0100
            Re: Making C more beautiful by not using macros with arguments David Kleinecke <dkleinecke@gmail.com> - 2015-06-01 12:18 -0700
        Re: Making C more beautiful by not using macros with arguments Keith Thompson <kst-u@mib.org> - 2015-05-30 15:43 -0700
          Re: Making C more beautiful by not using macros with arguments David Kleinecke <dkleinecke@gmail.com> - 2015-05-31 09:32 -0700
    Re: Making C more beautiful by not using macros with arguments Les Cargill <lcargill99@comcast.com> - 2015-05-29 22:07 -0500
    Making C more beautiful by not using macros with arguments rick.c.hodgin@gmail.com - 2015-05-30 09:22 -0700
      Re: Making C more beautiful by not using macros with arguments Morris Dovey <mrdovey@iedu.com> - 2015-05-30 14:22 -0500
        Re: Making C more beautiful by not using macros with arguments Bartc <bc@freeuk.com> - 2015-05-30 21:29 +0100
          Re: Making C more beautiful by not using macros with arguments Morris Dovey <mrdovey@iedu.com> - 2015-05-30 22:15 -0500
            Re: Making C more beautiful by not using macros with arguments Morris Dovey <mrdovey@iedu.com> - 2015-06-08 20:16 -0500
    Re: Making C more beautiful by not using macros with arguments David Brown <david.brown@hesbynett.no> - 2015-05-31 17:32 +0200
    Re: Making C more beautiful by not using macros with arguments Richard Heathfield <rjh@cpax.org.uk> - 2015-06-01 22:51 +0100

Page 4 of 4 — ← Prev page 1 2 3 [4]

#62919

On Sunday, May 31, 2015 at 3:52:09 PM UTC-7, luser droog wrote:
> On Sunday, May 31, 2015 at 4:26:45 PM UTC-5, David Brown wrote:
> > On 31/05/15 18:27, David Kleinecke wrote:
> > >
> > > The specific example, of course, is a macro I would never use - but
> > > no matter. The real reason I am deploring macros with arguments is
> > > that they aren't needed and I am interested in stripping the language
> > > down to only what is needed (That is - the core).
> > >
> > 
> > I can understand your point about macros with arguments being 
> > /unnecessary/, at least in cases similar to this one.  But I cannot 
> > understand how you consider
> > 
> > #define MAX_1 x
> > #define MAX_2 y
> > #define MAX ((MAX_1) > (MAX_2) ? (MAX_1) : (MAX_2))
> > 
> > // Thousand lines of code
> > 
> > int foo(int x, int y) {
> > 	#define MAX_1 x
> > 	#define MAX_2 y
> > 	return MAX;
> > }
> > 
> > to be "less ugly" than
> > 
> > #define MAX(x, y) ((x) > (y) ? (x) : (y))
> > 
> > // Thousand lines of code
> > 
> > int foo(int x, int y) {
> > 	return MAX(x, y);
> > }
> > 
> > 
> > I also can't understand the obsession with minimalism.  There are lots 
> > of things that could be removed from C without affecting the programs 
> > you could write.  There is no need for loops other than "while" (or the 
> > "G" macro that another poster is so fond of).  Why bother having "+", 
> > when you can just use "- -"?
> 
> Here's where I contribute some thoughts. This is the aspect of David
> Kleinecke's posts that I feel I do understand. Yes: feel. The urge 
> toward minimalism is a first step (or perhaps an x/y problem) toward
> achieving a notion of completeness. I suspect all of us here respect
> a version of this same drive embodied in the principle of scientific
> parsimony, aka Occam's Razor: "one ought not needlessly multiply terms".
> It gives us the strategies of Factoring and Recursive Decomposition.
> 
> [Esoterically, I see it as a manifestation of the urge toward 
> annihilation with the Logos. But I may be misusing all of these words.]
> 
> For David, if you haven't seen it already, I think "Small C" should
> interest you very much. It was a subset of C developed in the 80s
> by readers of Dr. Dobbs Journal. It was able to compile itself, 
> initially with the aid of an existing implementation to compile
> the compiler, but it was self-hosting after that.
> 
> The entire saga with chapters composed of the original articles and
> readers letter is published in a 700+ page book called Dr. Dobb's
> Toolbox of C. And it includes the full source for version 2.something
> of the compiler and many tools contributed by readers, including
> noteworthy C authors Axel Tobias Schreiner and Alan Holub.
> 
> The very existence of this body of work proves many of the points
> I think are being made: that a subset of C is sufficient to still
> be "general purpose" and capable of building "real programs" like
> a compiler.
> 
> Another minimalist system (which I just recently stumbled across 
> and found interesting) is ASM.js which describes a subset of
> Javascript that is easier to JIT than code which wantonly exploits 
> all the crazy constructs available.
 
I remember small C. I had some quarrels with it but it was a long time
ago and I forget what they were. Thanks for the reminder.

[toc] | [prev] | [next] | [standalone]

#62910

On 05/30/2015 06:28 PM, Lew Pitcher wrote:
> On Saturday May 30 2015 10:46, in comp.lang.c, "David Kleinecke"
> <dkleinecke@gmail.com> wrote:
> 
>> On Friday, May 29, 2015 at 2:17:12 PM UTC-7, Keith Thompson wrote:
>>>
>>> I can write:
>>>
>>>     #define MAX(x, y) ((x) > (y) ? (x) : (y))
>>>
>>> How would you suggest writing that as a parameterless macro?
>>  
>> Wouldn't
>>     #define MAX_1 x
>>     #define MAX_2 y
>>     #define MAX ((MAX_1) > (MAX_2) ? (MAX_1) : (MAX_2))
>> do the same thing?

I've been looking at the responses to this suggestion, and no one seems
to have pointed out what I think is the biggest problem with this
approach - code that uses MAX() more than once, with different arguments.

Here's some real-world code (I'm responsible for it, though I didn't
write it - but I don't see anything wrong with it):

>      max_SD_packets =
>                  MAX((scan_meta->frame_count_array[MD_SD_FRAMES_IN_SCAN] * 2),
>                      PH_REALISTIC_NUM_SD_PACKETS);
> 
>      max_SRCA_packets =
>                  MAX((scan_meta->frame_count_array[MD_SRCA_FRAMES_IN_SCAN] * 2), 
>                      PH_REALISTIC_NUM_SRCA_PACKETS);
> 
>      max_BB_packets =
>                  MAX((scan_meta->frame_count_array[MD_BB_FRAMES_IN_SCAN] * 2),
>                      PH_REALISTIC_NUM_BB_PACKETS);
> 
>      max_SV_packets =
>                  MAX((scan_meta->frame_count_array[MD_SV_FRAMES_IN_SCAN] * 2),
>                      PH_REALISTIC_NUM_SV_PACKETS);

Is David Kleinecke seriously suggesting that this code would be improved
by re-writing it as follows:

#undef MAX_1
#undef MAX_2
#define MAX_1 (scan_meta->frame_count_array[MD_SD_FRAMES_IN_SCAN] * 2)
#define MAX_2 PH_REALISTIC_NUM_SD_PACKETS
	max_SD_packets = MAX;

#undef MAX_1
#undef MAX_2
#define MAX_1 (scan_meta->frame_count_array[MD_SRCA_FRAMES_IN_SCAN] * 2)
#define MAX_2 PH_REALISTIC_NUM_SRCA_PACKETS
	max_BB_packets = MAX;

// etc.

!?

[toc] | [prev] | [next] | [standalone]

#62914

James Kuyper <jameskuyper@verizon.net> writes:

> On 05/30/2015 06:28 PM, Lew Pitcher wrote:
>> On Saturday May 30 2015 10:46, in comp.lang.c, "David Kleinecke"
>> <dkleinecke@gmail.com> wrote:
>> 
>>> On Friday, May 29, 2015 at 2:17:12 PM UTC-7, Keith Thompson wrote:
>>>>
>>>> I can write:
>>>>
>>>>     #define MAX(x, y) ((x) > (y) ? (x) : (y))
>>>>
>>>> How would you suggest writing that as a parameterless macro?
>>>  
>>> Wouldn't
>>>     #define MAX_1 x
>>>     #define MAX_2 y
>>>     #define MAX ((MAX_1) > (MAX_2) ? (MAX_1) : (MAX_2))
>>> do the same thing?
>
> I've been looking at the responses to this suggestion, and no one seems
> to have pointed out what I think is the biggest problem with this
> approach - code that uses MAX() more than once, with different arguments.
>
> Here's some real-world code (I'm responsible for it, though I didn't
> write it - but I don't see anything wrong with it):
>
>>      max_SD_packets =
>>                  MAX((scan_meta->frame_count_array[MD_SD_FRAMES_IN_SCAN] * 2),
>>                      PH_REALISTIC_NUM_SD_PACKETS);
>> 
>>      max_SRCA_packets =
>>                  MAX((scan_meta->frame_count_array[MD_SRCA_FRAMES_IN_SCAN] * 2), 
>>                      PH_REALISTIC_NUM_SRCA_PACKETS);
>> 
>>      max_BB_packets =
>>                  MAX((scan_meta->frame_count_array[MD_BB_FRAMES_IN_SCAN] * 2),
>>                      PH_REALISTIC_NUM_BB_PACKETS);
>> 
>>      max_SV_packets =
>>                  MAX((scan_meta->frame_count_array[MD_SV_FRAMES_IN_SCAN] * 2),
>>                      PH_REALISTIC_NUM_SV_PACKETS);
>
> Is David Kleinecke seriously suggesting that this code would be improved
> by re-writing it as follows:
>
> #undef MAX_1
> #undef MAX_2
> #define MAX_1 (scan_meta->frame_count_array[MD_SD_FRAMES_IN_SCAN] * 2)
> #define MAX_2 PH_REALISTIC_NUM_SD_PACKETS
> 	max_SD_packets = MAX;
>
> #undef MAX_1
> #undef MAX_2
> #define MAX_1 (scan_meta->frame_count_array[MD_SRCA_FRAMES_IN_SCAN] * 2)
> #define MAX_2 PH_REALISTIC_NUM_SRCA_PACKETS
> 	max_BB_packets = MAX;
>
> // etc.
>
> !?

That's exactly what I think he's suggesting.  I still can't work out
why.

[toc] | [prev] | [next] | [standalone]

#62922

On Monday, June 1, 2015 at 9:38:21 AM UTC-7, James Kuyper wrote:
> On 05/30/2015 06:28 PM, Lew Pitcher wrote:
> > On Saturday May 30 2015 10:46, in comp.lang.c, "David Kleinecke"
> > <dkleinecke@gmail.com> wrote:
> > 
> >> On Friday, May 29, 2015 at 2:17:12 PM UTC-7, Keith Thompson wrote:
> >>>
> >>> I can write:
> >>>
> >>>     #define MAX(x, y) ((x) > (y) ? (x) : (y))
> >>>
> >>> How would you suggest writing that as a parameterless macro?
> >>  
> >> Wouldn't
> >>     #define MAX_1 x
> >>     #define MAX_2 y
> >>     #define MAX ((MAX_1) > (MAX_2) ? (MAX_1) : (MAX_2))
> >> do the same thing?
> 
> I've been looking at the responses to this suggestion, and no one seems
> to have pointed out what I think is the biggest problem with this
> approach - code that uses MAX() more than once, with different arguments.
> 
> Here's some real-world code (I'm responsible for it, though I didn't
> write it - but I don't see anything wrong with it):
> 
> >      max_SD_packets =
> >                  MAX((scan_meta->frame_count_array[MD_SD_FRAMES_IN_SCAN] * 2),
> >                      PH_REALISTIC_NUM_SD_PACKETS);
> > 
> >      max_SRCA_packets =
> >                  MAX((scan_meta->frame_count_array[MD_SRCA_FRAMES_IN_SCAN] * 2), 
> >                      PH_REALISTIC_NUM_SRCA_PACKETS);
> > 
> >      max_BB_packets =
> >                  MAX((scan_meta->frame_count_array[MD_BB_FRAMES_IN_SCAN] * 2),
> >                      PH_REALISTIC_NUM_BB_PACKETS);
> > 
> >      max_SV_packets =
> >                  MAX((scan_meta->frame_count_array[MD_SV_FRAMES_IN_SCAN] * 2),
> >                      PH_REALISTIC_NUM_SV_PACKETS);
> 
> Is David Kleinecke seriously suggesting that this code would be improved
> by re-writing it as follows:
> 
> #undef MAX_1
> #undef MAX_2
> #define MAX_1 (scan_meta->frame_count_array[MD_SD_FRAMES_IN_SCAN] * 2)
> #define MAX_2 PH_REALISTIC_NUM_SD_PACKETS
> 	max_SD_packets = MAX;
> 
> #undef MAX_1
> #undef MAX_2
> #define MAX_1 (scan_meta->frame_count_array[MD_SRCA_FRAMES_IN_SCAN] * 2)
> #define MAX_2 PH_REALISTIC_NUM_SRCA_PACKETS
> 	max_BB_packets = MAX;
> 
> // etc.
> 
> !?

More or less - yes. But better
    p = scan_meta->frame_count_array[MD_SD_FRAMES_IN_SCAN] * 2)
    q = PH_REALISTIC_NUM_SD_PACKETS
    max_SD_packets = p < q ? q : p
and so on

[toc] | [prev] | [next] | [standalone]

#62859

David Kleinecke <dkleinecke@gmail.com> writes:
> On Friday, May 29, 2015 at 2:17:12 PM UTC-7, Keith Thompson wrote:
>> 
>> I can write:
>> 
>>     #define MAX(x, y) ((x) > (y) ? (x) : (y))
>> 
>> How would you suggest writing that as a parameterless macro?
>  
> Wouldn't
>     #define MAX_1 x
>     #define MAX_2 y
>     #define MAX ((MAX_1) > (MAX_2) ? (MAX_1) : (MAX_2))
> do the same thing?

I suppose so.  You could also replace functions with parameters by
assigning the argument expressions to global variables.

Your macro would do the same thing *if* the arguments are literally x
and y, but it's much less clear.

> But better just write what one means without the macro (an unfair
> criticism because you were just writing a simple example).

How would you write MAX() without using a macro?  The point is that it
can take arguments of any type for which ">" is meaningful; a function
can't do that.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#62875

On Saturday, May 30, 2015 at 3:43:36 PM UTC-7, Keith Thompson wrote:
> 
> How would you write MAX() without using a macro?  The point is that it
> can take arguments of any type for which ">" is meaningful; a function
> can't do that.

That's a feature I think is really a bug (or least not an advantage).

[toc] | [prev] | [next] | [standalone]

#62822

David Kleinecke wrote:
> In the world of C90 at least.
>
> I think everybody knows that if I were defining a macro with
> arguments I must leave no spaces between the macro name and
> the following opening parenthesis.
>
> I think everybody who has contemplated this fact will agree that is
> is the ugliest thing in C.
>
> I believe it is not indespensible  and only exists because K&R
> wanted to be able to write macros that looked like functions.
> It is hard, at this distance, to see why they thought that was
> important.
>
> Suppose I have, in traditional terms, a macro definition
>      #define fake(foo) array[foo]
>      x = fake(y)
> As I read the rules I could instead write
>      #define foo y
>      #define fake array[foo]
>      x = fake
>
> Normally #define fake array[foo] will be defined far off in
> some header and the immediate code will be
>      #define foo y
>      x = fake     /* fake depends on foo */
> which is only a little longer than
>      x = fake(y)
> and just as opaque.
>
> This "improvement" - if it actually works - is easy to implement -
> just stop writing macros with arguments.
>

People get a lot of rash about preprocessor macros and I just
don't get it.

I use macros if and only if they'll make the code terser, more regular-
looking and cleaner to the eye.

If I can turn a tangle into something that looks like it came
from a spreadsheet, it's a big win. Otherwise, just don't.

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#62849

Macros without the ability to include arguments defeats the primary
use of macros. Any proposal to suppress or remove them from
C, and I would personally extend that argument to include any
programming language,
can be summed up in one word: insane.

Things which have utility exist for a reason. Their benefit may
not be generally universal when applied specifically, but for
what each specific thing was designed to do, the utility is most
certainly there, and this is true in the case of macros with and
without arguments.

All they do is generate source code which is variable per instance
use, at compile time. They have exceedingly high value (above
several other things).

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#62850

On 5/30/15 11:22 AM, rick.c.hodgin@gmail.com wrote:
> Macros without the ability to include arguments defeats the primary
> use of macros. Any proposal to suppress or remove them from
> C, and I would personally extend that argument to include any
> programming language,
> can be summed up in one word: insane.
>
> Things which have utility exist for a reason. Their benefit may
> not be generally universal when applied specifically, but for
> what each specific thing was designed to do, the utility is most
> certainly there, and this is true in the case of macros with and
> without arguments.
>
> All they do is generate source code which is variable per instance
> use, at compile time. They have exceedingly high value (above
> several other things).

I agree wholeheartedly! Used appropriately, they can simplify coding and 
maintenance of otherwise (horribly) messy code.

For doubters, I've uploaded a snapshot of an example to
http://www.iedu.com/tmp/mips_io_h.png
(No, you probably don't want an editable copy.)
that allowed streamlining the coding of a whole collection of device 
drivers. :-)

-- 
Morris Dovey
http://www.iedu.com/Solar

[toc] | [prev] | [next] | [standalone]

#62854

On 30/05/2015 20:22, Morris Dovey wrote:
> On 5/30/15 11:22 AM, rick.c.hodgin@gmail.com wrote:
>> Macros without the ability to include arguments defeats the primary
>> use of macros. Any proposal to suppress or remove them from
>> C, and I would personally extend that argument to include any
>> programming language,
>> can be summed up in one word: insane.
>>
>> Things which have utility exist for a reason. Their benefit may
>> not be generally universal when applied specifically, but for
>> what each specific thing was designed to do, the utility is most
>> certainly there, and this is true in the case of macros with and
>> without arguments.
>>
>> All they do is generate source code which is variable per instance
>> use, at compile time. They have exceedingly high value (above
>> several other things).
>
> I agree wholeheartedly! Used appropriately, they can simplify coding and
> maintenance of otherwise (horribly) messy code.

I have the opposite opinion! Try taking code which uses multi-layered 
macros and converting to another language (one that doesn't have macros 
with arguments for example...). Or simply trying to find out how it works.

> For doubters, I've uploaded a snapshot of an example to
> http://www.iedu.com/tmp/mips_io_h.png

That's a good example. It took me a few minutes to disentangle how it 
works (is (b+(unsigned(r)) adding a byte offset, or what? Is b even a 
pointer?).

For example, it appears that pci(r) fetches a 32-bit unsigned value from 
byte offset r from some hard-coded memory address (and presumably can be 
used to write to the same address). Effectively, a uint array indexed by 
a byte offset (somewhat contrary to how C works).

But is that really not possible to code without such macros, *and* keep 
the code tidy? It seems not! Although I'd need to know more of the 
bigger picture to suggest alternatives.

How is r usually specified for example? How many entries are there 
within PCI? Because a simple array, located at a specific address (if C 
can do that somehow), accessed by index is one way of doing it (r values 
need adjusting to be int offsets).

Or just define a struct instance located at the same address. Now you 
might be able to access those registers with some ease. And no macro 
arguments needed either.

Alternatively it can just be done with functions (something that 
everyone understands and are supported by pretty much every language) 
and rely on inlining if access speed to these control registers is crucial.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#62862

On 5/30/15 3:29 PM, Bartc wrote:
> On 30/05/2015 20:22, Morris Dovey wrote:

>> I agree wholeheartedly! Used appropriately, they can simplify coding and
>> maintenance of otherwise (horribly) messy code.
>
> I have the opposite opinion! Try taking code which uses multi-layered
> macros and converting to another language (one that doesn't have macros
> with arguments for example...). Or simply trying to find out how it works.

Valid points - however in this instance I was brought in to help debug a 
brand new SOC which had (suspected) timing issues using a 
client-specified toolchain (gcc).
>
>> For doubters, I've uploaded a snapshot of an example to
>> http://www.iedu.com/tmp/mips_io_h.png
>
> That's a good example. It took me a few minutes to disentangle how it
> works (is (b+(unsigned(r)) adding a byte offset, or what? Is b even a
> pointer?).

All I/O was memory-mapped, and all devices except the flash memory and 
the ethernet PHY was all on-chip. Communication with devices was through 
device registers - and different devices had their own register sizes, 
and (to keep things simple) the registers for each device were mapped to 
contiguous memory address - and the address of the first register for 
each device was called its "base address".

What those macros do is allow addressing each register by name - and 
inform the compiler that the name is a pointer to a correct-sized 
volatile location.

> For example, it appears that pci(r) fetches a 32-bit unsigned value from
> byte offset r from some hard-coded memory address (and presumably can be
> used to write to the same address). Effectively, a uint array indexed by
> a byte offset (somewhat contrary to how C works).

I looked, but don't have the PCI stuff handy, so I uploaded a similar 
snapshot of some my ethernet header file to

http://www.iedu.com/tmp/eth_h.png

Recall that my task was to stress test the hardware interface logic 
rather than to write production drivers (although I did write test 
programs to exercise all of the circuitry), and they benefited 
substantially from my being able to load a register in one clock cycle 
and read back the value from that register the following clock cycle.

[ Lo and behold! Some device registers failed that simple test - and the 
EEs writing Verilog learned to cringe when I appeared in their area with 
a page of notes to say "Guys, we need to talk..." :-) It might help to 
note that each new generation of silicon cost in the neighborhood of $1M 
:-/ ]

> But is that really not possible to code without such macros, *and* keep
> the code tidy? It seems not! Although I'd need to know more of the
> bigger picture to suggest alternatives.

Yes, it's possible without, but the code is gruesomely untidy and prone 
to difficult-to-spot keyboarding errors.

> How is r usually specified for example? How many entries are there
> within PCI? Because a simple array, located at a specific address (if C
> can do that somehow), accessed by index is one way of doing it (r values
> need adjusting to be int offsets).

True (but only in the same sense that all of memory can be considered a 
simple byte array). There's nearly always more than one way to get a job 
done, but all of those were just a variation on what I show.

> Or just define a struct instance located at the same address. Now you
> might be able to access those registers with some ease. And no macro
> arguments needed either.

You could probably do that - but that would still require all of the 
same information, plus you'd be introducing all the visual clutter of 
structure definitions.

> Alternatively it can just be done with functions (something that
> everyone understands and are supported by pretty much every language)
> and rely on inlining if access speed to these control registers is crucial.

Correctness and speed were what it was all about, and functions had 
already been tried (and found inadequate) before the client bit the 
bullet and invited me to play.

No other language was even considered, and progress toward bug-free 
silicon was rapid. While I was still working on the project there was a 
demonstration with an improved SOC, which resulted in the client's first 
order for 10M of the product and they seemed well-pleased. Me too. :-)

-- 
Morris Dovey
http://www.iedu.com/Solar

[toc] | [prev] | [next] | [standalone]

#63101

I was rummaging through some old code and found this note to myself that 
illustrates the rationale for all those macro definitions:

    /* DMA and interrupts disabled */

    if (d != (t = IO_REG = d)) /* I/F problem! */ ;

I wish I’d spotted it before, but will add it to the conversation before 
I forget.

-- 
Morris Dovey
http://www.iedu.com/Solar

[toc] | [prev] | [next] | [standalone]

#62868

On 29/05/15 19:36, David Kleinecke wrote:
> In the world of C90 at least.
>
> I think everybody knows that if I were defining a macro with
> arguments I must leave no spaces between the macro name and
> the following opening parenthesis.

OK, that's the way the language is defined.

>
> I think everybody who has contemplated this fact will agree that is
> is the ugliest thing in C.

I certainly would not agree with that.  In fact, I think you will find 
barely anyone who thinks it is the ugliest thing in C - if you ask ten 
people in this group for "the ugliest thing in C", you'll get at least a 
dozen different answers.  You will also find a large proportion who 
would always omit the space even if it were optional, just as they write 
"foo(x, y)" and not "foo (x, y)".

[toc] | [prev] | [next] | [standalone]

#62927

On 29/05/15 18:36, David Kleinecke wrote:
> In the world of C90 at least.
>
> I think everybody knows that if I were defining a macro with
> arguments I must leave no spaces between the macro name and
> the following opening parenthesis.
>
> I think everybody who has contemplated this fact will agree that is
> is the ugliest thing in C.

I have, but I don't.

De gustibus and all that.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | comp.lang.c

csiph-web