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

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

configure() -- a new C compiler preprocessor and code injection proposal

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

Contents

  configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-21 08:27 -0700
    Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-21 20:15 -0700
      Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-21 20:25 -0700
    Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-21 20:34 -0700
      Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-22 09:46 -0700
        Re: configure() -- a new C compiler preprocessor and code injection proposal Philip Lantz <prl@canterey.us> - 2015-08-22 13:15 -0700
        Re: configure() -- a new C compiler preprocessor and code injection proposal fir <profesor.fir@gmail.com> - 2015-08-22 13:25 -0700
    Re: configure() -- a new C compiler preprocessor and code injection proposal Ian Collins <ian-news@hotmail.com> - 2015-08-23 09:06 +1200
      Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-22 14:47 -0700
        Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-22 23:09 +0100
          Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-22 15:21 -0700
            Re: configure() -- a new C compiler preprocessor and code injection proposal gordonb.qvmey@burditt.org (Gordon Burditt) - 2015-08-23 17:21 -0500
              Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-23 16:53 -0700
                Re: configure() -- a new C compiler preprocessor and code injection proposal gordonb.bkbkd@burditt.org (Gordon Burditt) - 2015-08-23 19:44 -0500
                  Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-23 19:08 -0700
                    Re: configure() -- a new C compiler preprocessor and code injection proposal gordonb.rnzzf@burditt.org (Gordon Burditt) - 2015-08-23 22:29 -0500
                      Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-23 20:43 -0700
                        Re: configure() -- a new C compiler preprocessor and code injection proposal gordonb.594yb@burditt.org (Gordon Burditt) - 2015-08-24 07:09 -0500
                          Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-24 05:30 -0700
                            Re: configure() -- a new C compiler preprocessor and code injection proposal Gordon Burditt <gordon@hammy.burditt.org> - 2015-08-24 07:39 -0500
                              Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-24 05:43 -0700
                                Re: configure() -- a new C compiler preprocessor and code injection proposal David Kleinecke <dkleinecke@gmail.com> - 2015-08-24 18:11 -0700
                                  Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 03:18 -0700
                                    Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-25 14:31 +0200
                                      Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 05:36 -0700
                                Re: configure() -- a new C compiler preprocessor and code injection proposal Richard Damon <Richard@Damon-Family.org> - 2015-08-24 22:01 -0400
                                  Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 03:22 -0700
                                    Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-25 12:12 +0100
                                      Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 04:26 -0700
                                        Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-25 13:09 +0100
                                          Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 05:20 -0700
                                            Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-25 13:50 +0100
                                              Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 06:08 -0700
                                                Re: configure() -- a new C compiler preprocessor and code injection proposal gazelle@shell.xmission.com (Kenny McCormack) - 2015-08-25 14:34 +0000
                                                  Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 07:53 -0700
                                  Re: configure() -- a new C compiler preprocessor and code injection proposal jt@toerring.de (Jens Thoms Toerring) - 2015-08-25 12:53 +0000
                                    Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 06:19 -0700
                                      Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-25 15:47 +0200
                                        Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 07:23 -0700
                                          Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-25 16:41 +0200
                                            Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-25 08:08 -0700
                              Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-24 05:54 -0700
                    Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-24 09:17 +0100
          Re: configure() -- a new C compiler preprocessor and code injection proposal gazelle@shell.xmission.com (Kenny McCormack) - 2015-08-22 22:22 +0000
            Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-22 15:31 -0700
          Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-23 23:13 +0200
        Re: configure() -- a new C compiler preprocessor and code injection proposal fir <profesor.fir@gmail.com> - 2015-08-22 15:40 -0700
          Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-22 16:00 -0700
            Re: configure() -- a new C compiler preprocessor and code injection proposal fir <profesor.fir@gmail.com> - 2015-08-22 16:05 -0700
        Re: configure() -- a new C compiler preprocessor and code injection proposal Ian Collins <ian-news@hotmail.com> - 2015-08-23 11:07 +1200
          Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-22 16:15 -0700
    Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-22 15:01 -0700
      Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-22 23:16 +0100
        Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-22 15:24 -0700
    Re: configure() -- a new C compiler preprocessor and code injection proposal gordonb.i2ffz@burditt.org (Gordon Burditt) - 2015-08-22 17:40 -0500
      Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-22 15:55 -0700
        Re: configure() -- a new C compiler preprocessor and code injection proposal Ian Collins <ian-news@hotmail.com> - 2015-08-23 11:13 +1200
          Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-22 16:19 -0700
            Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-22 16:29 -0700
              Re: configure() -- a new C compiler preprocessor and code injection proposal Richard Damon <Richard@Damon-Family.org> - 2015-08-22 21:04 -0400
        Re: configure() -- a new C compiler preprocessor and code injection proposal gordonb.501pe@burditt.org (Gordon Burditt) - 2015-08-23 18:25 -0500
          Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-23 17:18 -0700
            Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-24 10:41 +0200
      Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-23 22:55 +0200
        Re: configure() -- a new C compiler preprocessor and code injection proposal gordonb.ca5vg@burditt.org (Gordon Burditt) - 2015-08-23 18:43 -0500
          Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-24 10:57 +0200
            Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-24 05:40 -0700
              Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-24 15:07 +0200
                Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-24 06:29 -0700
                  Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-24 15:56 +0200
                    Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-24 07:18 -0700
                      Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-24 17:22 +0200
              Re: configure() -- a new C compiler preprocessor and code injection proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-24 14:36 +0100
                Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-24 06:49 -0700
    Re: configure() -- a new C compiler preprocessor and code injection proposal "Morten W. Petersen" <morphex@gmail.com> - 2015-08-23 12:55 +0200
      Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-23 04:58 -0700
      Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-23 13:03 +0100
        Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-23 05:20 -0700
          Re: configure() -- a new C compiler preprocessor and code injection proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-23 16:59 +0100
            Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-23 09:34 -0700
              Re: configure() -- a new C compiler preprocessor and code injection proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-23 20:10 +0100
            Re: configure() -- a new C compiler preprocessor and code injection proposal gazelle@shell.xmission.com (Kenny McCormack) - 2015-08-23 16:36 +0000
        Re: configure() -- a new C compiler preprocessor and code injection proposal "Morten W. Petersen" <morphex@gmail.com> - 2015-08-23 14:27 +0200
          Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-23 13:35 +0100
            Re: configure() -- a new C compiler preprocessor and code injection proposal "Morten W. Petersen" <morphex@gmail.com> - 2015-08-23 15:08 +0200
              Re: configure() -- a new C compiler preprocessor and code injection proposal Keith Thompson <kst-u@mib.org> - 2015-08-23 14:27 -0700
                Re: configure() -- a new C compiler preprocessor and code injection proposal "Morten W. Petersen" <morphex@gmail.com> - 2015-08-31 19:24 +0200
                  Re: configure() -- a new C compiler preprocessor and code injection proposal James Kuyper <jameskuyper@verizon.net> - 2015-08-31 13:53 -0400
                    Re: configure() -- a new C compiler preprocessor and code injection proposal "Morten W. Petersen" <morphex@gmail.com> - 2015-08-31 19:59 +0200
                      Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-31 19:10 +0100
                      Re: configure() -- a new C compiler preprocessor and code injection proposal Keith Thompson <kst-u@mib.org> - 2015-08-31 11:27 -0700
                      Re: configure() -- a new C compiler preprocessor and code injection proposal James Kuyper <jameskuyper@verizon.net> - 2015-08-31 15:40 -0400
                  Re: configure() -- a new C compiler preprocessor and code injection proposal Keith Thompson <kst-u@mib.org> - 2015-08-31 11:22 -0700
                    Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-31 12:18 -0700
                      Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-09-01 10:09 +0200
                        Re: configure() -- a new C compiler preprocessor and code injection proposal Keith Thompson <kst-u@mib.org> - 2015-09-01 08:12 -0700
                          Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-09-01 22:19 +0200
                    Re: configure() -- a new C compiler preprocessor and code injection proposal Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 14:47 -0700
              Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-23 23:13 +0200
                Re: configure() -- a new C compiler preprocessor and code injection proposal "Morten W. Petersen" <morphex@gmail.com> - 2015-08-31 22:27 +0200
                  Re: configure() -- a new C compiler preprocessor and code injection proposal supercat@casperkitty.com - 2015-08-31 15:00 -0700
                    Re: configure() -- a new C compiler preprocessor and code injection proposal "Morten W. Petersen" <morphex@gmail.com> - 2015-09-01 00:56 +0200
                      Re: configure() -- a new C compiler preprocessor and code injection proposal James Kuyper <jameskuyper@verizon.net> - 2015-08-31 20:11 -0400
                        Re: configure() -- a new C compiler preprocessor and code injection proposal "Morten W. Petersen" <morphex@gmail.com> - 2015-09-01 12:26 +0200
                          Re: configure() -- a new C compiler preprocessor and code injection proposal James Kuyper <jameskuyper@verizon.net> - 2015-09-01 13:37 -0400
                            Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-09-01 22:18 +0200
                              Re: configure() -- a new C compiler preprocessor and code injection proposal James Kuyper <jameskuyper@verizon.net> - 2015-09-01 16:31 -0400
                            Re: configure() -- a new C compiler preprocessor and code injection proposal "Morten W. Petersen" <morphex@gmail.com> - 2015-09-04 07:15 +0200
                              Re: configure() -- a new C compiler preprocessor and code injection proposal James Kuyper <jameskuyper@verizon.net> - 2015-09-04 07:28 -0400
                  Re: configure() -- a new C compiler preprocessor and code injection proposal James Kuyper <jameskuyper@verizon.net> - 2015-08-31 20:02 -0400
                  Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-09-01 09:41 +0200
                    Re: configure() -- a new C compiler preprocessor and code injection proposal "Morten W. Petersen" <morphex@gmail.com> - 2015-09-01 12:24 +0200
                      Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-09-01 14:14 +0200
                        Re: configure() -- a new C compiler preprocessor and code injection proposal "Morten W. Petersen" <morphex@gmail.com> - 2015-09-04 07:22 +0200
                          Re: configure() -- a new C compiler preprocessor and code injection proposal James Kuyper <jameskuyper@verizon.net> - 2015-09-04 07:38 -0400
                      Re: configure() -- a new C compiler preprocessor and code injection proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-01 13:14 +0100
                      Re: configure() -- a new C compiler preprocessor and code injection proposal James Kuyper <jameskuyper@verizon.net> - 2015-09-01 11:07 -0400
              Re: configure() -- a new C compiler preprocessor and code injection proposal gordonb.vg6n6@burditt.org (Gordon Burditt) - 2015-08-23 19:29 -0500
                Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-24 09:32 +0100
                  Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-24 11:43 +0200
                    Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-24 11:01 +0100
                      Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-24 12:24 +0200
                        Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-24 12:06 +0100
                          Re: configure() -- a new C compiler preprocessor and code injection proposal David Brown <david.brown@hesbynett.no> - 2015-08-24 14:21 +0200
        Re: configure() -- a new C compiler preprocessor and code injection   proposal Ian Collins <ian-news@hotmail.com> - 2015-08-24 07:48 +1200
          Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-23 12:56 -0700
      Re: configure() -- a new C compiler preprocessor and code injection proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-23 13:45 +0100
        Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-23 14:38 +0100
          Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-23 06:43 -0700
            Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-23 15:00 +0100
              Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-23 07:54 -0700
                Re: configure() -- a new C compiler preprocessor and code injection proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-23 19:28 +0100
                  Re: configure() -- a new C compiler preprocessor and code injection proposal mark.bluemel@gmail.com - 2015-08-24 00:31 -0700
          Re: configure() -- a new C compiler preprocessor and code injection proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-23 16:17 +0100
            Re: configure() -- a new C compiler preprocessor and code injection proposal Bartc <bc@freeuk.com> - 2015-08-23 16:30 +0100
              Re: configure() -- a new C compiler preprocessor and code injection proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-23 19:44 +0100
        Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-23 06:40 -0700
          Re: configure() -- a new C compiler preprocessor and code injection proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-23 16:29 +0100
      Re: configure() -- a new C compiler preprocessor and code injection proposal gordonb.kj6kb@burditt.org (Gordon Burditt) - 2015-08-23 19:13 -0500
    Re: configure() -- a new C compiler preprocessor and code injection proposal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-09-04 05:10 -0700

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

#68137

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> Ben Bacariase wrote:
>> Morten (who you credit with the idea) said:
>>
>>     "The idea of a configure() function is that it
>>      replaces macros"
>
> When did he say that? Before or after I started
> this thread?

Sun, 23 Aug 2015 12:55:21 +0200.  You started the thread on the 22nd.

In the same post, just a few lines before it is stated more forcefully:

  "Well, the point wasn't to add something to C as such, the point was
  that it should be possible to drop macros from a compiler, making for
  a slimmer variant of C."

I.e. to replace macros in every sense, so that they are simply not
needed.  That's why I posted my examples and asked for how they would be
done with this simmer, macro-less C that uses configure() instead.

The fact that you had no substantive comments to make about those
examples is because you and he are taking about two quite different
things.  I have no idea what you are talking about (and, please, there's
no need to try to explain it again) but I thought it worth asking what
Morten had in mind because I could formulate explicit questions about a
C-line language with no macros.

<snip>
-- 
Ben.

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

#68132

In article <87lhd23s3c.fsf@bsb.me.uk>,
Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
>"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
><snip>
>> I do not think this new configure ability should replace macros.

See note 1) below.

>Morten (who you credit with the idea) said:
>
>  "The idea of a configure() function is that it replaces macros"

See note 2) below.

><snip>

Far be it for me to be defending RCH, who I think is as loony as they come
(His spouting of the God stuff being just the icing on the cake), but to be
fair, there *are* multiple senses of the word "replace" in play here.

If this suggestion of his had any merit (which it doesn't), then it *would*
replace macros "going forward" - that is, new code written by smart people
would use the new configure() stuff and would pretty much leave macros to
the legions of code maintainers.  Eventually, like gets() and implicit int,
it would get dropped from the Standards documents, and would, eventually
after that, be dropped from the major implementations.

1) "replace" in the second sense - that is, of being dropped by the
Standards and, eventually, by the major implementations.

2) "replace" in the first sense - that is, of being dropped by smart people
writing new code.

-- 
People who say they'll vote for someone else because Obama couldn't solve
all of Bush's messes are like people complaining that he couldn't cure cancer,
so they'll go and vote for cancer.

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

#68110

On 23.08.2015 14:03, Bartc wrote:
> On 23/08/2015 11:55, Morten W. Petersen wrote:
>> On 21.08.2015 17:27, Rick C. Hodgin wrote:
>>> Morten W. Petersen came up with an idea for a configure() function
>
>>> I have created this thread to discuss the idea.  So far, I have had
>>> the idea that there should be some new keywords added which allow
>>> this ability to inject code programmatically when conifgure() is
>>> pre-compiled and executed, before the rest of the C source code is
>>> compiled.
>
>> Well, the point wasn't to add something to C as such, the point was
>> that it should be possible to drop macros from a compiler, making for a
>> slimmer variant of C.
>>
>> What I was thinking you were onto, was a hack if you can call it that,
>> which enables C-style code to be used instead of macros.
>>
>> The idea of a configure() function is that it replaces macros, and
>> should do so in a clean and simple way.
>
> How would it replace a macro like this:
>
> #define FOR(i,a,b) for(i=a; i<=b; ++i)
>
> (And at what stage do all FOR invocations in the source get expanded?)
>
> Macros with arguments are an important part of C. I don't think you can
> remove them without replacing them with something that can do the same
> things. And in the case of macros such as the above, I can't see the
> definition looking much different, or being less effort to implement.

Couldn't that be replaced by an inline function?

-Morten

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

#68111

On 23/08/2015 13:27, Morten W. Petersen wrote:
> On 23.08.2015 14:03, Bartc wrote:
>> On 23/08/2015 11:55, Morten W. Petersen wrote:
>>> On 21.08.2015 17:27, Rick C. Hodgin wrote:
>>>> Morten W. Petersen came up with an idea for a configure() function
>>
>>>> I have created this thread to discuss the idea.  So far, I have had
>>>> the idea that there should be some new keywords added which allow
>>>> this ability to inject code programmatically when conifgure() is
>>>> pre-compiled and executed, before the rest of the C source code is
>>>> compiled.
>>
>>> Well, the point wasn't to add something to C as such, the point was
>>> that it should be possible to drop macros from a compiler, making for a
>>> slimmer variant of C.
>>>
>>> What I was thinking you were onto, was a hack if you can call it that,
>>> which enables C-style code to be used instead of macros.
>>>
>>> The idea of a configure() function is that it replaces macros, and
>>> should do so in a clean and simple way.
>>
>> How would it replace a macro like this:
>>
>> #define FOR(i,a,b) for(i=a; i<=b; ++i)
>>
>> (And at what stage do all FOR invocations in the source get expanded?)
>>
>> Macros with arguments are an important part of C. I don't think you can
>> remove them without replacing them with something that can do the same
>> things. And in the case of macros such as the above, I can't see the
>> definition looking much different, or being less effort to implement.
>
> Couldn't that be replaced by an inline function?

Not this example, because it's not an expression, but a piece of syntax. 
The invocation would be followed by {...}, a single statement; or ";".

-- 
Bartc

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

#68118

On 23.08.2015 14:35, Bartc wrote:
> On 23/08/2015 13:27, Morten W. Petersen wrote:
>> On 23.08.2015 14:03, Bartc wrote:
>>> On 23/08/2015 11:55, Morten W. Petersen wrote:
>>>> On 21.08.2015 17:27, Rick C. Hodgin wrote:
>>>>> Morten W. Petersen came up with an idea for a configure() function
>>>
>>>>> I have created this thread to discuss the idea.  So far, I have had
>>>>> the idea that there should be some new keywords added which allow
>>>>> this ability to inject code programmatically when conifgure() is
>>>>> pre-compiled and executed, before the rest of the C source code is
>>>>> compiled.
>>>
>>>> Well, the point wasn't to add something to C as such, the point was
>>>> that it should be possible to drop macros from a compiler, making for a
>>>> slimmer variant of C.
>>>>
>>>> What I was thinking you were onto, was a hack if you can call it that,
>>>> which enables C-style code to be used instead of macros.
>>>>
>>>> The idea of a configure() function is that it replaces macros, and
>>>> should do so in a clean and simple way.
>>>
>>> How would it replace a macro like this:
>>>
>>> #define FOR(i,a,b) for(i=a; i<=b; ++i)
>>>
>>> (And at what stage do all FOR invocations in the source get expanded?)
>>>
>>> Macros with arguments are an important part of C. I don't think you can
>>> remove them without replacing them with something that can do the same
>>> things. And in the case of macros such as the above, I can't see the
>>> definition looking much different, or being less effort to implement.
>>
>> Couldn't that be replaced by an inline function?
>
> Not this example, because it's not an expression, but a piece of syntax.
> The invocation would be followed by {...}, a single statement; or ";".

Are there any cases for macros where they couldn't be replaced by
functions?  Like it would be many more lines of code to do something
similar in C code.

A point about the macros is that they are different than regular C
code, and because of that an added point of complexity / confusion.

So a new programmer wouldn't have to learn macros in a variant of
C that drops that support.  And another template language could
be used for simple or not so simple substitutions.

-Morten

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

#68146

"Morten W. Petersen" <morphex@gmail.com> writes:
> On 23.08.2015 14:35, Bartc wrote:
>> On 23/08/2015 13:27, Morten W. Petersen wrote:
>>> On 23.08.2015 14:03, Bartc wrote:
[...]
>>>> How would it replace a macro like this:
>>>>
>>>> #define FOR(i,a,b) for(i=a; i<=b; ++i)
>>>>
>>>> (And at what stage do all FOR invocations in the source get expanded?)
>>>>
>>>> Macros with arguments are an important part of C. I don't think you can
>>>> remove them without replacing them with something that can do the same
>>>> things. And in the case of macros such as the above, I can't see the
>>>> definition looking much different, or being less effort to implement.
>>>
>>> Couldn't that be replaced by an inline function?
>>
>> Not this example, because it's not an expression, but a piece of syntax.
>> The invocation would be followed by {...}, a single statement; or ";".
>
> Are there any cases for macros where they couldn't be replaced by
> functions?  Like it would be many more lines of code to do something
> similar in C code.

I'm probably misunderstanding the question, because the obvious answer
is that you've just seen an example of a macro that cannot be replaced
by a function, inline or otherwise.  (Conceivably you could write an
inline function that takes a function pointer as an argument, with the
function acting as the body of the loop -- but the function would have
to be defined separately, and its body would not be in the scope of the
loop.)

> A point about the macros is that they are different than regular C
> code, and because of that an added point of complexity / confusion.

And added capabilities.

> So a new programmer wouldn't have to learn macros in a variant of
> C that drops that support.  And another template language could
> be used for simple or not so simple substitutions.

C already has a template language, the preprocessor.  What is the
advantage of replacing that with a *different* template language?

Even if you decide to do that, there's no real need to incorporate it
into the language.  Tools that generate C code are already quite common,
and can be invoked automatically by any build system.

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

#68765

On 23.08.2015 23:27, Keith Thompson wrote:
> "Morten W. Petersen" <morphex@gmail.com> writes:
[...]
>> Are there any cases for macros where they couldn't be replaced by
>> functions?  Like it would be many more lines of code to do something
>> similar in C code.
>
> I'm probably misunderstanding the question, because the obvious answer
> is that you've just seen an example of a macro that cannot be replaced
> by a function, inline or otherwise.  (Conceivably you could write an
> inline function that takes a function pointer as an argument, with the
> function acting as the body of the loop -- but the function would have
> to be defined separately, and its body would not be in the scope of the
> loop.)

OK.  I still don't see any "magic" that can't be replaced by simple
C (inline) functions or some trivial alterations of how the program
is written.

>> A point about the macros is that they are different than regular C
>> code, and because of that an added point of complexity / confusion.
>
> And added capabilities.

OK.

>> So a new programmer wouldn't have to learn macros in a variant of
>> C that drops that support.  And another template language could
>> be used for simple or not so simple substitutions.
>
> C already has a template language, the preprocessor.  What is the
> advantage of replacing that with a *different* template language?
>
> Even if you decide to do that, there's no real need to incorporate it
> into the language.  Tools that generate C code are already quite common,
> and can be invoked automatically by any build system.

Well, the way I see it, macros have three main uses; one is compile-time
defines, checks and so on, the other is that they can guarantee "inline-
like" behavior of code, and the third that for example a text string
can be defined once and used in different places.

Points one and two can be handled by the compiler, while somewhat simple
search and replace features might be something a developer wants to
have.

I have some experience with (X)HTML/CSS/JS templating systems, where a
lot is generated on the fly, and it is a very useful feature to have.

-Morten

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

#68768

On 08/31/2015 01:24 PM, Morten W. Petersen wrote:
> On 23.08.2015 23:27, Keith Thompson wrote:
>> "Morten W. Petersen" <morphex@gmail.com> writes:
> [...]
>>> Are there any cases for macros where they couldn't be replaced by
>>> functions?  Like it would be many more lines of code to do something
>>> similar in C code.
>>
>> I'm probably misunderstanding the question, because the obvious answer
>> is that you've just seen an example of a macro that cannot be replaced
>> by a function, inline or otherwise.  (Conceivably you could write an
>> inline function that takes a function pointer as an argument, with the
>> function acting as the body of the loop -- but the function would have
>> to be defined separately, and its body would not be in the scope of the
>> loop.)
> 
> OK.  I still don't see any "magic" that can't be replaced by simple
> C (inline) functions or some trivial alterations of how the program
> is written.

We're going in circles. Bart gave you an example of a macro that cannot
be replaced by a simple C (inline) function, and asked how you would
replace it. You responded by asking "Can't this be replaced by an inline
function?" You were told quite firmly that it can't be. You responded
with the text given above. If you're so convinced that it can be
replaced, it's long past the point where you should have shown how you
think it could be done. You should have done so instead of saying "Can't
this be replaced by an inline function". Showing the replacement
function would have been a much better argument.

Bart's macro is not a particularly good example - its a macro I would
NOT recommend using. But it makes use of features of C's preprocessing
language which are also used in more reasonable macros, that render them
equally impossible to replace.

Ben Bacarrisse has also provided an example:
  #define OP_(name) { opcode_ ## name, #name, op_func_ ## name },

Please - either provide non-macro replacements for these macros, or
concede that they cannot be replaced.

At this point, I'd be equally astonished at either result - I expect
you'll do something else entirely.
-- 
James Kuyper

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

#68769

On 31.08.2015 19:53, James Kuyper wrote:
> On 08/31/2015 01:24 PM, Morten W. Petersen wrote:
>> On 23.08.2015 23:27, Keith Thompson wrote:
>>> "Morten W. Petersen" <morphex@gmail.com> writes:
>> [...]
>>>> Are there any cases for macros where they couldn't be replaced by
>>>> functions?  Like it would be many more lines of code to do something
>>>> similar in C code.
>>>
>>> I'm probably misunderstanding the question, because the obvious answer
>>> is that you've just seen an example of a macro that cannot be replaced
>>> by a function, inline or otherwise.  (Conceivably you could write an
>>> inline function that takes a function pointer as an argument, with the
>>> function acting as the body of the loop -- but the function would have
>>> to be defined separately, and its body would not be in the scope of the
>>> loop.)
>>
>> OK.  I still don't see any "magic" that can't be replaced by simple
>> C (inline) functions or some trivial alterations of how the program
>> is written.
>
> We're going in circles. Bart gave you an example of a macro that cannot
> be replaced by a simple C (inline) function, and asked how you would
> replace it. You responded by asking "Can't this be replaced by an inline
> function?" You were told quite firmly that it can't be. You responded
> with the text given above. If you're so convinced that it can be
> replaced, it's long past the point where you should have shown how you
> think it could be done. You should have done so instead of saying "Can't
> this be replaced by an inline function". Showing the replacement
> function would have been a much better argument.

I guess I was waiting for someone else to show that it can be replaced,
my experience and thinking is that one can change the design of a piece
of source code and get the same result.

If someone can't do that, I'll do it myself, or try at least. :)

> Bart's macro is not a particularly good example - its a macro I would
> NOT recommend using. But it makes use of features of C's preprocessing
> language which are also used in more reasonable macros, that render them
> equally impossible to replace.
>
> Ben Bacarrisse has also provided an example:
>    #define OP_(name) { opcode_ ## name, #name, op_func_ ## name },
>
> Please - either provide non-macro replacements for these macros, or
> concede that they cannot be replaced.
>
> At this point, I'd be equally astonished at either result - I expect
> you'll do something else entirely.

OK I'll have another look at that to see what's going on.  I'm still
confident that changing habits a bit will make it possible to avoid
using macros and let the compiler optimize plain C code to the speed
that a macro would have been.

-Morten

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

#68770

On 31/08/2015 18:59, Morten W. Petersen wrote:
> On 31.08.2015 19:53, James Kuyper wrote:

>> Please - either provide non-macro replacements for these macros, or
>> concede that they cannot be replaced.
>>
>> At this point, I'd be equally astonished at either result - I expect
>> you'll do something else entirely.
>
> OK I'll have another look at that to see what's going on.  I'm still
> confident that changing habits a bit will make it possible to avoid
> using macros and let the compiler optimize plain C code to the speed
> that a macro would have been.

Obviously macros /can/ be done away with, by avoiding them or doing 
expansions by hand.

But if you're going to create a C compiler that doesn't support macros, 
then it won't be popular with people expecting to be able to write 
normal C, and you will have trouble compiling any existing code.

Why not just throw in a discrete macro processor? The output will be the 
plain C that you want.

-- 
Bartc

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

#68772

"Morten W. Petersen" <morphex@gmail.com> writes:
[...]
> OK I'll have another look at that to see what's going on.  I'm still
> confident that changing habits a bit will make it possible to avoid
> using macros and let the compiler optimize plain C code to the speed
> that a macro would have been.

Are you assuming that the only purpose of macros is to improve speed?

Macros can also provide expressiveness that can't be provided
without them.  You've seen several examples of that in this thread.

It's true that a lot of things that have previously been implemented
as macros can reasonably be replaced by inline functions (which
C didn't have until C99) -- or by plain functions if performance
isn't really critical, or if the compiler can do its own inlining
without being told to.

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

#68776

On 08/31/2015 01:59 PM, Morten W. Petersen wrote:
> On 31.08.2015 19:53, James Kuyper wrote:
>> On 08/31/2015 01:24 PM, Morten W. Petersen wrote:
>>> On 23.08.2015 23:27, Keith Thompson wrote:
>>>> "Morten W. Petersen" <morphex@gmail.com> writes:
>>> [...]
>>>>> Are there any cases for macros where they couldn't be replaced by
>>>>> functions?  Like it would be many more lines of code to do something
>>>>> similar in C code.
>>>>
>>>> I'm probably misunderstanding the question, because the obvious answer
>>>> is that you've just seen an example of a macro that cannot be replaced
>>>> by a function, inline or otherwise.  (Conceivably you could write an
>>>> inline function that takes a function pointer as an argument, with the
>>>> function acting as the body of the loop -- but the function would have
>>>> to be defined separately, and its body would not be in the scope of the
>>>> loop.)
>>>
>>> OK.  I still don't see any "magic" that can't be replaced by simple
>>> C (inline) functions or some trivial alterations of how the program
>>> is written.
>>
>> We're going in circles. Bart gave you an example of a macro that cannot
>> be replaced by a simple C (inline) function, and asked how you would
>> replace it. You responded by asking "Can't this be replaced by an inline
>> function?" You were told quite firmly that it can't be. You responded
>> with the text given above. If you're so convinced that it can be
>> replaced, it's long past the point where you should have shown how you
>> think it could be done. You should have done so instead of saying "Can't
>> this be replaced by an inline function". Showing the replacement
>> function would have been a much better argument.
> 
> I guess I was waiting for someone else to show that it can be replaced,
> my experience and thinking is that one can change the design of a piece
> of source code and get the same result.
> 
> If someone can't do that, I'll do it myself, or try at least. :)
> 
>> Bart's macro is not a particularly good example - its a macro I would
>> NOT recommend using. But it makes use of features of C's preprocessing
>> language which are also used in more reasonable macros, that render them
>> equally impossible to replace.
>>
>> Ben Bacarrisse has also provided an example:
>>    #define OP_(name) { opcode_ ## name, #name, op_func_ ## name },
>>
>> Please - either provide non-macro replacements for these macros, or
>> concede that they cannot be replaced.
>>
>> At this point, I'd be equally astonished at either result - I expect
>> you'll do something else entirely.
> 
> OK I'll have another look at that to see what's going on.  I'm still
> confident that changing habits a bit will make it possible to avoid
> using macros and let the compiler optimize plain C code to the speed
> that a macro would have been.

A function-like macro can behave like a function, and if so, it will
often be without the overhead of an actual function call. When this is
the case, it's often (but not necessarily) the case that an inline
function call can do the same thing with better type safety - and since
it's inline "the same thing" includes "without the overhead of an actual
function call".

Macros also provide a mechanism for creating a named constant that
doesn't take up any actual space in the generated code if the constant
isn't used, which can be useful in header files. A const static object
initialized with that value provides greater type safety, and a decent
optimizer will probably optimize it away if not used (but not without
providing a warning message about an unused static variable - so this
isn't a perfect alternative to using a macro). C++ makes that
alternative more useful, by allowing a const object initialized with a
constant expression to qualify, itself, as a constant expression.

You seem to have absorbed those lessons, and think that they are the
entirety of what macros are about. They aren't - they're just two things
among many that macros can be used for. Speed is almost never the key
reason for using a macro. Macros provide features that can't be
duplicated by the post-processing part of the C language - as you will
find out the hard way when you try to figure out how to replace those
particular macros with non-macro code.

The division of C into a pre-processing language and a post-processing
language is less than ideal, and I wouldn't mind seeing a C-like
language that integrates the two parts more cleanly. But C as it
currently is would require a lot of modification to enable doing
entirely without macros.
-- 
James Kuyper

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

#68771

"Morten W. Petersen" <morphex@gmail.com> writes:
> On 23.08.2015 23:27, Keith Thompson wrote:
>> "Morten W. Petersen" <morphex@gmail.com> writes:
> [...]
>>> Are there any cases for macros where they couldn't be replaced by
>>> functions?  Like it would be many more lines of code to do something
>>> similar in C code.
>>
>> I'm probably misunderstanding the question, because the obvious answer
>> is that you've just seen an example of a macro that cannot be replaced
>> by a function, inline or otherwise.  (Conceivably you could write an
>> inline function that takes a function pointer as an argument, with the
>> function acting as the body of the loop -- but the function would have
>> to be defined separately, and its body would not be in the scope of the
>> loop.)
>
> OK.  I still don't see any "magic" that can't be replaced by simple
> C (inline) functions or some trivial alterations of how the program
> is written.

How would you implement offsetof() without using a macro?

offsetof (defined in <stddef>) takes two arguments, a type name and a
member name.  For example:

    struct foo {
        int x;
        int y;
    };

    offsetof(struct foo, x) == 0
    offsetof(struct foo, y) == sizeof (int) (most likely)

A member name is not an expression, so it can't be passed as an argument
to a function.

offsetof() cannot be implemented in portable C, which is part of the
reason each implementation is required to provide its own version.  Some
compilers use a compiler-specific intrinsic; others use code whose
behavior is undefined in general but works for that particular compiler.

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

#68774

On Monday, August 31, 2015 at 2:22:12 PM UTC-4, Keith Thompson wrote:
> How would you implement offsetof() without using a macro?
> 
> offsetof (defined in <stddef>) takes two arguments, a type name and a
> member name.  For example:
> 
>     struct foo {
>         int x;
>         int y;
>     };
> 
>     offsetof(struct foo, x) == 0
>     offsetof(struct foo, y) == sizeof (int) (most likely)

Pointer math:

    int lnOffsetX = (&foo.x - &foo);
    int lnOffsetY = (&foo.y - &foo);

> A member name is not an expression, so it can't be passed as an argument
> to a function.
> 
> offsetof() cannot be implemented in portable C, which is part of the
> reason each implementation is required to provide its own version.  Some
> compilers use a compiler-specific intrinsic; others use code whose
> behavior is undefined in general but works for that particular compiler.

As I understand it, the C standard does not allow pointer math ... so
my solution above would likely require specific compilers / extensions.
I believe this solution does work on Microsoft's compilers, and GCC for
x86 (at least if not other CPUs).

Best regards,
Rick C. Hodgin

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

#68797

On 31/08/15 21:18, Rick C. Hodgin wrote:
> On Monday, August 31, 2015 at 2:22:12 PM UTC-4, Keith Thompson wrote:
>> How would you implement offsetof() without using a macro?
>>
>> offsetof (defined in <stddef>) takes two arguments, a type name and a
>> member name.  For example:
>>
>>     struct foo {
>>         int x;
>>         int y;
>>     };
>>
>>     offsetof(struct foo, x) == 0
>>     offsetof(struct foo, y) == sizeof (int) (most likely)
> 
> Pointer math:
> 
>     int lnOffsetX = (&foo.x - &foo);
>     int lnOffsetY = (&foo.y - &foo);
> 

You would need casts to integer types here:

int lnOffsetX = ((uintptr_t) &foo.x - (uintptr_t) &foo);

Of course, that requires the existence of an object "foo" of the struct
type - while offsetoff works /without/ having any known object of that type.


Usually if there is no compiler-specific intrinsic or built-in,
offsetoff is implemented as something like this:

#define offsetof(TYPE, ELEMENT) ((size_t)&(((TYPE *)0)->ELEMENT))

(This is actually much the same as your pointer maths, with the missing
cast - it's just that we pretend that we have a object of type TYPE at
address 0.)

Technically, this is undefined behaviour (though it will work with most
compilers) - therefore compiles have to provide a method that they know
works for their compiler.


Anyway, the point how you would wrap this all up in a convenient
offsetof "thingy" if you didn't want to make offsetof as a macro.  The
answer, of course, is that you cannot do so with C - you cannot even do
it with C++.


>> A member name is not an expression, so it can't be passed as an argument
>> to a function.
>>
>> offsetof() cannot be implemented in portable C, which is part of the
>> reason each implementation is required to provide its own version.  Some
>> compilers use a compiler-specific intrinsic; others use code whose
>> behavior is undefined in general but works for that particular compiler.
> 
> As I understand it, the C standard does not allow pointer math ... so
> my solution above would likely require specific compilers / extensions.
> I believe this solution does work on Microsoft's compilers, and GCC for
> x86 (at least if not other CPUs).
> 
> Best regards,
> Rick C. Hodgin
> 

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

#68866

David Brown <david.brown@hesbynett.no> writes:
[...]
>> On Monday, August 31, 2015 at 2:22:12 PM UTC-4, Keith Thompson wrote:
>>> How would you implement offsetof() without using a macro?
>>>
>>> offsetof (defined in <stddef>) takes two arguments, a type name and a
>>> member name.  For example:
>>>
>>>     struct foo {
>>>         int x;
>>>         int y;
>>>     };
>>>
>>>     offsetof(struct foo, x) == 0
>>>     offsetof(struct foo, y) == sizeof (int) (most likely)
[...]
> You would need casts to integer types here:
>
> int lnOffsetX = ((uintptr_t) &foo.x - (uintptr_t) &foo);

No, that would not work portably.  It assumes that uintptr_t
exists, which is not guaranteed (there might not be any unsigned
integer type wide enough to hold a converted pointer value without
loss of information).  And it assumes that arithmetic on uintptr_t
corresponds to arithmetic on pointers, which also is not guaranteed
-- and I've worked on systems where it doesn't.

Casting to char rather than to uintptr_t would work, except that ...

> Of course, that requires the existence of an object "foo" of the struct
> type - while offsetoff works /without/ having any known object of that type.

[...]

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

#68922

On 01/09/15 17:12, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>>> On Monday, August 31, 2015 at 2:22:12 PM UTC-4, Keith Thompson wrote:
>>>> How would you implement offsetof() without using a macro?
>>>>
>>>> offsetof (defined in <stddef>) takes two arguments, a type name and a
>>>> member name.  For example:
>>>>
>>>>      struct foo {
>>>>          int x;
>>>>          int y;
>>>>      };
>>>>
>>>>      offsetof(struct foo, x) == 0
>>>>      offsetof(struct foo, y) == sizeof (int) (most likely)
> [...]
>> You would need casts to integer types here:
>>
>> int lnOffsetX = ((uintptr_t) &foo.x - (uintptr_t) &foo);
>
> No, that would not work portably.  It assumes that uintptr_t
> exists, which is not guaranteed (there might not be any unsigned
> integer type wide enough to hold a converted pointer value without
> loss of information).  And it assumes that arithmetic on uintptr_t
> corresponds to arithmetic on pointers, which also is not guaranteed
> -- and I've worked on systems where it doesn't.
>

I guess this is why the standards don't say how offsetof is to be 
defined, and leave it to the compiler implementer to find a way that 
works on /their/ system!

> Casting to char rather than to uintptr_t would work, except that ...
>
>> Of course, that requires the existence of an object "foo" of the struct
>> type - while offsetoff works /without/ having any known object of that type.
>
> [...]
>

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

#69684

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

> "Morten W.  Petersen" <morphex@gmail.com> writes:
>> On 23.08.2015 23:27, Keith Thompson wrote:
>>> "Morten W.  Petersen" <morphex@gmail.com> writes:
>>
>> [...]
>>
>>>> Are there any cases for macros where they couldn't be replaced by
>>>> functions?  Like it would be many more lines of code to do something
>>>> similar in C code.
>>>
>>> I'm probably misunderstanding the question, because the obvious answer
>>> is that you've just seen an example of a macro that cannot be replaced
>>> by a function, inline or otherwise.  (Conceivably you could write an
>>> inline function that takes a function pointer as an argument, with the
>>> function acting as the body of the loop -- but the function would have
>>> to be defined separately, and its body would not be in the scope of the
>>> loop.)
>>
>> OK.  I still don't see any "magic" that can't be replaced by simple
>> C (inline) functions or some trivial alterations of how the program
>> is written.
>
> How would you implement offsetof() without using a macro?
>
> offsetof (defined in <stddef>) takes two arguments, a type name and a
> member name.  For example:
>
>     struct foo {
>         int x;
>         int y;
>     };
>
>     offsetof(struct foo, x) == 0
>     offsetof(struct foo, y) == sizeof (int) (most likely)
>
> A member name is not an expression, so it can't be passed as an argument
> to a function.
>
> offsetof() cannot be implemented in portable C, which is part of
> the reason each implementation is required to provide its own
> version.  [snip elaboration]

Another reason is that offsetof() needs to be an integer constant
expression, which effectively requires the implementation to set
the form of the definition so that it can be one, since ordinary
integer constant expressions don't do the job.

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

#68153

On 23/08/15 15:08, Morten W. Petersen wrote:
> On 23.08.2015 14:35, Bartc wrote:
>> On 23/08/2015 13:27, Morten W. Petersen wrote:
>>> On 23.08.2015 14:03, Bartc wrote:
>>>> On 23/08/2015 11:55, Morten W. Petersen wrote:
>>>>> On 21.08.2015 17:27, Rick C. Hodgin wrote:
>>>>>> Morten W. Petersen came up with an idea for a configure() function
>>>>
>>>>>> I have created this thread to discuss the idea.  So far, I have had
>>>>>> the idea that there should be some new keywords added which allow
>>>>>> this ability to inject code programmatically when conifgure() is
>>>>>> pre-compiled and executed, before the rest of the C source code is
>>>>>> compiled.
>>>>
>>>>> Well, the point wasn't to add something to C as such, the point was
>>>>> that it should be possible to drop macros from a compiler, making
>>>>> for a
>>>>> slimmer variant of C.
>>>>>
>>>>> What I was thinking you were onto, was a hack if you can call it that,
>>>>> which enables C-style code to be used instead of macros.
>>>>>
>>>>> The idea of a configure() function is that it replaces macros, and
>>>>> should do so in a clean and simple way.
>>>>
>>>> How would it replace a macro like this:
>>>>
>>>> #define FOR(i,a,b) for(i=a; i<=b; ++i)
>>>>
>>>> (And at what stage do all FOR invocations in the source get expanded?)
>>>>
>>>> Macros with arguments are an important part of C. I don't think you can
>>>> remove them without replacing them with something that can do the same
>>>> things. And in the case of macros such as the above, I can't see the
>>>> definition looking much different, or being less effort to implement.
>>>
>>> Couldn't that be replaced by an inline function?
>>
>> Not this example, because it's not an expression, but a piece of syntax.
>> The invocation would be followed by {...}, a single statement; or ";".
>
> Are there any cases for macros where they couldn't be replaced by
> functions?  Like it would be many more lines of code to do something
> similar in C code.

It is certainly true that many macros from pre-C99 code would be 
replaceable with static inline functions in C99 code, and would be 
better written that way.  It is also certainly true that many simple 
#define'd macros are merely named literals, which could be replaced by 
static const data or enum constants.

But there are plenty of other uses of macros that are not nearly as easy 
to replace.  Some of them are complex - but sometimes tasks in 
programming /are/ complicated.  You can't avoid that, and it's okay if a 
rare and difficult task takes a bit of effort to get right.  One of the 
main reasons to use macros is to let you put the ugly stuff in one bit 
of a header somewhere, rather than in multiple places in the middle of 
source code when it is used.

Let me give you a couple of examples from a header that I use on many 
systems.  (I apologise in advance for any gcc'isms - I am sure they will 
be clear enough.)

In my embedded programming, it is sometimes necessary to access a 
variable in a volatile manner - even if it is not declared volatile 
itself.  Thus I have:

#define volatileAccess(v) *((volatile typeof((v)) *) &(v))

This lets me force an access to a variable "x" using 
"volatileAccess(x)", which is clear in the source code when it is used, 
and avoids the messy casting.  (IIRC, Linux has a similar macro, called 
ACCESS_ONCE.)


I make great use of static assertions in my code.  C11 has them as part 
of the language, but in pre-C11 code you need a macro if you want to use 
"static_assert(claim, warning)" syntax:


#define STATIC_ASSERT_NAME_(counter)   STATIC_ASSERT_NAME2_(counter)
#define STATIC_ASSERT_NAME2_(counter)  assertion_failed_at_##counter
#define static_assert(claim, warning) \
     typedef struct { \
         char STATIC_ASSERT_NAME_(__COUNTER__) [(claim) ? 2 : -2]; \
     } STATIC_ASSERT_NAME_(__COUNTER__)


Ugly?  Yes, indeed - in the definition.  But the usage is clear and 
simple.  And it can't be replaced by anything else in C, such as inline 
functions - you'd have to replace it with an equally ugly alternative 
pre-processor, or an even uglier "configure()" system.

>
> A point about the macros is that they are different than regular C
> code, and because of that an added point of complexity / confusion.
>
> So a new programmer wouldn't have to learn macros in a variant of
> C that drops that support.  And another template language could
> be used for simple or not so simple substitutions.
>
> -Morten

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

#68778

On 23.08.2015 23:13, David Brown wrote:
> On 23/08/15 15:08, Morten W. Petersen wrote:
[...]
>> Are there any cases for macros where they couldn't be replaced by
>> functions?  Like it would be many more lines of code to do something
>> similar in C code.
>
> It is certainly true that many macros from pre-C99 code would be
> replaceable with static inline functions in C99 code, and would be
> better written that way.  It is also certainly true that many simple
> #define'd macros are merely named literals, which could be replaced by
> static const data or enum constants.
>
> But there are plenty of other uses of macros that are not nearly as easy
> to replace.  Some of them are complex - but sometimes tasks in
> programming /are/ complicated.  You can't avoid that, and it's okay if a
> rare and difficult task takes a bit of effort to get right.  One of the
> main reasons to use macros is to let you put the ugly stuff in one bit
> of a header somewhere, rather than in multiple places in the middle of
> source code when it is used.
>
> Let me give you a couple of examples from a header that I use on many
> systems.  (I apologise in advance for any gcc'isms - I am sure they will
> be clear enough.)
>
> In my embedded programming, it is sometimes necessary to access a
> variable in a volatile manner - even if it is not declared volatile
> itself.  Thus I have:
>
> #define volatileAccess(v) *((volatile typeof((v)) *) &(v))
>
> This lets me force an access to a variable "x" using
> "volatileAccess(x)", which is clear in the source code when it is used,
> and avoids the messy casting.  (IIRC, Linux has a similar macro, called
> ACCESS_ONCE.)

OK.  If I understand this correctly, this is basically some syntax
sugar.

Wouldn't it be possible to say something like

inline function volatileAccess(type, variable) {
   return *((volatile type *) &(v))
}

And in the code that makes use of it say

type mytype = typeof(v)
result = volatileAccess(mytype, v)

?

> I make great use of static assertions in my code.  C11 has them as part
> of the language, but in pre-C11 code you need a macro if you want to use
> "static_assert(claim, warning)" syntax:
>
>
> #define STATIC_ASSERT_NAME_(counter)   STATIC_ASSERT_NAME2_(counter)
> #define STATIC_ASSERT_NAME2_(counter)  assertion_failed_at_##counter
> #define static_assert(claim, warning) \
>      typedef struct { \
>          char STATIC_ASSERT_NAME_(__COUNTER__) [(claim) ? 2 : -2]; \
>      } STATIC_ASSERT_NAME_(__COUNTER__)
>
>
> Ugly?  Yes, indeed - in the definition.  But the usage is clear and
> simple.  And it can't be replaced by anything else in C, such as inline
> functions - you'd have to replace it with an equally ugly alternative
> pre-processor, or an even uglier "configure()" system.

Well equally ugly is OK. :)

The point is again that macros and its syntax could be removed.

-Morten

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

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

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

csiph-web