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

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

What if pre-processor was moved to parser?

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

Contents

  What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-14 15:37 -0800
    Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-15 00:05 -0800
      Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-15 00:57 -0800
        Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-15 07:21 -0800
          Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-15 07:24 -0800
            Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-15 08:10 -0800
    Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 03:05 -0800
      Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-15 11:38 +0000
        Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 04:28 -0800
          Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-15 13:22 +0000
            Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 05:47 -0800
          Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 10:06 -0800
        Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 05:24 -0800
          Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-15 13:57 +0000
            Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-19 10:27 -0800
          Re: What if pre-processor was moved to parser? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-15 15:16 +0000
            Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 08:14 -0800
              Re: What if pre-processor was moved to parser? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-15 18:01 +0000
                Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-15 18:25 +0000
                  Re: What if pre-processor was moved to parser? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-15 19:14 +0000
                Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-15 10:25 -0800
                  Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-15 18:45 +0000
                    Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-15 20:03 +0100
          Re: What if pre-processor was moved to parser? jameskuyper@verizon.net - 2017-02-15 10:12 -0800
            Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-15 10:51 -0800
            Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 12:14 -0800
              Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-15 20:25 +0000
                Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 12:50 -0800
                  Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-16 11:50 +0000
                    Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-16 04:44 -0800
                      Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-16 05:28 -0800
                      Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-16 14:32 +0000
                        Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-16 09:13 -0800
                          Re: What if pre-processor was moved to parser? Keith Thompson <kst-u@mib.org> - 2017-02-16 10:38 -0800
                            Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-16 11:55 -0800
                              Re: What if pre-processor was moved to parser? Keith Thompson <kst-u@mib.org> - 2017-02-16 12:24 -0800
                              Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-16 21:32 +0100
                                Re: What if pre-processor was moved to parser? Keith Thompson <kst-u@mib.org> - 2017-02-16 12:55 -0800
                                  Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-16 22:41 +0100
                                    Re: What if pre-processor was moved to parser? Keith Thompson <kst-u@mib.org> - 2017-02-16 14:02 -0800
                                    Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-16 15:08 -0800
                                Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-16 13:32 -0800
                                  Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-17 21:19 +1300
                                    Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-17 12:01 +0100
                                      Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-17 09:16 -0800
                                        Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-17 18:55 +0100
                                      Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 08:07 +1300
                                        Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-17 20:12 +0100
                                          Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 11:04 +1300
                                            Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-17 22:38 +0000
                                              Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 11:47 +1300
                                              Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-17 14:55 -0800
                                                Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 12:11 +1300
                                                  Re: What if pre-processor was moved to parser? "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-02-17 15:26 -0800
                                                  Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-17 16:15 -0800
                                                    Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 13:22 +1300
                                                      Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-17 16:37 -0800
                                                        Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-18 11:57 +0100
                                                  Re: What if pre-processor was moved to parser? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-18 07:13 +0000
                                                    Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 20:26 +1300
                                                      Re: What if pre-processor was moved to parser? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-18 09:17 +0000
                                              Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-18 01:18 +0100
                                                Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 13:23 +1300
                                                  Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-18 01:45 +0100
                                                    Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 16:18 +1300
                                                      Re: What if pre-processor was moved to parser? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-18 07:19 +0000
                                                        Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-18 20:30 +1300
                                                          Re: What if pre-processor was moved to parser? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-18 09:18 +0000
                                                          Re: What if pre-processor was moved to parser? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-18 07:15 -0800
                                                          Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-24 09:24 -0800
                                                            Re: What if pre-processor was moved to parser? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-24 17:51 +0000
                                                              Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-24 10:08 -0700
                                                                Re: What if pre-processor was moved to parser? Richard Heathfield <rjh@cpax.org.uk> - 2017-04-24 18:58 +0100
                                                                  Re: What if pre-processor was moved to parser? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-04-26 05:03 +0000
                                                                  Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 11:21 -0700
                                                            Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-25 09:15 +1300
                                                              Re: What if pre-processor was moved to parser? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-24 17:29 -0800
                                                              Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-26 06:19 -0700
                                                                Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-26 16:04 +0200
                                                                Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-04-26 07:08 -0700
                                                                  Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-26 16:46 +0200
                                                                    Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-04-26 09:32 -0700
                                                                      Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-26 20:19 +0200
                                                                        Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-04-26 11:29 -0700
                                                                        Re: What if pre-processor was moved to parser? scott@slp53.sl.home (Scott Lurndal) - 2017-04-26 18:51 +0000
                                                                Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-04-27 09:32 +1200
                                                                  Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-04-27 11:01 +0200
                                                                    Re: What if pre-processor was moved to parser? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-04-27 02:23 -0700
                                                                      Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-04-27 21:31 +1200
                                                                        Re: What if pre-processor was moved to parser? Ike Naar <ike@iceland.freeshell.org> - 2017-04-27 16:15 +0000
                                                                          Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-04-27 09:35 -0700
                                                                            Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-28 15:12 +0200
                                                                          Re: What if pre-processor was moved to parser? Gareth Owen <gwowen@gmail.com> - 2017-04-27 19:13 +0100
                                                                      Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-04-27 11:37 +0200
                                                                      Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-27 15:18 +0200
                                                        Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-18 08:43 +0100
                                                          Re: What if pre-processor was moved to parser? Richard Heathfield <rjh@cpax.org.uk> - 2017-02-18 09:22 +0000
                                                        Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-18 09:44 -0800
                                                      Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-18 11:33 +0000
                                                        Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-18 13:25 +0100
                                                          Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-18 13:47 +0000
                                                            Re: What if pre-processor was moved to parser? Jean-Marc Bourguet <jm@bourguet.org> - 2017-02-18 15:23 +0100
                                                              Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-18 14:53 +0000
                                                            Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-18 16:56 +0000
                                                            Re: What if pre-processor was moved to parser? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-18 22:50 -0600
                                                              Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-19 09:45 +0100
                                                            Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-19 13:35 +0100
                                                          Re: What if pre-processor was moved to parser? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-02-18 11:24 -0500
                                                            Re: What if pre-processor was moved to parser? Robert Wessel <robertwessel2@yahoo.com> - 2017-02-18 22:48 -0600
                                                          Re: What if pre-processor was moved to parser? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-18 10:04 -0800
                                                            Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-19 17:12 +0100
                                                              Re: What if pre-processor was moved to parser? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-19 11:11 -0800
                                                                Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-19 21:14 +0100
                                                                  Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-19 21:22 +0100
                                                                    Re: What if pre-processor was moved to parser? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-19 12:33 -0800
                                                                  Re: What if pre-processor was moved to parser? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-19 12:31 -0800
                                                                    Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-19 13:14 -0800
                                                                      Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-19 14:50 -0800
                                                                        Re: What if pre-processor was moved to parser? fir <profesor.fir@gmail.com> - 2017-02-19 15:04 -0800
                                                                    Re: What if pre-processor was moved to parser? David Brown <david.brown@hesbynett.no> - 2017-02-20 10:13 +0100
                                                                  Re: What if pre-processor was moved to parser? Gareth Owen <gwowen@gmail.com> - 2017-02-19 21:09 +0000
                                    Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-23 15:32 -0800
                                      Re: What if pre-processor was moved to parser? Ian Collins <ian-news@hotmail.com> - 2017-02-24 12:44 +1300
                                  Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-19 21:04 -0800
                              Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-19 21:14 -0800
                            Re: What if pre-processor was moved to parser? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-02-16 14:48 -0800
                              Re: What if pre-processor was moved to parser? Keith Thompson <kst-u@mib.org> - 2017-02-16 15:46 -0800
                                Re: What if pre-processor was moved to parser? Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-23 16:16 -0800
                        Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-20 04:18 -0800
                          Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-20 06:47 -0800
                            Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-20 09:50 -0800
                              Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-21 04:33 -0800
                                Re: What if pre-processor was moved to parser? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-02-21 15:41 +0100
                                Re: What if pre-processor was moved to parser? supercat@casperkitty.com - 2017-02-21 09:39 -0800
                                  Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-21 09:59 -0800
                                    Re: What if pre-processor was moved to parser? TickleMe Elmo <tmelmosfire@gmail.com> - 2017-02-21 10:22 -0800
                          Re: What if pre-processor was moved to parser? BartC <bc@freeuk.com> - 2017-02-20 15:49 +0000
                            Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-20 09:43 -0800
              Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 12:31 -0800
                Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-16 03:33 -0800
              Re: What if pre-processor was moved to parser? jameskuyper@verizon.net - 2017-02-15 12:47 -0800
                Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 13:06 -0800
                  Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-02-15 13:15 -0800
    Re: What if pre-processor was moved to parser? "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-02-18 12:36 +0100
      Re: What if pre-processor was moved to parser? "Patrick.Schluter" <Patrick.Schluter@free.fr> - 2017-02-18 12:41 +0100
    Re: What if pre-processor was moved to parser? John Bode <jfbode1029@gmail.com> - 2017-04-26 09:42 -0700
      Re: What if pre-processor was moved to parser? Thiago Adams <thiago.adams@gmail.com> - 2017-04-26 09:58 -0700

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

#104231

David Brown <david.brown@hesbynett.no> writes:

> I suppose your justification for these claims is going to be found in
> the usual places, alongside your statistics proving your rule of
> three, rule of two, and so on.

Yes, and if you're interested in retrieving them I can refer you to a
qualified proctologist.

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

#104551

Ian Collins <ian-news@hotmail.com> writes:

> On 02/17/17 10:32 AM, supercat@casperkitty.com wrote:
>> On Thursday, February 16, 2017 at 2:32:48 PM UTC-6, David Brown wrote:
>>> Regarding access to POD members with no constructors or destructors, C++
>>> treats unions mostly like C89 - if you have a union of a float and an
>>> int, and assign to the float, you are not allowed to read out the
>>> representation as the int.  (In C89, this is implementation-defined
>>> behaviour - in C++, it is not discussed and therefore undefined.)  This
>>> is hardly surprising, since C++ effectively forked from C89, and the
>>> "type punning" feature of unions was not standardised until C99.
>>
>> Type punning, whether via pointers or unions, is crucial in some kinds of
>> programming, but not needed at all in others.
>
> One reason C++ is gaining std::variant (a type-safe union).

That's a non-sequitur.  Needing type punning is not a
reason to add std::variant.  Not needing type punning
is not a reason to add std::variant.  This looks like
an excuse to proselytize C++.

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

#104553

On 02/24/17 12:32 PM, Tim Rentsch wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>
>> On 02/17/17 10:32 AM, supercat@casperkitty.com wrote:
>>> On Thursday, February 16, 2017 at 2:32:48 PM UTC-6, David Brown wrote:
>>>> Regarding access to POD members with no constructors or destructors, C++
>>>> treats unions mostly like C89 - if you have a union of a float and an
>>>> int, and assign to the float, you are not allowed to read out the
>>>> representation as the int.  (In C89, this is implementation-defined
>>>> behaviour - in C++, it is not discussed and therefore undefined.)  This
>>>> is hardly surprising, since C++ effectively forked from C89, and the
>>>> "type punning" feature of unions was not standardised until C99.
>>>
>>> Type punning, whether via pointers or unions, is crucial in some kinds of
>>> programming, but not needed at all in others.
>>
>> One reason C++ is gaining std::variant (a type-safe union).
>
> That's a non-sequitur.  Needing type punning is not a
> reason to add std::variant.  Not needing type punning
> is not a reason to add std::variant.  This looks like
> an excuse to proselytize C++.

Seeing as you view everything I post is either glib or proselytising 
C++, I may as well quite while I'm ahead....

-- 
Ian

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

#104252

supercat@casperkitty.com writes:

> Neither the C Standard nor the C++ Standard requires compilers
> to generate bogus code in cases where [...]

If the relevant standard required certain code be generated in
some such case, then that code wouldn't be bogus would it?  :)

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

#104253

supercat@casperkitty.com writes:

> On Thursday, February 16, 2017 at 12:37:43 PM UTC-6, Keith Thompson wrote:
>> supercat writes:
>> [...]
>>> The ability to compile a C program as C++ is only useful if the resulting
>>> program will run with known semantics.  There are some constructs which
>>> have defined behavior in C but have no convenient direct equivalent in C++.
>>
>> For example?
>
> I'm not a C++ expert by any means, but by my understanding it
> requires that after one union member is used, any attempt to use
> another member without first using placement new yields UB. [...]

I believe your understanding is mistaken.  Placement new is not
needed when the types involved are regular C data types.  When
the types involved have non-trivial constructors or destructors
that's a different story, but not when the types are regular C
types.

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

#104042

On 2/16/2017 10:38 AM, Keith Thompson wrote:
> supercat@casperkitty.com writes:
> [...]
>> The ability to compile a C program as C++ is only useful if the resulting
>> program will run with known semantics.  There are some constructs which
>> have defined behavior in C but have no convenient direct equivalent in C++.
>
> For example?
>
> [...]

#include <stdio.h>

void foo(void) { printf("foo\n"); }
void bar(int a) { printf("bar %d\n", a); }
void baz(int x, int y) { printf("baz %d %d\n", x, y); };

int main()
{
   void (*const a[3])() = { foo, bar, baz };
   a[0]();
   a[1](42);
   a[2](4, 2);
}

Although, if I remember correctly, C is planning to obsolete the 
"flexible" '()' parameter list.

-- 
Best regards,
Andrey Tarasevich

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

#104046

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> On 2/16/2017 10:38 AM, Keith Thompson wrote:
>> supercat@casperkitty.com writes:
>> [...]
>>> The ability to compile a C program as C++ is only useful if the resulting
>>> program will run with known semantics.  There are some constructs which
>>> have defined behavior in C but have no convenient direct equivalent in C++.
>>
>> For example?
>>
>> [...]
>
> #include <stdio.h>
>
> void foo(void) { printf("foo\n"); }
> void bar(int a) { printf("bar %d\n", a); }
> void baz(int x, int y) { printf("baz %d %d\n", x, y); };
>
> int main()
> {
>    void (*const a[3])() = { foo, bar, baz };
>    a[0]();
>    a[1](42);
>    a[2](4, 2);
> }
>
> Although, if I remember correctly, C is planning to obsolete the 
> "flexible" '()' parameter list.

Parameter lists using () have be "obsolescent" since C89/C90, and the
C99 rationale explicitly warns that they're likely to be removed from a
future standard aware of any plans by the committee to actually do so.

It is possible to do the equivalent without using old-style function
declarations.  I won't claim that it's particularly convenient.

    #include <stdio.h>
    
    void foo(void) { printf("foo\n"); }
    void bar(int a) { printf("bar %d\n", a); }
    void baz(int x, int y) { printf("baz %d %d\n", x, y); }
    
    int main(void) {
        typedef void (func0)(void);
        typedef void (func1)(int);
        typedef void (func2)(int, int);
        func0 *const a[] = { (func0*)foo, (func0*)bar, (func0*)baz };
        ((func0*)a[0])();
        ((func1*)a[1])(42);
        ((func2*)a[2])(4, 2);
    }

Some might prefer to define typedefs for function pointer types rather
than function types.  You could also do the whole thing without
typedefs, but IMHO they aid in readability.

I used `void()(void)` as a "generic" function type, which happens to
match the type of foo().  That might be error-prone in some cases.  An
alternative is to define an otherwise unused struct type and define your
"generic" function type to take or return a value of that type, so that
all uses of the generic function type require a pointer cast.

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

#104557

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

> Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
>> On 2/16/2017 10:38 AM, Keith Thompson wrote:
>>> supercat@casperkitty.com writes:
>>> [...]
>>>> The ability to compile a C program as C++ is only useful if the
>>>> resulting program will run with known semantics.  There are
>>>> some constructs which have defined behavior in C but have no
>>>> convenient direct equivalent in C++.
>>>
>>> For example?
>>>
>>> [...]
>>
>> #include <stdio.h>
>>
>> void foo(void) { printf("foo\n"); }
>> void bar(int a) { printf("bar %d\n", a); }
>> void baz(int x, int y) { printf("baz %d %d\n", x, y); };
>>
>> int main()
>> {
>>    void (*const a[3])() = { foo, bar, baz };
>>    a[0]();
>>    a[1](42);
>>    a[2](4, 2);
>> }
>>
>> Although, if I remember correctly, C is planning to obsolete the
>> "flexible" '()' parameter list.
>
> Parameter lists using () have be "obsolescent" since C89/C90, and
> the C99 rationale explicitly warns that they're likely to be
> removed from a future standard aware of any plans by the committee
> to actually do so.  [...]

No it does not.  What the C99 rationale does say is this:

  "The characterization as obsolescent of the use of the "old style"
   function declarations and definitions, that is, the traditional
   style not using prototypes, signals the Committee's intent that
   the new prototype style should eventually replace the old style.

   The case for the prototype style is presented in 6.5.2.2 and
   6.7.5.3.  The gist of this case is that the new syntax addresses
   some of the most glaring weaknesses of the language defined in K&R,
   that the new style is superior to the old style on every count.

   It was obviously out of the question to remove syntax used in the
   overwhelming majority of extant C code, so the Standard specifies
   two ways of writing function declarations and function
   definitions.  Characterizing the old style as obsolescent is meant
   to discourage its use and to serve as a strong endorsement by the
   Committee of the new style.  It confidently expects that approval
   and adoption of the prototype style will make it feasible for some
   future C Standard to remove the old style syntax."

A few comments are in order.

The word "style" in the first paragraph appears to be meant as
"usage" (ie, as opposed to language definition).

The quoted passage refers to function declarations and definitions,
not to function types in general.

The word "likely" is not used.

The final sentence, talking about the future, does not say old style
parameter lists are (even just probably) going to be removed, only
that it is expected that it will be feasible to remove them.  That
is an important distinction.  (And apparently it isn't feasible even
yet, 27 years later.)

Last but not least, note the important last word "syntax".  What
is being discussed is the syntactic forms involved.  The comments
do not address the deeper questions about semantic capability.

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

#104260

On Thursday, February 16, 2017 at 12:32:20 PM UTC-2, Bart wrote:
[...]
> So you can go through programs and look at how macros can be eliminated. 
> For new code at least, because you need to support existing code.
> 
> If your intention is to enforce macro usage guidelines, a bit like 
> MISRA, to make it easier to analyse code, then that's simpler in that 
> you don't need to create a new language!


A new language is not necessary.
New constrains can be added optionally in existing code.

Everything can be experimented with no changes in the C 
standard for a long period because it is only compiler 
settings.


For instance, if #if was moved to parser, then It must
be defined to appear in some places.

The problem, is probably to find consensus.

Who does code like this?

int 
#ifdef NAME_I
i
#define X 1
#else
y
#endif
;


I would suggest that #if/#ifdef/#error/#define/#undef cannot 
be used in the middle of declarations/expressions.

I don't believe this kind of rule will make the language 
complicated for the users because they will only notice the
difference in a day they try to do something not allowed.

(Many young programmers didn't realized at begging 
that 
#define X 1 
is something external to the language.)

They can just write the code in a different way and the 
compiler will be happy. 
Not only this. The code is also compatible with very old 
compilers.
The 100% compatibility is only required when you want to use 
some existing library that didn't agree with the rules.
For that reason, the compiler must switch to "classic-preprocessor" 
when including some file.

Some other points may be controversy.
Can #include/#define/#undef be used inside function scope?

int main()
{
  #include <file1.h>
  #define X 1
}


The parser could be very friendly with existing code, 
allowing everything. But I think this is not the 
objective. Even if it was, I think this works better than
the "blind" preprocessor.


The rules for the expansion are something that I am not 
ready to define and probably it's something we need to 
experiment and see.

I don't know if during all the expansions the rules should be 
applied or if at some point the expansion can be incorrect and then
at next expansion correct again. (maybe use of ## #)

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

#104262

On Monday, February 20, 2017 at 6:19:07 AM UTC-6, Thiago Adams wrote:
> Some other points may be controversy.
> Can #include/#define/#undef be used inside function scope?
> 
> int main()
> {
>   #include <file1.h>
>   #define X 1
> }
> 
> 
> The parser could be very friendly with existing code, 
> allowing everything. But I think this is not the 
> objective. Even if it was, I think this works better than
> the "blind" preprocessor.

There are certainly times when that can be useful, especially when the file
in question is machine-generated.  On the other hand, it would probably be
reasonable to say that a #include file that begins within a lexical context
must end within that same context.  So one could have

    int foo[4] = {
    #include "foo.i"
    };

if foo.i held

   1,2,3,4

or even

    int version = 
    #include "version_number.i"
    ;

if version_number.i held

   1
   +1
   +1
   +1

[The latter allows auto-incrementing sequential version numbers to be made
with minimal shell-scripting abilities that should work with tools present
on a variety of systems, not just Unix].

There are far fewer situations were it would be useful for a context to start
outside a #include file and end within it.  Such things might occasionally be
useful, but it may be desirable to disable such constructs by default (a
conforming implementation need not "default" to conforming mode, provided that
it documents what is necessary to make it behave in a conforming mode).

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

#104279

On Monday, February 20, 2017 at 11:47:52 AM UTC-3, supe...@casperkitty.com wrote:
> On Monday, February 20, 2017 at 6:19:07 AM UTC-6, Thiago Adams wrote:
> > Some other points may be controversy.
> > Can #include/#define/#undef be used inside function scope?
> > 
> > int main()
> > {
> >   #include <file1.h>
> >   #define X 1
> > }
> > 
> > 
> > The parser could be very friendly with existing code, 
> > allowing everything. But I think this is not the 
> > objective. Even if it was, I think this works better than
> > the "blind" preprocessor.
> 
> There are certainly times when that can be useful, especially when the file
> in question is machine-generated.  On the other hand, it would probably be
> reasonable to say that a #include file that begins within a lexical context
> must end within that same context.  So one could have
> 
>     int foo[4] = {
>     #include "foo.i"
>     };
> 
> if foo.i held
> 
>    1,2,3,4
> 
> or even
> 
>     int version = 
>     #include "version_number.i"
>     ;
> 
> if version_number.i held
> 
>    1
>    +1
>    +1
>    +1
> 
> [The latter allows auto-incrementing sequential version numbers to be made
> with minimal shell-scripting abilities that should work with tools present
> on a variety of systems, not just Unix].
> 
> There are far fewer situations were it would be useful for a context to start
> outside a #include file and end within it.  Such things might occasionally be
> useful, but it may be desirable to disable such constructs by default (a
> conforming implementation need not "default" to conforming mode, provided that
> it documents what is necessary to make it behave in a conforming mode).


For versioning I do:

version.h

#define VERSION 1.1

and the build recreates this file.

then 

#include "version.h"

int version = VERSION;

--
The best "new rules" for expansion would be the ones that
have an workaround. This workaround needs to be compatible with 
old rules (that are basically,  everything is allowed).
If no workaround is found then It can be hard to remove.

We have two worlds. One is good because everything is allowed. 
At the same time, a very few refactoring tools exist after decades
of c language.

Having c'-source to c-source is a good thing because the language
could experiment more without to add something on the standard.

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

#104312

On Monday, February 20, 2017 at 2:51:00 PM UTC-3, Thiago Adams wrote:
[...]
> The best "new rules" for expansion would be the ones that
> have an workaround. This workaround needs to be compatible with 
> old rules (that are basically,  everything is allowed).
> If no workaround is found then It can be hard to remove.


Do you have some guidelines for preprocessor usage?

There are some classical guidelines like put (arg) around your arguments, 
or use do { } while (0);
Use UPPERCASE.
Use inline function when possible.

In general I found very few recommendations on google.

I found one very interesting:

https://www.gnu.org/prep/standards/standards.html

 3.5 Conditional Compilation

"
When supporting configuration options already known when building your program we prefer using if (... ) over conditional compilation, as in the former case the compiler is able to perform more extensive checking of all possible code paths.

For example, please write

  if (HAS_FOO)
    ...
  else
    ...
instead of:

  #ifdef HAS_FOO
    ...
  #else
    ...
  #endif
A modern compiler such as GCC will generate exactly the same code in both cases, and we have been using similar techniques with good success in several projects. Of course, the former method assumes that HAS_FOO is defined as either 0 or 1.

While this is not a silver bullet solving all portability problems, and is not always appropriate, following this policy would have saved GCC developers many hours, or even days, per year.

In the case of function-like macros like REVERSIBLE_CC_MODE in GCC which cannot be simply used in if (...) statements, there is an easy workaround. Simply introduce another macro HAS_REVERSIBLE_CC_MODE as in the following example:

  #ifdef REVERSIBLE_CC_MODE
  #define HAS_REVERSIBLE_CC_MODE 1
  #else
  #define HAS_REVERSIBLE_CC_MODE 0
  #endif
"

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

#104314

On Tue, 21 Feb 2017 04:33:52 -0800 (PST)
Thiago Adams <thiago.adams@gmail.com> wrote:

> I found one very interesting:
> 
> https://www.gnu.org/prep/standards/standards.html

These rules are only relevant if you consider contributing to any GNU project
to bring consistency to your code. In other cases, you should better define
yours which you feel comfortable with.

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

#104322

On Tuesday, February 21, 2017 at 6:34:13 AM UTC-6, Thiago Adams wrote:
> I found one very interesting:
> 
> https://www.gnu.org/prep/standards/standards.html
> 
>  3.5 Conditional Compilation
> 
> "
> When supporting configuration options already known when building your program we prefer using if (... ) over conditional compilation, as in the former case the compiler is able to perform more extensive checking of all possible code paths.
> 
> For example, please write
> 
>   if (HAS_FOO)
>     ...
>   else
>     ...
> instead of:
> 
>   #ifdef HAS_FOO
>     ...
>   #else
>     ...
>   #endif
> A modern compiler such as GCC will generate exactly the same code in both cases, and we have been using similar techniques with good success in several projects. Of course, the former method assumes that HAS_FOO is defined as either 0 or 1.

There are times each pattern may be better than the other.  Most notably,
code which is disabled via "if()" will still be validated by the compiler in
ways that code which is disabled via "#ifdef" or "#if" won't.  If the code
should be able to compile without complaint whether or not it is enabled,
using "if()" rather than "#ifdef" will assure that.  If the program would
make use of a variable that exists on some platforms but not others,
however, then it will be necessary to use conditional compilation somewhere
to avoid having code for one system include references to a variable that
only exists on a different system.

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

#104324

On Tuesday, February 21, 2017 at 2:39:23 PM UTC-3, supe...@casperkitty.com wrote:
> On Tuesday, February 21, 2017 at 6:34:13 AM UTC-6, Thiago Adams wrote:
> > I found one very interesting:
> > 
> > https://www.gnu.org/prep/standards/standards.html
> > 
> >  3.5 Conditional Compilation
> > 
> > "
> > When supporting configuration options already known when building your program we prefer using if (... ) over conditional compilation, as in the former case the compiler is able to perform more extensive checking of all possible code paths.
> > 
> > For example, please write
> > 
> >   if (HAS_FOO)
> >     ...
> >   else
> >     ...
> > instead of:
> > 
> >   #ifdef HAS_FOO
> >     ...
> >   #else
> >     ...
> >   #endif
> > A modern compiler such as GCC will generate exactly the same code in both cases, and we have been using similar techniques with good success in several projects. Of course, the former method assumes that HAS_FOO is defined as either 0 or 1.
> 
> There are times each pattern may be better than the other.  Most notably,
> code which is disabled via "if()" will still be validated by the compiler in
> ways that code which is disabled via "#ifdef" or "#if" won't.  If the code
> should be able to compile without complaint whether or not it is enabled,
> using "if()" rather than "#ifdef" will assure that.  If the program would
> make use of a variable that exists on some platforms but not others,
> however, then it will be necessary to use conditional compilation somewhere
> to avoid having code for one system include references to a variable that
> only exists on a different system.

I think this limitation will reduce the use of 'if' a lot. 
This is the first time I see this advice, maybe because 
it is very unlikely to help in real cases.

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

#104326

On Tuesday, 21 February 2017 10:59:23 UTC-7, Thiago Adams  wrote:
> On Tuesday, February 21, 2017 at 2:39:23 PM UTC-3, supe...@casperkitty.com wrote:
> > On Tuesday, February 21, 2017 at 6:34:13 AM UTC-6, Thiago Adams wrote:
> > > I found one very interesting:
> > > 
> > > https://www.gnu.org/prep/standards/standards.html
> > > 
> > >  3.5 Conditional Compilation
> > > 
> > > "
> > > When supporting configuration options already known when building your program we prefer using if (... ) over conditional compilation, as in the former case the compiler is able to perform more extensive checking of all possible code paths.
> > > 
> > > For example, please write
> > > 
> > >   if (HAS_FOO)
> > >     ...
> > >   else
> > >     ...
> > > instead of:
> > > 
> > >   #ifdef HAS_FOO
> > >     ...
> > >   #else
> > >     ...
> > >   #endif
> > > A modern compiler such as GCC will generate exactly the same code in both cases, and we have been using similar techniques with good success in several projects. Of course, the former method assumes that HAS_FOO is defined as either 0 or 1.
> > 
> > There are times each pattern may be better than the other.  Most notably,
> > code which is disabled via "if()" will still be validated by the compiler in
> > ways that code which is disabled via "#ifdef" or "#if" won't.  If the code
> > should be able to compile without complaint whether or not it is enabled,
> > using "if()" rather than "#ifdef" will assure that.  If the program would
> > make use of a variable that exists on some platforms but not others,
> > however, then it will be necessary to use conditional compilation somewhere
> > to avoid having code for one system include references to a variable that
> > only exists on a different system.
> 
> I think this limitation will reduce the use of 'if' a lot. 
> This is the first time I see this advice, maybe because 
> it is very unlikely to help in real cases.

Another Snit sock.

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

#104266

On 20/02/2017 12:18, Thiago Adams wrote:
> On Thursday, February 16, 2017 at 12:32:20 PM UTC-2, Bart wrote:
> [...]
>> So you can go through programs and look at how macros can be eliminated.
>> For new code at least, because you need to support existing code.
>>
>> If your intention is to enforce macro usage guidelines, a bit like
>> MISRA, to make it easier to analyse code, then that's simpler in that
>> you don't need to create a new language!
>
>
> A new language is not necessary.
> New constrains can be added optionally in existing code.
>
> Everything can be experimented with no changes in the C
> standard for a long period because it is only compiler
> settings.
>
>
> For instance, if #if was moved to parser,

Actually, with some implementations (mine for example), preprocessing 
isn't a separate pass, but is done via the parser as it goes along. So a 
#define M and an invocation of M can be done even when it's 
half-finished parsing a module and deep inside a statement.

But it's usually done transparently: the parser requests the next token, 
but if that is # (followed by define), or a macro name M, then that is 
all dealt with before the first of the resulting set of tokens is 
delivered to the parser.

I guess you're talking about the parser detecting these things directly, 
or at least, # directives (doing macro expansion is heavy).

I think that is possible, but then #define would need to be just another 
declaration, and #if...#endif would be just another statement (that can 
contain declarations and statements, or possibly nothing if the contents 
need to be discarded due to a false branch).

The big problem is compatibility. Because you propose the same set of # 
directives, how do the tokeniser and parser know which one is to process 
a directive? (I think you gave an example of how; that's the one I 
couldn't follow! But that maybe others can't either.)

Because existing code will exist that will use preprocessing features in 
ways that cannot be duplicated in the parser:

> The 100% compatibility is only required when you want to use
> some existing library that didn't agree with the rules.
> For that reason, the compiler must switch to "classic-preprocessor"
> when including some file.

> Some other points may be controversy.
> Can #include/#define/#undef be used inside function scope?

If you're not changing language, then #define creates file-scope names, 
wherever it is declared. That's why an alternative (not a replacement) 
that creates names with conventional scope is attractive.


> int main()
> {
>   #include <file1.h>
>   #define X 1
> }

Yes, it can; I use it myself. But I wouldn't use it for headers.

And that is the problem: #include is used for shared headers (in the 
absence of any other mechanism to do import-like things), and for 
incorporating arbitrary bits of code. Example I used only yesterday:

int getchar(void);
void recordstat(int);
#define EOF -1

int main(void) {
int index,c;
char buffer[100];

#include "test"
}

'test' is auto-generated (code fragments duplicated so as to end up with 
a million lines of code, for performance testing). One of myriad uses 
(another is auto-generated tables). So arbitrary include is useful. But 
including stdio.h inside a block, while the language allows it, is not 
useful.

However, include files can be in <...> or "..." delimiters; perhaps that 
can be used to distinguish them.

>
> The parser could be very friendly with existing code,
> allowing everything. But I think this is not the
> objective. Even if it was, I think this works better than
> the "blind" preprocessor.
>
>
> The rules for the expansion are something that I am not
> ready to define and probably it's something we need to
> experiment and see.
>
> I don't know if during all the expansions the rules should be
> applied or if at some point the expansion can be incorrect and then
> at next expansion correct again. (maybe use of ## #)

As I understand it, either any include files, or perhaps some include 
files according to some criteria, will be preprocessed in the 'classic' 
method. Then there will be no '#' directives in the output, and no 
unexpanded macro names.

Anything else: top level source code (presumably, only new-style if 
making use of existing source) and maybe some new-style include files, 
will have new-style preprocessing: the tokeniser is simple, and passes 
through '#' directives to the parser. But those can only be used in 
restricted ways. Macro expansion however still needs to be done by the 
tokeniser; so it will need to 'see' macro definitions in the symbol table.

-- 
Bartc

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

#104278

On Monday, February 20, 2017 at 12:49:43 PM UTC-3, Bart wrote:
> On 20/02/2017 12:18, Thiago Adams wrote:
> > On Thursday, February 16, 2017 at 12:32:20 PM UTC-2, Bart wrote:
> > [...]
> >> So you can go through programs and look at how macros can be eliminated.
> >> For new code at least, because you need to support existing code.
> >>
> >> If your intention is to enforce macro usage guidelines, a bit like
> >> MISRA, to make it easier to analyse code, then that's simpler in that
> >> you don't need to create a new language!
> >
> >
> > A new language is not necessary.
> > New constrains can be added optionally in existing code.
> >
> > Everything can be experimented with no changes in the C
> > standard for a long period because it is only compiler
> > settings.
> >
> >
> > For instance, if #if was moved to parser,
> 
> Actually, with some implementations (mine for example), preprocessing 
> isn't a separate pass, but is done via the parser as it goes along. So a 
> #define M and an invocation of M can be done even when it's 
> half-finished parsing a module and deep inside a statement.
> 
> But it's usually done transparently: the parser requests the next token, 
> but if that is # (followed by define), or a macro name M, then that is 
> all dealt with before the first of the resulting set of tokens is 
> delivered to the parser.

In my parser, I did exactly like you described. The preprocessor is done
by the scanner.


> I guess you're talking about the parser detecting these things directly, 
> or at least, # directives (doing macro expansion is heavy).

Yes. If the scanner does the preprocessing, then you can set some flag
on this scanner "leave all tokens for me" or "do the preprocessor for me".


> I think that is possible, but then #define would need to be just another 
> declaration, and #if...#endif would be just another statement (that can 
> contain declarations and statements, or possibly nothing if the contents 
> need to be discarded due to a false branch).

Yes, something like this.

> The big problem is compatibility. Because you propose the same set of # 
> directives, how do the tokeniser and parser know which one is to process 
> a directive? (I think you gave an example of how; that's the one I 
> couldn't follow! But that maybe others can't either.)

The compiler can set for instance that all includes of "include dir" 
will be expanded using preprocessor.

So, for instance. file.c that includes stdio.h will be compiled 
with constrained preprocessor. In other words, the scanner that 
has preprocessor capability will output #if/#include etc because
the parser asked it for this. "leave preprocessor for me"

--file.c--
#include <stdio.h>
----------
At the beginning the scanner will output the #preprocessor tokens.
The parser will receive the #include. The parser will check "can 
#include token be used here?"
Then because <stdio.h>  is inside the "std includes" the parser
can turn on the preprocessor flag true on scanner.
So, during the include of stdio.h the parser will not see any
preprocessor token an all macros expansion will be done by the
scanner using normal rules.
When the stdio.h ends the preprocessor flag is turn off on the scanner.
So it will leave preprocessor tokens to the parser again.

The #defines from stdio.h will be alive inside file.c.
But some of then may not be expanded if they violates the macro
expansion rules.



> Because existing code will exist that will use preprocessing features in 
> ways that cannot be duplicated in the parser:
> 
> > The 100% compatibility is only required when you want to use
> > some existing library that didn't agree with the rules.
> > For that reason, the compiler must switch to "classic-preprocessor"
> > when including some file.
> 
> > Some other points may be controversy.
> > Can #include/#define/#undef be used inside function scope?
> 
> If you're not changing language, then #define creates file-scope names, 
> wherever it is declared. That's why an alternative (not a replacement) 
> that creates names with conventional scope is attractive.
> 

Scopes could be an alternative. 
But my suggestion was to leave the  #define to be decided 
only at expansion.
The #define will accept everything like today. The decision
and checks are done only at the expansion.

 
> > int main()
> > {
> >   #include <file1.h>
> >   #define X 1
> > }
> 
> Yes, it can; I use it myself. But I wouldn't use it for headers.
> 
> And that is the problem: #include is used for shared headers (in the 
> absence of any other mechanism to do import-like things), and for 
> incorporating arbitrary bits of code. Example I used only yesterday:
> 
> int getchar(void);
> void recordstat(int);
> #define EOF -1
> 
> int main(void) {
> int index,c;
> char buffer[100];
> 
> #include "test"
> }
> 
> 'test' is auto-generated (code fragments duplicated so as to end up with 
> a million lines of code, for performance testing). One of myriad uses 
> (another is auto-generated tables). So arbitrary include is useful. But 
> including stdio.h inside a block, while the language allows it, is not 
> useful.
> 
> However, include files can be in <...> or "..." delimiters; perhaps that 
> can be used to distinguish them.
> 
> >
> > The parser could be very friendly with existing code,
> > allowing everything. But I think this is not the
> > objective. Even if it was, I think this works better than
> > the "blind" preprocessor.
> >
> >
> > The rules for the expansion are something that I am not
> > ready to define and probably it's something we need to
> > experiment and see.
> >
> > I don't know if during all the expansions the rules should be
> > applied or if at some point the expansion can be incorrect and then
> > at next expansion correct again. (maybe use of ## #)
> 
> As I understand it, either any include files, or perhaps some include 
> files according to some criteria, will be preprocessed in the 'classic' 
> method. Then there will be no '#' directives in the output, and no 
> unexpanded macro names.

Yes.

> Anything else: top level source code (presumably, only new-style if 
> making use of existing source) and maybe some new-style include files, 
> will have new-style preprocessing: the tokeniser is simple, and passes 
> through '#' directives to the parser. But those can only be used in 
> restricted ways. Macro expansion however still needs to be done by the 
> tokeniser; so it will need to 'see' macro definitions in the symbol table.
> 

I didn't understand the last part:
"Macro expansion however still needs to be done by the 
> tokeniser; so it will need to 'see' macro definitions in the symbol table."

Macro expansion can be done by the parser, and it has access to 
#define symbols and everything.

Macro expansion also could be done by the scanner.

file.c

#define X 1 

//the file bellow is configured to used normal c preprocessor
//it can expand X inside it.
#include "some_file_i_want_normal_c_preprocessor.h" 

the #define of X was done by the parser. And it was expanded
by the scanner. (they can be mixed)


At the end of day, everything looks like an implementation detail.
But if the rules are completely free of rules then I believe the 
problem of preprocessor for refactoring tools and others is almost 
the same of today.

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

#103964

On Wednesday, February 15, 2017 at 6:14:22 PM UTC-2, Thiago Adams wrote:
[...]
> > That, on the other hand, makes it quite clear that you're proposing a new language. C', in which only a small subset of the features of C's preprocessing is supported. C' will, inherently, be incompatible with any existing C code that makes use of any of those features not supported by C', so I assume that you're reducing the importance of compatibility with existing C code?

If the preprocessor was completely disabled and re-recreated
as new grammar rules then It would be hard to archive 100% 
compatibility.
If we had 90%, probably the 10% remaining would be weird macros.

If the C language was moving into this direction, weird macros
could generate warnings preparing for the future.

#define X 1 + 2

//warning this macro can be invalid in future versions of C

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

#103990

On Wednesday, February 15, 2017 at 6:31:10 PM UTC-2, Thiago Adams wrote:
> On Wednesday, February 15, 2017 at 6:14:22 PM UTC-2, Thiago Adams wrote:
> [...]
> > > That, on the other hand, makes it quite clear that you're proposing a new language. C', in which only a small subset of the features of C's preprocessing is supported. C' will, inherently, be incompatible with any existing C code that makes use of any of those features not supported by C', so I assume that you're reducing the importance of compatibility with existing C code?

At the end, the idea is to move the preprocessor to parser with 
options.

The parser will understand #define, #include etc... and at the point
of expansion of some macro it will expand normally and after expansion it 
will check the rules if that expansion is allowed.

The compiler can have many flags.

One flag is - expand everything normally with preprocessor.
              Parser will not see preprocessor tokens. 

The other flags are used when the parser sees the preprocessor tokens 
and do the expansions.

For each rule we can have flags

 * Allow expansion of constant macro
 * Allow expansion of ( expression ) macro
 * Allow expansion of type-qualifier
 * Allow expansion of storage-class-specifier (etc)
 * Allow expansion of do statement while(0);
 etc..

When we compile a file.c you can pass the flags to the compiler.

file.c
#include <stdio.h>

But when the compiler see <stdio.h> it can automatically set flags
for include directories.(flag expand this header normally)

The include is like a macro-expansion of that file using some flags
for that expansion.

Sample of grammar for expansion:

MISRA C
"C macros shall only expand to a braced initialiser, a constant,
a string literal, a parenthesised expression, a type qualifier, a
storage class specifier, or a do-while-zero construct."

initializer:
 assignment-expression
 { initializer-list }
 { initializer-list , }
 macro-identifier that expands to initializer

primary-expression:
identifier
constant
string-literal
( expression )
generic-selection
macro-identifier that expand to ( expression ) or constant or string-literal


type-qualifier:
 const
 restrict
 volatile
 _Atomic
 macro-identifier that expands to const,  restrict, volatile or  _Atomic

storage-class-specifier:
 typedef
 extern
 static
 _Thread_local
 auto
 register
 macro-identifier that expand to  typedef, extern, static, _Thread_local, auto or  register


iteration-statement:
 while ( expression ) statement
 do statement while ( expression ) ;
 for ( expressionopt ; expressionopt ; expressionopt ) statement
 for ( declaration expressionopt ; expressionopt ) statement
 macro-identifier that expands to  do statement while ( 0 ) ;



The implementation of this expansion can be done in place with context.
For instance:

#define X(a) do a++; while (0)

int i = 0;
X(i);

The parser will see X at iteration-statement
Then it expand X(i). The result of the expansion is
"do i++; while (0)"
It can try to build a temporary AST node for this expansion
using this context (i).

Then the parser check the node if it matches the rules.
Also at the expansion it can show some compile error.

Some macros are incomplete

#define BEGIN do {
#define END } while(0);

BEGIN

END

Flags:

* Allow incomplete expansion at function scope
* Allow incomplete expansion at struct-union scope
* Allow incomplete expansion at global scope

etc..

The expansion flags could be by region:

#pragma push preprocessor rules 1, 54, 54

#pragma pop preprocessor 

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

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

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

csiph-web