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

#62873

On Saturday, May 30, 2015 at 3:18:14 PM UTC-7, Keith Thompson wrote:
> 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?

Of course I need additional library functions - C was designed to be that
way. At some point there must be funcions in that library that cannot
themselves be written in C. And there are wheels that should not be
re-invented like math.h even though they could be writen in C. 

These are things the core C can refer to - not parts of C.

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

#62884

David Kleinecke <dkleinecke@gmail.com> writes:
> On Saturday, May 30, 2015 at 3:18:14 PM UTC-7, Keith Thompson wrote:
>> 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?
>
> Of course I need additional library functions - C was designed to be that
> way. At some point there must be funcions in that library that cannot
> themselves be written in C. And there are wheels that should not be
> re-invented like math.h even though they could be writen in C. 

So you do use the standard library.  So much for sticking to core C.

> These are things the core C can refer to - not parts of C.

One more time, the C standard library is part of C.  It's specified
by section 7 of the same standard that specifies the core language.
The library is not part of "core C", if by that you mean the
subset specified by section 6 of the standard.  You'll note that
the standard doesn't use the phrase "core C"; there's no particular
reason it should make that artificial distinction.

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

#62867

On 30/05/15 16:38, David Kleinecke wrote:
> 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.
>

When compilers are both omniscient and omnipotent, we can dispense with 
"inline".  Until then, it can be a useful hint to the compiler - as well 
as a documentation to readers.  (And with gcc, you can use the 
"allways_inline" attribute to enforce inline.)

Also, C does not have function overloading - function-like macros can be 
used to make pseudo-functions that work with different types of arguments.

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

#62805

On 5/29/15 12:36 PM, David Kleinecke wrote:

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

Oops, you thought wrong.

"De gustibus non est disputandum." :-)

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

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

#62806

> "David Kleinecke"  wrote in message 
> news:032b4cc1-a813-4caa-a810-569e1ea3b0ab@googlegroups.com...

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

Well, I have to admit that I am a fan of macros with arguments. A simple 
example:

https://groups.google.com/d/topic/comp.lang.c/JNl51a9nibs/discussion

http://pastebin.com/f52a443b1

;^D 

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

#62808

> "Chris M. Thomasson"  wrote in message 
> news:mkahli$q2m$1@speranza.aioe.org...

> > "David Kleinecke"  wrote in message
> news:032b4cc1-a813-4caa-a810-569e1ea3b0ab@googlegroups.com...

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

> Well, I have to admit that I am a fan of macros with arguments. A simple 
> example:
[...]
> http://pastebin.com/f52a443b1

For instance, the following macros make using the vtable a bit easier:
_________________________________________________________
#define object_destroy(mp_self) ( \
  (mp_self)->vtable->object.fp_destroy((mp_self)) \
)

#define device_read(mp_self, mp_buf, mp_size) ( \
  (mp_self)->vtable->device.fp_read((mp_self), (mp_buf), (mp_size)) \
)

#define device_write(mp_self, mp_buf, mp_size) ( \
  (mp_self)->vtable->device.fp_write((mp_self), (mp_buf), (mp_size)) \
)
_________________________________________________________


;^)

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

#62807

David Kleinecke <dkleinecke@gmail.com> writes:

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

No, those of us who are are accustomed to the normal typography used
everywhere except in programming languages, and who therefore find
putting a space between a function and its arguments to be just plain
weird, don't find it ugly at all.

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

#62810

David Kleinecke <dkleinecke@gmail.com> writes:
> 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. 

Right -- though it's important to note that this requirement doesn't
apply to invocations of function-like macros.

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

I cit myself as one more counterexample of your claim.  I haven't taken
the time to decide what the ugliest thing in C is, but this isn't it.
Off the top of my head, I consider trigraphs, multi-character constants,
and the implementation-defined signedness of plain char to be uglier.
YMMV.

[...]

> This "improvement" - if it actually works - is easy to implement -
> just stop writing macros with arguments.

The standard assert() macro cannot be defined as a parameterless macro.
If it were, then

    assert(expr);

would always evalute expr whether NDEBUG is defined or not.

I routinely use function-like macros for logging.  The macro definitions
depend on compile-time flags, and expand to different code depending on
the logging level.  They could not be written correctly as parameterless
macros; the argument would always be evaluated.

Standard library functions are permitted to be additionally defined as
function-like macros.  Defining them as parameterless macros would not
permit bypassing any macro definition by enclosing the function name in
parentheses.  (That's in section 7 of the standard.)

I can write:

    #define MAX(x, y) ((x) > (y) ? (x) : (y))

How would you suggest writing that as a parameterless macro?

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

#62845

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?

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

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

#62858

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?

Perhaps, but it certainly isn't as readable.

Assume that those defines are at the top of a source code file.
Two thousand lines later, you see

  int foo(int x, int y, int z)
  {
    int y1 = y-z;

    return MAX;
  }

At this point (remember, the definitions for MAX_1, MAX_2 and MAX are two
thousand lines away, out of site, and probably not noticed) what does
function foo() return?

How about, a thousand lines later
  int bar(int x, int y, int z)
  {
    int y1 = y-z;

    return MAX;
  }
?
(Note that 250 lines before function bar(), someone added

  #undef MAX_1
  #define MAX_1 z
)

Now, how is
  MAX
better than
  MAX(x,y)
and
  MAX(x,z)
?

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


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

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

#62874

On Saturday, May 30, 2015 at 3:28:20 PM UTC-7, 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?
> 
> Perhaps, but it certainly isn't as readable.
>
> Assume that those defines are at the top of a source code file.

But that is a silly thing to do to the "argument" macros. The MAX
macro might be described far away but MAX_1 and MAX_2 would be 
defined just before they are needed - and probably undefined 
immediately after.

> Two thousand lines later, you see
> 
>   int foo(int x, int y, int z)
>   {
>     int y1 = y-z;
> 
>     return MAX;
>   }
> 

   int foo(int x, int y, int z)
   {
     int y1 = y-z;
     #define MAX_1 x
     #define MAX_2 y
     return MAX;
   }
 
> At this point (remember, the definitions for MAX_1, MAX_2 and MAX are two
> thousand lines away, out of site, and probably not noticed) what does
> function foo() return?
> 
> How about, a thousand lines later
>   int bar(int x, int y, int z)
>   {
>     int y1 = y-z;
> 
>     return MAX;
>   }
> ?
> (Note that 250 lines before function bar(), someone added
> 
>   #undef MAX_1
>   #define MAX_1 z
> )
> 
> Now, how is
>   MAX
> better than
>   MAX(x,y)
> and
>   MAX(x,z)
> ?
> 
> > 
> > But better just write what one means without the macro (an unfair
> > criticism because you were just writing a simple example).
 
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).

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

#62877

On 31/05/2015 17: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).

But most existing code will use such macros. And C programmers will 
expect to use them.

So, unless you expect input source to be pre-processed elsewhere, or 
will only be coding in it yourself (eg. for code generation), such a 
stripped-down language will be of little interest to someone expecting 'C'.

(The pre-processor was one of several reasons that stopped me dashing 
off a C compiler. I wasn't interested in the effort that would be 
needed, and it looked difficult. But I couldn't just leave it out 
because one purpose of such a project was to translate existing C code. 
And C code seems to use the preprocessor a lot!

There are ways to get an existing C compiler to output pre-processed 
source, but that has its own problems.)

-- 
Bartc

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

#62915

On Sunday, May 31, 2015 at 9:59:31 AM UTC-7, Bart wrote:
> On 31/05/2015 17: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).
> 
> But most existing code will use such macros. And C programmers will 
> expect to use them.
> 
> So, unless you expect input source to be pre-processed elsewhere, or 
> will only be coding in it yourself (eg. for code generation), such a 
> stripped-down language will be of little interest to someone expecting 'C'.
> 
> (The pre-processor was one of several reasons that stopped me dashing 
> off a C compiler. I wasn't interested in the effort that would be 
> needed, and it looked difficult. But I couldn't just leave it out 
> because one purpose of such a project was to translate existing C code. 
> And C code seems to use the preprocessor a lot!
> 
> There are ways to get an existing C compiler to output pre-processed 
> source, but that has its own problems.)
> 
> -- 
> Bartc

I am not trying very hard to change anything going on today in the real
world. I am aiming toward simplifying the use of C in the remote future.
Like somebody once said once a long time ago "I don't know what the
programming language of 2020 will be but I know what its name will be -
FORTRAN". I am aiming at, say, 2075.

However I am not advocating removing anything from C (althouh I do agree
that ungetc should go). I am advocating not using some features. 

I think you made a small error back then - a preprocessor is fairly easy
to write. Much easier than a compiler or even a syntax checker. Especialy
if you omit explit tokenization.

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

#62921

David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> However I am not advocating removing anything from C (althouh I do agree
> that ungetc should go). I am advocating not using some features. 

Ok, thank you for clarifying that.

The pattern I've noticed is that you've advocated not using some
particular feature, followed by numerous people showing that that
feature is much easier to use than any alternative.  Function-like
macros are a recent example.

As for ungetc, with whom are yhou agreeing?  I don't recall ungetc
being mentioned in this thread, nor do I recall anyone advocating
removing it from the standard.

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

#62923

On Monday, June 1, 2015 at 12:15:54 PM UTC-7, Keith Thompson wrote:
> David Kleinecke <dkleinecke@gmail.com> writes:
> [...]
> > However I am not advocating removing anything from C (althouh I do agree
> > that ungetc should go). I am advocating not using some features. 
> 
> Ok, thank you for clarifying that.
> 
> The pattern I've noticed is that you've advocated not using some
> particular feature, followed by numerous people showing that that
> feature is much easier to use than any alternative.  Function-like
> macros are a recent example.
> 
> As for ungetc, with whom are yhou agreeing?  I don't recall ungetc
> being mentioned in this thread, nor do I recall anyone advocating
> removing it from the standard.
 
C11 disparages it and predicts it's demise.

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

#62924

David Kleinecke <dkleinecke@gmail.com> writes:
> On Monday, June 1, 2015 at 12:15:54 PM UTC-7, Keith Thompson wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>> [...]
>> > However I am not advocating removing anything from C (althouh I do agree
>> > that ungetc should go). I am advocating not using some features. 
>> 
>> Ok, thank you for clarifying that.
>> 
>> The pattern I've noticed is that you've advocated not using some
>> particular feature, followed by numerous people showing that that
>> feature is much easier to use than any alternative.  Function-like
>> macros are a recent example.
>> 
>> As for ungetc, with whom are yhou agreeing?  I don't recall ungetc
>> being mentioned in this thread, nor do I recall anyone advocating
>> removing it from the standard.
>  
> C11 disparages it and predicts it's demise.

It does not.

N1570 7.31.11p2:

    The use of ungetc on a binary stream where the file position
    indicator is zero prior to the call is an obsolescent feature.

One particular use is obsolescent.  Its use on text streams is
unaffected, and there is no hint that it could be removed.

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

#62885

David Kleinecke <dkleinecke@gmail.com> writes:
[...]
> 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).

*Everyone* strips the language down to only what they need, simply
by only using those language features that are appropriate.

If you don't like function-like macros, then by all means don't
use them (though you might find yourself using them without being
aware of it).

I don't use function-like macros when they're not appropriate.
The same is true of every feature of the language and library.
For example, I don't use floating-point in the code I work on for my
job.  But I don't suggest removing support for it from the language.

Are you proposing that the C standard should be modified to remove
function-like macros?  (Do you know how much existing code that
would break?)  Or are you proposing a new C-like language that
doesn't support them?  Or are you just talking about features you'd
rather not use yourself?

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

#62893

On 31/05/15 18:27, David Kleinecke wrote:
> On Saturday, May 30, 2015 at 3:28:20 PM UTC-7, 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?
>>
>> Perhaps, but it certainly isn't as readable.
>>
>> Assume that those defines are at the top of a source code file.
>
> But that is a silly thing to do to the "argument" macros. The MAX
> macro might be described far away but MAX_1 and MAX_2 would be
> defined just before they are needed - and probably undefined
> immediately after.
>
>> Two thousand lines later, you see
>>
>>    int foo(int x, int y, int z)
>>    {
>>      int y1 = y-z;
>>
>>      return MAX;
>>    }
>>
>
>     int foo(int x, int y, int z)
>     {
>       int y1 = y-z;
>       #define MAX_1 x
>       #define MAX_2 y
>       return MAX;
>     }
>
>> At this point (remember, the definitions for MAX_1, MAX_2 and MAX are two
>> thousand lines away, out of site, and probably not noticed) what does
>> function foo() return?
>>
>> How about, a thousand lines later
>>    int bar(int x, int y, int z)
>>    {
>>      int y1 = y-z;
>>
>>      return MAX;
>>    }
>> ?
>> (Note that 250 lines before function bar(), someone added
>>
>>    #undef MAX_1
>>    #define MAX_1 z
>> )
>>
>> Now, how is
>>    MAX
>> better than
>>    MAX(x,y)
>> and
>>    MAX(x,z)
>> ?
>>
>>>
>>> But better just write what one means without the macro (an unfair
>>> criticism because you were just writing a simple example).
>
> 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 "- -"?

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

#62896

David Brown <david.brown@hesbynett.no> writes:
<snip>
> 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 "- -"?

Nit: + and - - are not interchangeable in C due to the possibility of
overflow.

-- 
Ben.

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

#62898

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.

-- 
lusor basiliensis

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

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

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

csiph-web