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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#62895

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> <snip>
>>
>>> I'm trying to answer your quetsions - hit me again with any I have
>>> left unanswered.
>>
>> You said of the # and ## operators that this aspect of the pre-processor
>> is useful but does not require require macros with arguments.  I asked
>> two questions:
>>
>> (1) Can you give an example of a parameter-less macro that uses #?
>
> No such example exists,

That was, of course, why I asked!

<snip>
-- 
Ben.

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

#62897

On 31/05/2015 20:37, Ben Bacarisse wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> <snip>
>
>> I'm trying to answer your quetsions - hit me again with any I have
>> left unanswered.
>
> You said of the # and ## operators that this aspect of the pre-processor
> is useful but does not require require macros with arguments.  I asked
> two questions:
>
> (1) Can you give an example of a parameter-less macro that uses #?
>
> (2) I posted a use of ## recently:
>
>    #define B(a, b)   BX(PAT_ ## a, PAT_ ## b)
>    #define BX(a, b)  BXX(a, b)
>    #define BXX(a, b) 0x ## a ## b,
>
>    const unsigned image[] = {
>    B(X___,___X)
>    ...etc...
>    };
>
>    How do you do this without arguments?

I tried to do this without arguments (with the entire image definition 
in a macro). But ## doesn't work how I expect it; if A and B are macros, 
then:

  A ## B

will join A and B before expanding them. I need them expanded then 
joined. So the language is indirectly forcing you to use macro arguments 
(as it seems that some extra magic can be done with them).

(Not that this solves all the problems; it would have taken me ages to 
come up with your B, BX and BXX macros, or more likely would never have 
done so. It's still not exactly intuitive.)

-- 
Bartc

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

#62918

On Sunday, May 31, 2015 at 12:38:18 PM UTC-7, Ben Bacarisse wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> <snip>
> 
> > I'm trying to answer your quetsions - hit me again with any I have
> > left unanswered.
> 
> You said of the # and ## operators that this aspect of the pre-processor
> is useful but does not require require macros with arguments.  I asked
> two questions:
> 
> (1) Can you give an example of a parameter-less macro that uses #?
> 
> (2) I posted a use of ## recently:
> 
>   #define B(a, b)   BX(PAT_ ## a, PAT_ ## b)
>   #define BX(a, b)  BXX(a, b)
>   #define BXX(a, b) 0x ## a ## b,
> 
>   const unsigned image[] = {
>   B(X___,___X)
>   ...etc...
>   };
> 
>   How do you do this without arguments?
> 
> <snip>
> -- 
> Ben.

(1) I thought this was trivial because I read # as ##. My error. Of
course, I can't. # Only means something in a macro with arguments. 
Having never used # I haven't thought about it and how, if possible, 
to do it without the #

(2) I don't see why the general way of removing arguments wont work   

    #define B_1 PAT_ ## X__
    #define B_2 PAT_ ## __X
    #define B 0x ## B_1 ## B_2

I did that in a hurry and may have made mistakes but you get the
general idea.

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

#62933

David Kleinecke <dkleinecke@gmail.com> writes:

> On Sunday, May 31, 2015 at 12:38:18 PM UTC-7, Ben Bacarisse wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> <snip>
>> 
>> > I'm trying to answer your quetsions - hit me again with any I have
>> > left unanswered.
>> 
>> You said of the # and ## operators that this aspect of the pre-processor
>> is useful but does not require require macros with arguments.  I asked
>> two questions:
>> 
>> (1) Can you give an example of a parameter-less macro that uses #?
>> 
>> (2) I posted a use of ## recently:
>> 
>>   #define B(a, b)   BX(PAT_ ## a, PAT_ ## b)
>>   #define BX(a, b)  BXX(a, b)
>>   #define BXX(a, b) 0x ## a ## b,
>> 
>>   const unsigned image[] = {
>>   B(X___,___X)
>>   ...etc...
>>   };
>> 
>>   How do you do this without arguments?
>> 
>> <snip>
>> -- 
>> Ben.
>
> (1) I thought this was trivial because I read # as ##. My error. Of
> course, I can't. # Only means something in a macro with arguments. 
> Having never used # I haven't thought about it and how, if possible, 
> to do it without the #

So do you still think that # is useful (and hence you accept that macro
arguments are useful) or do you think # can be thrown under the bus just
to your desire to avoid macros with arguments?

> (2) I don't see why the general way of removing arguments wont work   
>
>     #define B_1 PAT_ ## X__
>     #define B_2 PAT_ ## __X
>     #define B 0x ## B_1 ## B_2
>
> I did that in a hurry and may have made mistakes but you get the
> general idea.

No, I don't.  I asked because I can't see the genera idea of how to
avoid the perfectly innocent feature that you've arbitrarily decided to
rule out.  I need you to explain how to do it (ideally with code, so
everyone can compare the two).

-- 
Ben.

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

#62942

On 02/06/2015 01:14, Ben Bacarisse wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:

>> (1) I thought this was trivial because I read # as ##. My error. Of
>> course, I can't. # Only means something in a macro with arguments.
>> Having never used # I haven't thought about it and how, if possible,
>> to do it without the #
>
> So do you still think that # is useful (and hence you accept that macro
> arguments are useful) or do you think # can be thrown under the bus just
> to your desire to avoid macros with arguments?

Clearly # isn't useful if it's only meaningful for macro arguments and 
the aim is to avoid macro arguments. But it is still needed for #include 
and so on.

>> (2) I don't see why the general way of removing arguments wont work
>>
>>      #define B_1 PAT_ ## X__
>>      #define B_2 PAT_ ## __X
>>      #define B 0x ## B_1 ## B_2
>>
>> I did that in a hurry and may have made mistakes but you get the
>> general idea.
>
> No, I don't.  I asked because I can't see the genera idea of how to
> avoid the perfectly innocent feature that you've arbitrarily decided to
> rule out.  I need you to explain how to do it (ideally with code, so
> everyone can compare the two).

Macro arguments would be avoided in the same way they would be in any 
other language without macro arguments. He's already given alternatives 
for MAX.

(Using an add-on macro processor is not allowed. But even if you 
resorted to this, then the same technique can be applied to the OP's 
proposed restricted C.)

(The B/BX/BXX set of macros is harder. However here is one solution /to 
the problem it's trying to solve/ that doesn't use macro arguments:

http://pastebin.com/bU2catVn

It also has the advantage that it's easy to grasp how it works, unlike 
your set of macros where I have no idea how it does it or why it has to 
be done like that.

But doubtless you will come up with another example which is harder to 
circumvent.)

-- 
Bartc

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

#62943

Bartc <bc@freeuk.com> writes:

> On 02/06/2015 01:14, Ben Bacarisse wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>
>>> (1) I thought this was trivial because I read # as ##. My error. Of
>>> course, I can't. # Only means something in a macro with arguments.
>>> Having never used # I haven't thought about it and how, if possible,
>>> to do it without the #
>>
>> So do you still think that # is useful (and hence you accept that macro
>> arguments are useful) or do you think # can be thrown under the bus just
>> to your desire to avoid macros with arguments?
>
> Clearly # isn't useful if it's only meaningful for macro arguments and
> the aim is to avoid macro arguments.

Yes, clearly.  I don't think we disagree on this.  David Kleinecke said
that macro arguments are not needed but also that # and ## (as
*operators*) are useful.  He says he read # as ##, but that does not
clear up what he thinks about uses of # -- it just means he's not yet
said anything about it having misread it as ##.  Is using # an exception
to his silly rule about macros with arguments or does he think it's not
useful?  I may, one day, find out.

<snip>
>>> (2) I don't see why the general way of removing arguments wont work
>>>
>>>      #define B_1 PAT_ ## X__
>>>      #define B_2 PAT_ ## __X
>>>      #define B 0x ## B_1 ## B_2
>>>
>>> I did that in a hurry and may have made mistakes but you get the
>>> general idea.
>>
>> No, I don't.  I asked because I can't see the genera idea of how to
>> avoid the perfectly innocent feature that you've arbitrarily decided to
>> rule out.  I need you to explain how to do it (ideally with code, so
>> everyone can compare the two).
>
> Macro arguments would be avoided in the same way they would be in any
> other language without macro arguments. He's already given
> alternatives for MAX.

MAX does not use ## so it can't possibly help explain DK's position
here.  DK (a) thinks # and ## are useful (though maybe only ##); (b)
does not want to change C; and (c) says that macros arguments are not
needed.  This is the puzzle.

By the way, do you agree with DK about any of these points?  Do you
actually agree that his frankly daft alternative to MAX makes the code
better?

<snip>
-- 
Ben.

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

#62944

On 02/06/2015 11:06, Ben Bacarisse wrote:
> Bartc <bc@freeuk.com> writes:

>> Macro arguments would be avoided in the same way they would be in any
>> other language without macro arguments. He's already given
>> alternatives for MAX.
>
> MAX does not use ## so it can't possibly help explain DK's position
> here.  DK (a) thinks # and ## are useful (though maybe only ##); (b)
> does not want to change C; and (c) says that macros arguments are not
> needed.  This is the puzzle.
>
> By the way, do you agree with DK about any of these points?

(a) I don't really fully understand what ## does. After writing a few 
tens of thousands of lines of C, I've never used it. (When I have tried 
it, it didn't do what I expected: if tokens are macro names, it 
concatenates them before expanding them).

So to me ## is not useful and I wouldn't miss it.

(b) He wants to use a restricted subset of C. That can work when C is 
used as a code generator target, for example (but readability isn't a 
big issue there). But specifying coding guidelines and avoiding certain 
features can be useful, that's nothing new.

(c) Avoiding macros with arguments completely: all I can say is that in 
a million lines of code outside C, I've never used macros with 
arguments, and only rarely use them in C. So in this case I might agree.

> Do you
> actually agree that his frankly daft alternative to MAX makes the code
> better?

I didn't grasp the MAX one. But this alternative seemed simple enough:

     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

Splitting up the original code has made it more readable. (Maybe the 
MAX() version could have been formatted differently, but the above 
approach forces you to do so.)

-- 
Bartc

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

#62945

Bart,

I use this macro for creating unions with _ prefixed names of
another type (typically a pointer to struct, and a signed or unsigned
integer, the value of which is the pointer's address).

    #define _union(x, y, z) union { x z; y _ ## z; }

In source code I use:
_union(SMyStruct*, int, abc);

It creates:
union
{
    SMyStruct* abc;
    int _abc;
};

The ## merges text, concatenating into a single, unified thing.

Best regards,
Rick C. Hodgin

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

#62946

Bartc <bc@freeuk.com> writes:

> On 02/06/2015 11:06, Ben Bacarisse wrote:
>> Bartc <bc@freeuk.com> writes:
>
>>> Macro arguments would be avoided in the same way they would be in any
>>> other language without macro arguments. He's already given
>>> alternatives for MAX.
>>
>> MAX does not use ## so it can't possibly help explain DK's position
>> here.  DK (a) thinks # and ## are useful (though maybe only ##); (b)
>> does not want to change C; and (c) says that macros arguments are not
>> needed.  This is the puzzle.
>>
>> By the way, do you agree with DK about any of these points?
>
> (a) I don't really fully understand what ## does. After writing a few
> tens of thousands of lines of C, I've never used it. (When I have
> tried it, it didn't do what I expected: if tokens are macro names, it
> concatenates them before expanding them).
>
> So to me ## is not useful and I wouldn't miss it.
>
> (b) He wants to use a restricted subset of C. That can work when C is
> used as a code generator target, for example (but readability isn't a
> big issue there). But specifying coding guidelines and avoiding
> certain features can be useful, that's nothing new.
>
> (c) Avoiding macros with arguments completely: all I can say is that
> in a million lines of code outside C, I've never used macros with
> arguments, and only rarely use them in C. So in this case I might
> agree.

OK.  There's nothing contentious there.  You won't miss ## (I can't make
you miss it!), and having some coding guidelines certainly is useful,
and though you don't write much C, macros with arguments have some use
(enough that you've used them).

>> Do you
>> actually agree that his frankly daft alternative to MAX makes the code
>> better?
>
> I didn't grasp the MAX one.

Right.  So for the moment it would be safe to say that you don't think
the code was improved?  To say so, you'd have to have an comprehensible
example first, yes?

> But this alternative seemed simple enough:
>
>     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
>
> Splitting up the original code has made it more readable.

Right, but avoiding the MAX macro altogether was not the contentious
claim.  The contentious claim is to keep it but without arguments and
you found *that* example incomprehensible.

Let's not lose track of the preposterous nature of this argument.  DK
says "just stop writing macros with arguments" and the example he
originally gives is to define

 #define fake array[foo]

"far off in some header" and then to write

  #define foo y
  x = fake     /* fake depends on foo */

where you need it, rather than simply using

  #define fake(foo) array[foo]

Now let's see how he summarises this suggestion.  He describes it as

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

So it's longer and just as opaque (I think it's more opaque but that's
not the issue right now) and the word "improvement" is in quotes -- even
*he* does not think it's an improvement!  And from this modest post he's
got days of entertainment, admittedly helped by topping it up with a few
more crank claims.

<snip>
-- 
Ben.

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

#62947

On 02/06/2015 13:24, Ben Bacarisse wrote:

> And from this modest post he's got days of entertainment, admittedly
> helped by topping it up with a few more crank claims.

What took you so long?!

Perhaps it is time now to send him to the bit bucket?

Regards.

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

#62948

On 02/06/15 14:41, Noob wrote:
> On 02/06/2015 13:24, Ben Bacarisse wrote:
>
>> And from this modest post he's got days of entertainment, admittedly
>> helped by topping it up with a few more crank claims.
>
> What took you so long?!
>
> Perhaps it is time now to send him to the bit bucket?

He has an alternative perspective on C. That's allowed, isn't it? And as 
far as I can tell, he has been polite throughout. So the bit bucket 
seems a little harsh at this stage.

Anyway, even for those who think he's a crank (a judgement on which I 
offer no opinion), some of the most interesting threads in comp.lang.c 
are started by cranks. One doesn't have to take a crank seriously to 
benefit from a discussion that he or she starts.

-- 
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] | [next] | [standalone]

#62949 — Re: Trolls/Cranks/Kooks

On 02/06/2015 16:00, Richard Heathfield wrote:
> On 02/06/15 14:41, Noob wrote:
>> On 02/06/2015 13:24, Ben Bacarisse wrote:
>>
>>> And from this modest post he's got days of entertainment, admittedly
>>> helped by topping it up with a few more crank claims.
>>
>> What took you so long?!
>>
>> Perhaps it is time now to send him to the bit bucket?
> 
> He has an alternative perspective on C. That's allowed, isn't it? And as 
> far as I can tell, he has been polite throughout. So the bit bucket 
> seems a little harsh at this stage.

Different people, different thresholds.
(Yours is high, considering AOB and remy.)

> Anyway, even for those who think he's a crank (a judgement on which I 
> offer no opinion), some of the most interesting threads in comp.lang.c 
> are started by cranks. One doesn't have to take a crank seriously to 
> benefit from a discussion that he or she starts.

Can you provide an example or two?
(I kill entire threads. Perhaps I missed a gem in the manure.)

Regards.

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

#62950 — Re: Trolls/Cranks/Kooks

On 02/06/15 15:41, Noob wrote:
> On 02/06/2015 16:00, Richard Heathfield wrote:
>> On 02/06/15 14:41, Noob wrote:
>>> On 02/06/2015 13:24, Ben Bacarisse wrote:
>>>
>>>> And from this modest post he's got days of entertainment, admittedly
>>>> helped by topping it up with a few more crank claims.
>>>
>>> What took you so long?!
>>>
>>> Perhaps it is time now to send him to the bit bucket?
>>
>> He has an alternative perspective on C. That's allowed, isn't it? And as
>> far as I can tell, he has been polite throughout. So the bit bucket
>> seems a little harsh at this stage.
>
> Different people, different thresholds.
> (Yours is high, considering AOB and remy.)
>
>> Anyway, even for those who think he's a crank (a judgement on which I
>> offer no opinion), some of the most interesting threads in comp.lang.c
>> are started by cranks. One doesn't have to take a crank seriously to
>> benefit from a discussion that he or she starts.
>
> Can you provide an example or two?

I'd have thought the current thread would constitute a good example. It 
surfaced a few misunderstandings that some people seem to have about 
macros. Okay, it's not earth-shaking, but it sure beats UFOs (a recent 
thread that very few people seemed to object to).

> (I kill entire threads. Perhaps I missed a gem in the manure.)

A gem? No. A thread of minor pedagogical interest? Yes. But "manure"? 
I've seen many clc threads that deserve that metaphor far more than this 
one does.

-- 
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] | [next] | [standalone]

#62953 — Re: Trolls/Cranks/Kooks

On 02/06/2015 16:56, Richard Heathfield wrote:

> I'd have thought the current thread would constitute a good example. It 
> surfaced a few misunderstandings that some people seem to have about 
> macros. Okay, it's not earth-shaking, but it sure beats UFOs (a recent 
> thread that very few people seemed to object to).

I KFed JN a decade ago. I see his posts when I use a fresh install.

> A gem? No. A thread of minor pedagogical interest? Yes. But "manure"? 
> I've seen many clc threads that deserve that metaphor far more than this 
> one does.

Errr... Isn't it obvious that I haven't killed this thread? :-)

Regards.

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

#62954 — Re: Trolls/Cranks/Kooks

On 02/06/15 16:09, Noob wrote:

> Errr... Isn't it obvious that I haven't killed this thread? :-)

You may not have done, but I certainly have! :-)

-- 
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] | [next] | [standalone]

#62951

Noob <root@127.0.0.1> writes:

> On 02/06/2015 13:24, Ben Bacarisse wrote:
>
>> And from this modest post he's got days of entertainment, admittedly
>> helped by topping it up with a few more crank claims.
>
> What took you so long?!

I pointed out almost immediately that his post was obviously a wind-up.

> Perhaps it is time now to send him to the bit bucket?

Cranks are not alone in getting entertainment from Usenet.

-- 
Ben.

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

#62957

Bartc <bc@freeuk.com> writes:

> On 02/06/2015 01:14, Ben Bacarisse wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>
>>> (1) I thought this was trivial because I read # as ##. My error. Of
>>> course, I can't. # Only means something in a macro with arguments.
>>> Having never used # I haven't thought about it and how, if possible,
>>> to do it without the #
>>
>> So do you still think that # is useful (and hence you accept that macro
>> arguments are useful) or do you think # can be thrown under the bus just
>> to your desire to avoid macros with arguments?
>
> Clearly # isn't useful if it's only meaningful for macro arguments and
> the aim is to avoid macro arguments. But it is still needed for
> #include and so on.
>
>>> (2) I don't see why the general way of removing arguments wont work
>>>
>>>      #define B_1 PAT_ ## X__
>>>      #define B_2 PAT_ ## __X
>>>      #define B 0x ## B_1 ## B_2
>>>
>>> I did that in a hurry and may have made mistakes but you get the
>>> general idea.
>>
>> No, I don't.  I asked because I can't see the genera idea of how to
>> avoid the perfectly innocent feature that you've arbitrarily decided to
>> rule out.  I need you to explain how to do it (ideally with code, so
>> everyone can compare the two).
>
> Macro arguments would be avoided in the same way they would be in any
> other language without macro arguments. He's already given
> alternatives for MAX.

Why not do away with local variables where you are at it?  It's an
analogous change IMO.

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

#62956

On Monday, June 1, 2015 at 5:14:28 PM UTC-7, Ben Bacarisse wrote:
> 
> So do you still think that # is useful (and hence you accept that macro
> arguments are useful) or do you think # can be thrown under the bus just
> to your desire to avoid macros with arguments?
 
Heck no. If I were to encounter a situation where I needed # (so far
I never have) I would go ahead and use a macro with arguments. Better
than, say, an assembly language subroutine. Nothing to get uptight
about. The computer should be uptight enough for all of us. 

> > (2) I don't see why the general way of removing arguments wont work   
> >
> >     #define B_1 PAT_ ## X__
> >     #define B_2 PAT_ ## __X
> >     #define B 0x ## B_1 ## B_2
> >
> > I did that in a hurry and may have made mistakes but you get the
> > general idea.
> 
> No, I don't.  I asked because I can't see the genera idea of how to
> avoid the perfectly innocent feature that you've arbitrarily decided to
> rule out.  I need you to explain how to do it (ideally with code, so
> everyone can compare the two).
 
Well, first off, does my alternative do the same thing as your
elaborate example?

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

#62958

David Kleinecke <dkleinecke@gmail.com> writes:

> On Monday, June 1, 2015 at 5:14:28 PM UTC-7, Ben Bacarisse wrote:
<attributions snipped but not by me>

>> > (2) I don't see why the general way of removing arguments wont work   
>> >
>> >     #define B_1 PAT_ ## X__
>> >     #define B_2 PAT_ ## __X
>> >     #define B 0x ## B_1 ## B_2
>> >
>> > I did that in a hurry and may have made mistakes but you get the
>> > general idea.
>> 
>> No, I don't.  I asked because I can't see the genera[l] idea of how to
>> avoid the perfectly innocent feature that you've arbitrarily decided to
>> rule out.  I need you to explain how to do it (ideally with code, so
>> everyone can compare the two).
>  
> Well, first off, does my alternative do the same thing as your
> elaborate example?

No.  (The fact that you don't know that suggests this whole exchange is
pointless.)

-- 
Ben.

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

#62857

David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> I don't reject higher versions of C - I'd just rather stick to core C.
[...]

Where "core C" means the part of C described in section 6 of the
standard.

Does that mean you don't use the standard library?  How do you
do I/O?  String operations?  Math functions?  Dynamic memory
allocation?  Or do you work in an environment where those things
are either unnecessary or unavailable?

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

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

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

csiph-web