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

#62800 — Making C more beautiful by not using macros with arguments

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.

[toc] | [next] | [standalone]

#62802

On 29/05/2015 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 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.

It's important because C doesn't use a symbol such as "=" or ":" between 
a macro, and any arguments, and what it's defined as.

So that:

  #define mac(a,b,c)   // mac(x,y,z) expands to nothing

and:

  #define mac (a,b,c)  // mac(x,y,z) expands to (a,b,c)(x,y,z)

mean different things. Inserting a symbol makes it obvious what is being 
defined:

  #define mac = (a,b,c)   // mac clearly has no arguments (and
                          // expands to (a,b,c))

  #define mac (a,b,c) =   // mac clearly has 3 arguments (and
                          // expands to nothing)

Spaces are no longer significant.

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

Probably 90% of C code depends on macros with arguments. /That/ is one 
of the ugliest features of the language, never mind that extra space.

(It also means the language misses out on some proper new features, 
because people can just cobble together their own ugly home-made macros 
to half-do the job instead.)

-- 
Bartc

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

#62842

On Friday, May 29, 2015 at 11:04:32 AM UTC-7, Bart wrote:
> On 29/05/2015 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 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.
> 
> It's important because C doesn't use a symbol such as "=" or ":" between 
> a macro, and any arguments, and what it's defined as.
> 
> So that:
> 
>   #define mac(a,b,c)   // mac(x,y,z) expands to nothing
> 
> and:
> 
>   #define mac (a,b,c)  // mac(x,y,z) expands to (a,b,c)(x,y,z)
> 
> mean different things. Inserting a symbol makes it obvious what is being 
> defined:
> 
>   #define mac = (a,b,c)   // mac clearly has no arguments (and
>                           // expands to (a,b,c))
> 
>   #define mac (a,b,c) =   // mac clearly has 3 arguments (and
>                           // expands to nothing)
> 
> Spaces are no longer significant.

My God, you misunderstood my comment in a way I hadn't expected. I 
wrote "It is hard, at this distance, to see why they thought that was
important." meaning about why they thought they needed macros with
arguments not about the space. I should hav been clearer.

...

> Probably 90% of C code depends on macros with arguments. /That/ is one 
> of the ugliest features of the language, never mind that extra space.
> 
> (It also means the language misses out on some proper new features, 
> because people can just cobble together their own ugly home-made macros 
> to half-do the job instead.)
 
I don't much like the pre-processor but it is indespensible - if only for
#include (and conditional compilation). #define has two functions - as 
flags for conditional compilation and as true expanding macros. We need
the flags - I think we could get along without expansions.

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

#62846

On 30/05/2015 15:30, David Kleinecke wrote:
> On Friday, May 29, 2015 at 11:04:32 AM UTC-7, Bart wrote:

>> It's important because C doesn't use a symbol such as "=" or ":" between
>> a macro, and any arguments, and what it's defined as.
>>

> My God, you misunderstood my comment in a way I hadn't expected. I
> wrote "It is hard, at this distance, to see why they thought that was
> important." meaning about why they thought they needed macros with
> arguments not about the space. I should hav been clearer.

OK. But my comments about using "=" with define still stands; that would 
have saved a lot of trouble.

>> Probably 90% of C code depends on macros with arguments. /That/ is one
>> of the ugliest features of the language, never mind that extra space.
>>
>> (It also means the language misses out on some proper new features,
>> because people can just cobble together their own ugly home-made macros
>> to half-do the job instead.)
>
> I don't much like the pre-processor but it is indespensible - if only for
> #include (and conditional compilation). #define has two functions - as
> flags for conditional compilation and as true expanding macros. We need
> the flags - I think we could get along without expansions.

None of the languages I've used (mostly home-made ones) have had macros 
with arguments. That includes those that do the same job as C, but so 
far I'm managed fine without such macros.

There are some lexical features along the lines of C's pre-processor, 
but they are little used, except for code that originated as C.

C, however, seems to find this stuff indispensable. Partly, because some 
code needs to work in many different configurations, but then the source 
becomes impossible to follow, just a mess of macros and conditional code.

I however prefer to find alternate solutions.

-- 
Bartc

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

#62804

David Kleinecke <dkleinecke@gmail.com> writes:

> In the world of C90 at least.
<snip>
> just stop writing macros with arguments.

Inline functions help with that, but they are in a later version of C
that you reject (for reasons I can't fathom, but that's not the point
here).  You advise against macros with arguments, but offer no
alternative.  (You referred to an "improvement" but quotes like that
usually indicate sarcasm.)

Of course macros that use the # and ## operators can't be replaced with
inline functions, even for those of us happy to use modern C.

-- 
Ben.

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

#62843

On Friday, May 29, 2015 at 11:26:17 AM UTC-7, Ben Bacarisse wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> 
> > In the world of C90 at least.
> <snip>
> > just stop writing macros with arguments.
> 
> Inline functions help with that, but they are in a later version of C
> that you reject (for reasons I can't fathom, but that's not the point
> here).  You advise against macros with arguments, but offer no
> alternative.  (You referred to an "improvement" but quotes like that
> usually indicate sarcasm.)
 
I don't reject higher versions of C - I'd just rather stick to core C.
As nearly as I can tell inline functions are better left to the
optimizer. The optimizer can easily inline any freestanding functions
it deems suitable to inline. Telling the optimizer what to inline is
a bit like using the register specifier. 

> Of course macros that use the # and ## operators can't be replaced with
> inline functions, even for those of us happy to use modern C.
 
This aspect of pre-processor I would accept as useful - but it does not
require macros with arguments.

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

#62856

David Kleinecke <dkleinecke@gmail.com> writes:
<snip>
>> Of course macros that use the # and ## operators can't be replaced with
>> inline functions, even for those of us happy to use modern C.
>  
> This aspect of pre-processor I would accept as useful - but it does not
> require macros with arguments.

Can you give an example of a parameter-less macro that uses #?

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?

-- 
Ben.

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

#62860

On 30/05/2015 21:44, Ben Bacarisse wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> <snip>
>>> Of course macros that use the # and ## operators can't be replaced with
>>> inline functions, even for those of us happy to use modern C.
>>
>> This aspect of pre-processor I would accept as useful - but it does not
>> require macros with arguments.
>
> Can you give an example of a parameter-less macro that uses #?
>
> 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?

(If adjacent numeric literals were concatenated, or ## was allowed 
outside a macro definition, then the B macro would not be needed. If 
binary literals were available, perhaps with alternatives for digits 0 
and 1, then the PAT_ macros wouldn't be needed either.

If min() and max() were built-in operators, then we wouldn't need to 
create macros for those. (And if C had a for-statement I liked, I 
wouldn't need to write FOR(i,a,b).)

It seems that many macros with arguments are just used to get around 
deficiencies in the language.

I can see that creating clever macros can be appealing, but someone 
might have to try and decipher them afterwards!)

-- 
Bartc

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

#62861

Bartc <bc@freeuk.com> writes:

> On 30/05/2015 21:44, Ben Bacarisse wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> <snip>
>>>> Of course macros that use the # and ## operators can't be replaced with
>>>> inline functions, even for those of us happy to use modern C.
>>>
>>> This aspect of pre-processor I would accept as useful - but it does not
>>> require macros with arguments.
>>
>> Can you give an example of a parameter-less macro that uses #?
>>
>> 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?
>
> (If adjacent numeric literals were concatenated, [...]

But David Kleinecke is advocating the avoidance of macros with
arguments, not replacing C with a new language (unless I missed his
point altogether).

<snip>
-- 
Ben.

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

#62863

On 31/05/2015 00:27, Ben Bacarisse wrote:
> Bartc <bc@freeuk.com> writes:
>
>> On 30/05/2015 21:44, Ben Bacarisse wrote:

>>>     #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?
>>
>> (If adjacent numeric literals were concatenated, [...]
>
> But David Kleinecke is advocating the avoidance of macros with
> arguments, not replacing C with a new language (unless I missed his
> point altogether).

I thought he was implementing a version of C89 or C90, which makes it 
possible to experiment with these small changes, although it's also true 
it would quickly make it an incompatible language.

I still think that it's undesirable to have to resort to macros with 
arguments because of something not otherwise possible in the language.

(While trying to locate a file mips_io.h to make sense of Morris Dovey's 
driver code, I came across some source that appeared to use ## to 
concatenate tokens, but in normal code.

Then I noticed each line ended in \. Scrolling up, it appeared this was 
part of a single large macro that defined two entire functions (and with 
four macro arguments).

It also uses an __asm__{} block just in case the reader is finding too 
easy to follow the code so far.

The functions were also defined as inline. *And* it appears this 
4-argument macro isn't invoked directly, but used in the definition of 
at least one more layer of macros.

At least the whole thing wasn't part of a conditional #ifdef block - or 
was it?)

-- 
Bartc

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

#62864

Bartc <bc@freeuk.com> writes:

> On 31/05/2015 00:27, Ben Bacarisse wrote:
>> Bartc <bc@freeuk.com> writes:
>>
>>> On 30/05/2015 21:44, Ben Bacarisse wrote:
>
>>>>     #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?
>>>
>>> (If adjacent numeric literals were concatenated, [...]
>>
>> But David Kleinecke is advocating the avoidance of macros with
>> arguments, not replacing C with a new language (unless I missed his
>> point altogether).
>
> I thought he was implementing a version of C89 or C90, which makes it
> possible to experiment with these small changes, although it's also
> true it would quickly make it an incompatible language.

Maybe he will answer my questions and I'll find out, but if his words
really meant "don't use macros with parameters, use this language that
is not quite C instead" I would not have answered -- I'm not interested
in yet another language a bit like C.

<snip>
-- 
Ben.

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

#62876

On Sunday, May 31, 2015 at 3:00:32 AM UTC-7, Ben Bacarisse wrote:
> Bartc <bc@freeuk.com> writes:
> 
> > On 31/05/2015 00:27, Ben Bacarisse wrote:
> >> Bartc <bc@freeuk.com> writes:
> >>
> >>> On 30/05/2015 21:44, Ben Bacarisse wrote:
> >
> >>>>     #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?
> >>>
> >>> (If adjacent numeric literals were concatenated, [...]
> >>
> >> But David Kleinecke is advocating the avoidance of macros with
> >> arguments, not replacing C with a new language (unless I missed his
> >> point altogether).
> >
> > I thought he was implementing a version of C89 or C90, which makes it
> > possible to experiment with these small changes, although it's also
> > true it would quickly make it an incompatible language.
> 
> Maybe he will answer my questions and I'll find out, but if his words
> really meant "don't use macros with parameters, use this language that
> is not quite C instead" I would not have answered -- I'm not interested
> in yet another language a bit like C.
 
I'm trying to answer your quetsions - hit me again with any I have
left unanswered. 

I am most assuredly not trying to define a new language. I am trying to
clarify the core of C - by which I would like to say K&R 1978. But I
can't - too many loose ends. So I am working with C90 - I imagine K&R
2nd ed to be the same - as a good version of code C. I still think C90
is a suitable basis but there seem to be more barnacles than I knew
about when I started. The big goal is to make programs easier to
understand.

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

#62879

On 31/05/2015 17:45, David Kleinecke wrote:
> On Sunday, May 31, 2015 at 3:00:32 AM UTC-7, Ben Bacarisse wrote:

> I'm trying to answer your quetsions - hit me again with any I have
> left unanswered.
>
> I am most assuredly not trying to define a new language. I am trying to
> clarify the core of C - by which I would like to say K&R 1978. But I
> can't - too many loose ends. So I am working with C90 - I imagine K&R
> 2nd ed to be the same - as a good version of code C. I still think C90
> is a suitable basis but there seem to be more barnacles than I knew
> about when I started. The big goal is to make programs easier to
> understand.

That was vaguely one of my aims too, but achieved by translating C to a 
more friendly syntax.

But C is too open-ended as a language and has too many quirks, so it can 
be a bit like trying to turn ASM into high level structured code.

As an example of the quirks, take this simple program:

  int main(void) {}

How many people know that it can also be written like this:

  int (main(void)) {}

(with the extra parentheses)? At least one C compiler doesn't!

While the prototype for a function 'g', taking parameter type 'h', and 
returning type 'f', can be written as:

  f(g(h));

Which happens to look exactly like a couple of nested function calls! 
(This means it's not possible to write a simple syntax translator for C.)

-- 
Bartc

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

#62882

Bartc <bc@freeuk.com> writes:
[...]
> As an example of the quirks, take this simple program:
>
>  int main(void) {}
>
> How many people know that it can also be written like this:
>
>  int (main(void)) {}
>
> (with the extra parentheses)? At least one C compiler doesn't!


I didn't know that, but I verified it by compiling with gcc and checking
the syntax in the standard.

Which compiler?

Incidentally, cdecl recognizes int (main(void)) -- and any compiler that
doesn't is non-conforming.

> While the prototype for a function 'g', taking parameter type 'h', and
> returning type 'f', can be written as:
>
>  f(g(h));
>
> Which happens to look exactly like a couple of nested function calls!
> (This means it's not possible to write a simple syntax translator for
> C.)

The difference is that f and h are type names, which are syntactically
distinct from identifiers.

This:

    int(g(int));

is valid, but is more clearly written as

    int g(int);

Parentheses are permitted in declarators for the same reason they're
allowed in expressions: to specify grouping and improve clarity.  C's
declaration syntax is peculiar enough that the result can be confusing.

In this case, int is a keyword, not an identifier, so there's no real
ambiguity.  If you use a typedef name:

    typedef int foo;
    foo(g(foo));
    // or foo g(foo);

it *seems* more ambiguous, but it isn't really.  Typedefs were added to
the language relatively late (I don't remember whether K&R1 had them),
and they caused some syntactic problems.  A typedef declaration
effectively creates a new keyword, but only within the scope of the
declaration -- except that the identifier can be redeclared in an inner
scope.  This makes it impossible to parse C without feedback from the
symbol table.

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

#62883

On Sunday May 31 2015 16:04, in comp.lang.c, "Keith Thompson" <kst-u@mib.org>
wrote:

[snip]
> Typedefs were added to
> the language relatively late (I don't remember whether K&R1 had them),
> and they caused some syntactic problems.

typedef was part of K&R1; Chapter 6 "Structures" section 6.9 "Typedef"

[snip]

HTH
-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
> 

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

#62886

On 31/05/2015 21:04, Keith Thompson wrote:
> Bartc <bc@freeuk.com> writes:

>> How many people know that it can also be written like this:
>>
>>   int (main(void)) {}
>>
>> (with the extra parentheses)? At least one C compiler doesn't!
>
> I didn't know that, but I verified it by compiling with gcc and checking
> the syntax in the standard.
>
> Which compiler?

It was Digital Mars' compiler that didn't like it. This is quite an old 
one from 2004, but presumably that syntax existed long before.

(But it compiles 'int (main(void));' OK.)

> This makes it impossible to parse C without feedback from the
> symbol table.

Yes, but not just that. It might only be possible to build the symbol 
table by processing macros, typedefs and conditional code that come 
before; in fact you need to implement half of a C compiler.

Even then it can be impossible to properly parse 'f(g(h));' if 'f' for 
example depends on a conditional macro which is submitted as a compiler 
option, or somehow depends on the current environment.

So for browsing C source code via automatic tools (especially in 
isolation from a specific build, compiler or target), or if you want to 
do a /one-off/ translation into some other form, then C can present 
difficulties.

(It doesn't make it any easier for a human reader either!)

-- 
Bartc

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

#62891

Bartc <bc@freeuk.com> writes:
> On 31/05/2015 21:04, Keith Thompson wrote:
[...]
>> This makes it impossible to parse C without feedback from the
>> symbol table.
>
> Yes, but not just that. It might only be possible to build the symbol
> table by processing macros, typedefs and conditional code that come
> before; in fact you need to implement half of a C compiler.
>
> Even then it can be impossible to properly parse 'f(g(h));' if 'f' for
> example depends on a conditional macro which is submitted as a
> compiler option, or somehow depends on the current environment.
>
> So for browsing C source code via automatic tools (especially in
> isolation from a specific build, compiler or target), or if you want
> to do a /one-off/ translation into some other form, then C can present
> difficulties.
>
> (It doesn't make it any easier for a human reader either!)

Of course C can't be reliably parsed without passing it through the
preprocessor.  A #include directive can apply arbitrary macro
definitions, which can do extreme violence to the syntax; anything that
looks like an identifier can be transformed into any arbitrary token
sequence.

Tools that aren't compilers can do a reasonably good job *if* the code
doesn't play too many nasty tricks with the preprocessor -- and a tool
can do a complete job without worrying about code generation.

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

#62916

On Sunday, May 31, 2015 at 10:20:42 AM UTC-7, Bart wrote:
> On 31/05/2015 17:45, David Kleinecke wrote:
> > On Sunday, May 31, 2015 at 3:00:32 AM UTC-7, Ben Bacarisse wrote:
> 
> > I'm trying to answer your quetsions - hit me again with any I have
> > left unanswered.
> >
> > I am most assuredly not trying to define a new language. I am trying to
> > clarify the core of C - by which I would like to say K&R 1978. But I
> > can't - too many loose ends. So I am working with C90 - I imagine K&R
> > 2nd ed to be the same - as a good version of code C. I still think C90
> > is a suitable basis but there seem to be more barnacles than I knew
> > about when I started. The big goal is to make programs easier to
> > understand.
> 
> That was vaguely one of my aims too, but achieved by translating C to a 
> more friendly syntax.
> 
> But C is too open-ended as a language and has too many quirks, so it can 
> be a bit like trying to turn ASM into high level structured code.
> 
> As an example of the quirks, take this simple program:
> 
>   int main(void) {}
> 
> How many people know that it can also be written like this:
> 
>   int (main(void)) {}
> 
> (with the extra parentheses)? At least one C compiler doesn't!
> 
> While the prototype for a function 'g', taking parameter type 'h', and 
> returning type 'f', can be written as:
> 
>   f(g(h));
> 
> Which happens to look exactly like a couple of nested function calls! 
> (This means it's not possible to write a simple syntax translator for C.)

I believe that this particular example will not pass a compliler because
f and h will be recognized as type names but I am aware that I am making
the assumption that if a name is a type name it behaves like a keyword.
I have not checked with the standard about that.

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

#62881

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.

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

#62890

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, at least not in portable code.  N1570
6.10.3.2p1:

    Constraints

    Each # preprocessing token in the replacement list for a
    function-like macro shall be followed by a parameter as the
    next preprocessing token in the wreplacement list.

(C90 has similar wording.)

[...]

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

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

csiph-web