Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #103912 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2017-02-14 15:37 -0800 |
| Last post | 2017-04-26 09:58 -0700 |
| Articles | 20 on this page of 147 — 26 participants |
Back to article view | Back to comp.lang.c
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 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-15 10:25 -0800 |
| Message-ID | <d776ae32-9945-49e3-9d9b-e03b85800a12@googlegroups.com> |
| In reply to | #103949 |
On Wednesday, February 15, 2017 at 12:01:46 PM UTC-6, Ben Bacarisse wrote: > Right. But my point is that if you restrict #define to permit only > certai forms, you can (and should) also restrict what it means. You can > simple say that after > > #define X 1 + 2 > > X means (1 + 2). And then you notice don't need the special line > oriented syntax and you can use a more comfortable syntax. Breaking away from line-oriented syntax would make it possible to have a macro change the meaning of local or global "preprocessor" symbols. I think there are advantages to having a language specified in such a way that doesn't make metaprogramming Turing-complete (which would make the question of whether a particular program could be compiled, undecidable) but still allows limited looping constructs. Without an ability to replace expressions with simple values, however, compilation could easily become very slow if repeated invocations of a macro yield 1, 1+(1), 1+(1+(1)), etc. rather than 1, 2, 3, etc.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-15 18:45 +0000 |
| Message-ID | <o827gg$88p$1@dont-email.me> |
| In reply to | #103954 |
On 15/02/2017 18:25, supercat@casperkitty.com wrote:
> On Wednesday, February 15, 2017 at 12:01:46 PM UTC-6, Ben Bacarisse wrote:
>> Right. But my point is that if you restrict #define to permit only
>> certai forms, you can (and should) also restrict what it means. You can
>> simple say that after
>>
>> #define X 1 + 2
>>
>> X means (1 + 2). And then you notice don't need the special line
>> oriented syntax and you can use a more comfortable syntax.
>
> Breaking away from line-oriented syntax would make it possible to have a
> macro change the meaning of local or global "preprocessor" symbols. I
> think there are advantages to having a language specified in such a way
> that doesn't make metaprogramming Turing-complete (which would make the
> question of whether a particular program could be compiled, undecidable)
> but still allows limited looping constructs. Without an ability to replace
> expressions with simple values, however, compilation could easily become
> very slow if repeated invocations of a macro yield 1, 1+(1), 1+(1+(1)),
> etc. rather than 1, 2, 3, etc.
>
This is a program that is very slow to compile because of heavy use of
macros:
http://pastebin.com/PfRbGHns
(Originally posted by BGB as part of gcc bug report, as gcc was taking
an inordinately long time to compile it. Although most of that was
dealing with the result of the preprocessing.)
This 1000-line file took gcc 1.5 seconds to preprocess (-E).
With my own cpp, preprocessing was up to 3 magnitudes slower than I
would have expected from a file of that size.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2017-02-15 20:03 +0100 |
| Message-ID | <20170215200333.390bcc8ba849a87680ddf22a@gmail.com> |
| In reply to | #103955 |
On Wed, 15 Feb 2017 18:45:16 +0000 BartC <bc@freeuk.com> wrote: > This is a program that is very slow to compile because of heavy use of > macros: > > http://pastebin.com/PfRbGHns Heavy use of C macros is a C bad use! > (Originally posted by BGB as part of gcc bug report, as gcc was taking > an inordinately long time to compile it. Although most of that was > dealing with the result of the preprocessing.) > > This 1000-line file took gcc 1.5 seconds to preprocess (-E). > > With my own cpp, preprocessing was up to 3 magnitudes slower than I > would have expected from a file of that size. > > -- > bartc Why people try to implement bad function-like macros when they can easily implement good C functions? It's like people implementing 3D engines or video codecs in Javascript... Once more, I'm not very fond of VeryLongIdentifiersThatBreakMyFingers. Good identifiers should be less than 10 characters with meaningful characters.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-02-15 10:12 -0800 |
| Message-ID | <8b49e198-86a5-45b4-ade7-a27ecb4f5e07@googlegroups.com> |
| In reply to | #103929 |
On Tuesday, February 14, 2017 at 6:37:48 PM UTC-5, Thiago Adams wrote: > I was wondering how to eliminate pre-processor > keeping compatibility with existing C code. Since there's essentially no feature of C pre-processing that hasn't already been used by existing code, if compatibility with existing C code is important to you, then it would seem you were proposing to implement all of those features, but to do so without having a distinct pre-processor step. In principle, that should be possible, though I don't know that there's any big advantage to be achieved by doing it that way. On Wednesday, February 15, 2017 at 8:24:34 AM UTC-5, Thiago Adams wrote: ... > Some samples to make the idea clear: > I will allow empty define, constant or constant-expression with () > > C' Grammar: > > define-declaration: > #define identifier > #define identifier constant > #define identifier ( constant-expression ) 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?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-15 10:51 -0800 |
| Message-ID | <f4e9aa28-9b27-4b7a-85dc-c242320d6f4f@googlegroups.com> |
| In reply to | #103952 |
On Wednesday, February 15, 2017 at 12:12:50 PM UTC-6, james...@verizon.net 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? IMHO, a good derived language should strive to ensure that outside of contrived scenarios, code which has meaning in the original language will either have the same meaning in the new language, or else it will fail compilation but be easily replaceable with code that would have the same meaning in both languages and be as good or better than the original code in the original language. For example, if I were designing a language I would distinguish between values which are derived from arithmetic expressions that might wrap or overflow, and values which are not, and I would forbid conversion of such values directly to larger types, *even with a cast operator*. Thus, given "uint32_t x,y; uint64_t z;" I would allow "x+=y; z=x;" but I would not allow "z=x+y;" nor even "z=(uint64_t)(x+y);". I would suggest that even in C, "z=(uint32_t)(x+y);" would be clearer and thus "better" than the forms without the uint32_t cast. Not only does the uint32_t cast help make it obvious what the code actually does, but more importantly *it shows what the author of the code is expecting it to do*. Adding the aforementioned rules would make the resulting language incompatible with some C programs, but the vast majority of such programs could readily be adapted to work with the new language without making them less suitable for use in C (the only situations I can see that might be problematic would involve macro constructs, and I doubt they'd post much difficulty outside of contrived scenarios).
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2017-02-15 12:14 -0800 |
| Message-ID | <d879efad-7e8b-44dd-aa5d-cab5950f7de2@googlegroups.com> |
| In reply to | #103952 |
On Wednesday, February 15, 2017 at 4:12:50 PM UTC-2, james...@verizon.net wrote:
> On Tuesday, February 14, 2017 at 6:37:48 PM UTC-5, Thiago Adams wrote:
> > I was wondering how to eliminate pre-processor
> > keeping compatibility with existing C code.
>
> Since there's essentially no feature of C pre-processing that hasn't already been used by existing code, if compatibility with existing C code is important to you, then it would seem you were proposing to implement all of those features, but to do so without having a distinct pre-processor step. In principle, that should be possible, though I don't know that there's any big advantage to be achieved by doing it that way.
>
> On Wednesday, February 15, 2017 at 8:24:34 AM UTC-5, Thiago Adams wrote:
> ...
> > Some samples to make the idea clear:
> > I will allow empty define, constant or constant-expression with ()
> >
> > C' Grammar:
> >
> > define-declaration:
> > #define identifier
> > #define identifier constant
> > #define identifier ( constant-expression )
>
> 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?
Yes. Exactly.
I want compatibility with existing code.
So, inside #include we are in normal mode.(as it is today)
---file.h---
#define INLINE inline
INLINE void F();
---
---file.c---
#include "file.h"
-----------------------
We can use #define without restriction (as it is today).
The parser (when parsing file.c) will enter inside the include
and it will see only preprocessed tokens:
inline void F();
(No macros here)
But, if you put a define outside:
---file.c---
#include "file.h"
#define X 1 + 2
-----------------------
Now this #defined is parsed with new grammar rules. (see alternative below)
The parser will not see any preprocessor tokens from file.h
but it still have in memory the #defines (original) created
inside file.h.
So the INLINE macro still present on the memory.
Now, if I try:
---file.c---
#include "file.h"
INLINE void f2();
-----------------------
This INLINE is macro created inside file.h
If this macro doesn't follow the grammar rules
(as it was defined inside file.c) I can generate
an error.
So, one option is instead of adding grammar rules for
#define, we could allow everything as it is today.
Then, at expansion we could apply the rules.
For instance:
--file.c--
#define X 1 + 2
#include "file2.h" //file 2 will see X as normal macro
int main()
{
//Now, only here, at expansion we will check the macro
//and complain
int i = 2 * X;
}
Again, what is the advantage?
I can rebuild file.c. (refactoring for instance)
The usage of macros inside file.c follow some
rules and it's safer.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-15 20:25 +0000 |
| Message-ID | <o82dcg$u62$1@dont-email.me> |
| In reply to | #103961 |
On 15/02/2017 20:14, Thiago Adams wrote: > On Wednesday, February 15, 2017 at 4:12:50 PM UTC-2, james...@verizon.net 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? > > Yes. Exactly. > I want compatibility with existing code. > > So, inside #include we are in normal mode.(as it is today) > > ---file.h--- > #define INLINE inline > > INLINE void F(); > --- > > ---file.c--- > #include "file.h" > ----------------------- > > We can use #define without restriction (as it is today). > The parser (when parsing file.c) will enter inside the include > and it will see only preprocessed tokens: > > inline void F(); > > (No macros here) > > > But, if you put a define outside: > > ---file.c--- > #include "file.h" > #define X 1 + 2 > ----------------------- You've already lost me. If someone sees a code fragment containing '#define', is that processed according to the old or new rules? What happens when people copy and paste across files, or just want to share code. It's too confusing. Why not use something different from '#' (I think @ is available), or change the directives, so #newdefine or #Define or whatever? -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2017-02-15 12:50 -0800 |
| Message-ID | <d771fe14-7515-422b-9759-1d2b947a941f@googlegroups.com> |
| In reply to | #103962 |
On Wednesday, February 15, 2017 at 6:25:42 PM UTC-2, Bart wrote:
> On 15/02/2017 20:14, Thiago Adams wrote:
> > On Wednesday, February 15, 2017 at 4:12:50 PM UTC-2, james...@verizon.net 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?
> >
> > Yes. Exactly.
> > I want compatibility with existing code.
> >
> > So, inside #include we are in normal mode.(as it is today)
> >
> > ---file.h---
> > #define INLINE inline
> >
> > INLINE void F();
> > ---
> >
> > ---file.c---
> > #include "file.h"
> > -----------------------
> >
> > We can use #define without restriction (as it is today).
> > The parser (when parsing file.c) will enter inside the include
> > and it will see only preprocessed tokens:
> >
> > inline void F();
> >
> > (No macros here)
> >
> >
> > But, if you put a define outside:
> >
> > ---file.c---
> > #include "file.h"
> > #define X 1 + 2
> > -----------------------
>
> You've already lost me.
>
> If someone sees a code fragment containing '#define', is that processed
> according to the old or new rules? What happens when people copy and
> paste across files, or just want to share code.
>
> It's too confusing.
>
> Why not use something different from '#' (I think @ is available), or
> change the directives, so #newdefine or #Define or whatever?
There are two options and I think this is
creating confusion.
1 - Preprocessor doesn't exist anymore.
Everything must follow new rules.
Some existing code will not compile.
2 - Preprocessor still working when inside the included files.
New rules are applied only at the translation unit outside the
include.
Here the description of 2:
The program starts parsing "file.c"
Let's say there is an option "-parse using new macro rules"
We have two files. (file.c and file.h)
---file.h---
#define INLINE inline
INLINE void F();
---
---file.c---
#include "file.h"
-----------------------
At the beginning we are parsing file.c.
We can see all tokens.
So the parser will see the token "#include".
When it see #include it enters in a "MACRO ON MODE".
So the parser will not see anymore any preprocessor
token #include, #define etc..
It will see only:
inline void F();
and then the parser of file.h finish.
We are again at the start state, and the parser can
see #include, #define.
The parsed macros from file.h still alive in memory.
There is a hasp map ["INLINE"] -> "inline"
#define INLINE inline
If you include another file for instance file2.h after file.h
it would see INLINE and it could expand INLINE because
inside the include we are in "MACRO ON MODE".
But if you try to expand the INLINE macro inside file.c
---file.c---
#include "file.h"
INLINE void f3(); // <- here
-----------------------
Then the INLINE macro must follow the rules for expansion.
The rules would be applied only at expansion inside .c file.
---------
For the option 1 the rules are applied everywhere.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-16 11:50 +0000 |
| Message-ID | <o843j2$i30$1@dont-email.me> |
| In reply to | #103966 |
On 15/02/2017 20:50, Thiago Adams wrote: > On Wednesday, February 15, 2017 at 6:25:42 PM UTC-2, Bart wrote: >> You've already lost me. >> >> If someone sees a code fragment containing '#define', is that processed >> according to the old or new rules? What happens when people copy and >> paste across files, or just want to share code. >> >> It's too confusing. >> >> Why not use something different from '#' (I think @ is available), or >> change the directives, so #newdefine or #Define or whatever? > > There are two options and I think this is > creating confusion. > > 1 - Preprocessor doesn't exist anymore. > Everything must follow new rules. > Some existing code will not compile. > > 2 - Preprocessor still working when inside the included files. > New rules are applied only at the translation unit outside the > include. > > Here the description of 2: > > > The program starts parsing "file.c" > Let's say there is an option "-parse using new macro rules" > > We have two files. (file.c and file.h) > > ---file.h--- > #define INLINE inline > > INLINE void F(); > --- > > ---file.c--- > #include "file.h" > ----------------------- > > At the beginning we are parsing file.c. > We can see all tokens. > > So the parser will see the token "#include". > > When it see #include it enters in a "MACRO ON MODE". > So the parser will not see anymore any preprocessor > token #include, #define etc.. > > It will see only: > > inline void F(); > > and then the parser of file.h finish. > > We are again at the start state, and the parser can > see #include, #define. > > The parsed macros from file.h still alive in memory. > > There is a hasp map ["INLINE"] -> "inline" > #define INLINE inline > > If you include another file for instance file2.h after file.h > it would see INLINE and it could expand INLINE because > inside the include we are in "MACRO ON MODE". > > > But if you try to expand the INLINE macro inside file.c > > ---file.c--- > #include "file.h" > > INLINE void f3(); // <- here > > ----------------------- > > Then the INLINE macro must follow the rules for expansion. > The rules would be applied only at expansion inside .c file. > > --------- > > For the option 1 the rules are applied everywhere. Sorry, but that the fact that you need all this explanation is not a good sign. (I tried to understand but my brain seems unwilling.) Compare that to this: #define X A B C // old rules .define Y D E F // new rules Do you see how much simpler it is to explain? And how much easier for someone to glance at a bit of code and know immediately, without any other context, whether it is interpreted under the old or new rules? (Actually you can't use ".define" because a normal "." can occur at the start of a line. "@" is maybe a better choice but I didn't like it. #Define is another option. Whatever it is, you need something to distinguish '#define' from '#define'!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2017-02-16 04:44 -0800 |
| Message-ID | <7cc856f7-997e-496d-8ebf-ba413cb89d75@googlegroups.com> |
| In reply to | #103995 |
On Thursday, February 16, 2017 at 9:50:48 AM UTC-2, Bart wrote:
[...]
> Sorry, but that the fact that you need all this explanation is not a
> good sign. (I tried to understand but my brain seems unwilling.) Compare
> that to this:
>
> #define X A B C // old rules
> .define Y D E F // new rules
>
> Do you see how much simpler it is to explain? And how much easier for
> someone to glance at a bit of code and know immediately, without any
> other context, whether it is interpreted under the old or new rules?
>
> (Actually you can't use ".define" because a normal "." can occur at the
> start of a line. "@" is maybe a better choice but I didn't like it.
> #Define is another option. Whatever it is, you need something to
> distinguish '#define' from '#define'!)
>
The explanation is big because is how it works.
The "manual" is much simpler:
- [ ] Use c preprocessor (all expansions are allowed)
- [X] Use parser-preprocessor
[X] Allow expansion of constants
[X] Allow expansion of do while()
..etc..
The idea is that the programmer will not notice the difference
in most cases.
There is no need for .define @define.
(
I created this confusion because at the begging I suggest
changing the grammar for #define. Then I realized that the rules
are better applied at expansion and the code is more compatible with C.
)
#define will allow everything (normally)
because the rules are checked at expansion.
I understand when you say that some C' language could have
a syntax for constants.
But, think the key for real and immediate use is to be very
compatible with C. Also for general success.
I think C++ is very successful because of this.
I not sure if any other language like D ou Rust will be more
used than C++ because C++ is easy to compile C and integrate with
Window, Android, Mac, Linux, embedded.
Also, C is interesting because it is simple. Adding new rules
can make it complicated.
C++ programmers will say "don't use macros!"
But many real programs are using macros in a safe way.
However, even in a program that is correct, there are potential problems.
Moving the pre-processor do parser will allow more checking.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2017-02-16 05:28 -0800 |
| Message-ID | <8e941107-9a18-4aaa-b61c-fea950b92911@googlegroups.com> |
| In reply to | #103998 |
On Thursday, February 16, 2017 at 10:44:34 AM UTC-2, Thiago Adams wrote:
> On Thursday, February 16, 2017 at 9:50:48 AM UTC-2, Bart wrote:
> [...]
>
> > Sorry, but that the fact that you need all this explanation is not a
> > good sign. (I tried to understand but my brain seems unwilling.) Compare
> > that to this:
> >
> > #define X A B C // old rules
> > .define Y D E F // new rules
> >
> > Do you see how much simpler it is to explain? And how much easier for
> > someone to glance at a bit of code and know immediately, without any
> > other context, whether it is interpreted under the old or new rules?
> >
> > (Actually you can't use ".define" because a normal "." can occur at the
> > start of a line. "@" is maybe a better choice but I didn't like it.
> > #Define is another option. Whatever it is, you need something to
> > distinguish '#define' from '#define'!)
> >
>
> The explanation is big because is how it works.
>
> The "manual" is much simpler:
>
> - [ ] Use c preprocessor (all expansions are allowed)
> - [X] Use parser-preprocessor
> [X] Allow expansion of constants
> [X] Allow expansion of do while()
> ..etc..
>
> The idea is that the programmer will not notice the difference
> in most cases.
>
> There is no need for .define @define.
>
> (
> I created this confusion because at the begging I suggest
> changing the grammar for #define. Then I realized that the rules
> are better applied at expansion and the code is more compatible with C.
> )
>
> #define will allow everything (normally)
> because the rules are checked at expansion.
One more sample: (from MISRA C)
/* The following are compliant */
#define PI 3.14159F /* Constant */
#define XSTAL 10000000 /* Constant */
#define CLOCK (XSTAL/16) /* Constant expression */
#define PLUS2(X) ((X) + 2) /* Macro expanding to expression */
#define STOR extern /* storage class specifier */
#define INIT(value){ (value), 0, 0} /* braced initialiser */
#define CAT (PI) /* parenthesised expression */
#define FILE_A "filename.h" /* string literal */
#define READ_TIME_32() \
do { \
DISABLE_INTERRUPTS (); \
time_now = (uint32_t)TIMER_HI << 16; \
time_now = time_now | (uint32_t)TIMER_LO; \
ENABLE_INTERRUPTS (); \
} while (0) /* example of do-while-zero */
/* the following are NOT compliant */
#define int32_t long /* use typedef instead */
#define STARTIF if( /* unbalanced () and language redefinition */
#define CAT PI /* non-parenthesised expression */
-------
Let's say:
/* The following are compliant */
#define PI 3.14159F /* Constant */
#define CAT (PI) /* parenthesised expression */
And I create a new macro X
#define X CAT
Now X is OK, not because I parsed "X CAT"
but because the expansion is (3.14159F).
The rule that can be applied at the #define
definition is a warning if the argument is not
inside parentheses.
A more sophisticated expansion could check the rules
during each expansion.
#define X 1 + 2
#define Y 2 * X
Here the checked expansion only at the end would be: 2 * 1 + 2
But if the rules were checked during expansion.
int i = Y; // 2 * X
// X is not a valid expansion
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-02-16 14:32 +0000 |
| Message-ID | <o84d1v$il5$1@dont-email.me> |
| In reply to | #103998 |
On 16/02/2017 12:44, Thiago Adams wrote:
> On Thursday, February 16, 2017 at 9:50:48 AM UTC-2, Bart wrote:
> But, think the key for real and immediate use is to be very
> compatible with C. Also for general success.
> I think C++ is very successful because of this.
I wonder why C doesn't just disappear then? As every C program, with
some tweaks as necessary, will compile as C++.
> I not sure if any other language like D ou Rust will be more
> used than C++ because C++ is easy to compile C and integrate with
> Window, Android, Mac, Linux, embedded.
>
> Also, C is interesting because it is simple. Adding new rules
> can make it complicated.
But C++ is complicated, and above you suggest that has not stopped it
being successful!
> C++ programmers will say "don't use macros!"
> But many real programs are using macros in a safe way.
Most of the MISRA examples you gave involved constants, which I said
elsewhere are an easy feature that ought to be built-in to the language.
The others are:
#define PLUS2(X) ((X) + 2) /* Macro expanding to expression */
Inline function. (That such macros remove the need to specifier type is
something that needs thinking about, perhaps as a new language feature,
but which must under no circumstance involved introducing templates).
#define STOR extern /* storage class specifier */
Redefining the language (wasn't this prohibited?).
#define INIT(value){ (value), 0, 0} /* braced initialiser */
IMO, also redefining the language (even if it is a new version of C). An
initialiser with multiple elements is enclosed in {...}. This gets rid
of the braces.
#define CAT (PI) /* parenthesised expression */
Inline function.
#define READ_TIME_32() \
do { \
DISABLE_INTERRUPTS (); \
time_now = (uint32_t)TIMER_HI << 16; \
time_now = time_now | (uint32_t)TIMER_LO; \
ENABLE_INTERRUPTS (); \
} while (0) /* example of do-while-zero */
Inline function.
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!
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-16 09:13 -0800 |
| Message-ID | <7dc5b761-29bb-4244-aa99-ed20cbfa5fcd@googlegroups.com> |
| In reply to | #104006 |
On Thursday, February 16, 2017 at 8:32:20 AM UTC-6, Bart wrote:
> On 16/02/2017 12:44, Thiago Adams wrote:
> > But, think the key for real and immediate use is to be very
> > compatible with C. Also for general success.
> > I think C++ is very successful because of this.
>
> I wonder why C doesn't just disappear then? As every C program, with
> some tweaks as necessary, will compile as C++.
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++.
Of course, the same sort of problem can exist along the path from C89
to later versions unless a compiler continues to support old semantics.
Some constructs in C89 have no practical equivalent in C99 (e.g. unless
one interprets C89 in a fashion that would not allow allocated storage to
hold objects of non-character type, it would be hard to write an efficient
function whose behavior was semantically equivalent to the following in
all cases that would be defined in C89).
void copy_as_bytes(void *dest, void *src, size_t n)
{ memmove(dest, src, n); }
The number of cases where C constructs have no C++ equivalent, however, is
larger than the number of cases where C89 constructs have no C99 equivalent.
> The others are:
>
> #define PLUS2(X) ((X) + 2) /* Macro expanding to expression */
>
> Inline function. (That such macros remove the need to specifier type is
> something that needs thinking about, perhaps as a new language feature,
> but which must under no circumstance involved introducing templates).
Macros can do some things inline functions can't. It may be practical to
give some of those abilities to inline or other functions (e.g. include a
real pass-by-reference syntax, and add some special parameter types whose
values would be generated by the compiler rather than the caller source
code). For example, given:
void inc_and_log_it(__caller_file cf, __caller_line cl,
char const *msg, unsigned &var)
{
fprintf(logfile, "%s:%u\n", msg, var);
var++;
}
a function call log_it("FRED", x); would be interpreted as though the
function had been
void log_it(char const *cf, size_t cl,
char const *msg, unsigned * restrict v);
{
fprintf(logfile, "%s:%u\n", msg, *var);
(*var)++;
}
and the call had been log_it(__FILE__, __LINE__, "FRED", &x); except that
a compiler would be entitled to treat x afterward as though its address
had not been taken.
>
> #define STOR extern /* storage class specifier */
>
> Redefining the language (wasn't this prohibited?).
A common pattern in some circles is to implement the "don't repeat yourself"
principle with external variables by having a header file like foo.h say
something like:
#ifndef FOO_C
#define FOO_EXTERN extern
#else
#define FOO_EXTERN
#endif
and then precede each declaration within the file with FOO_EXTERN. This
avoids the need to keep two sets of declarations in sync, and would be even
more useful if "extern" had priority over the presence of an initializer,
thus allowing e.g.
FOO_EXTERN const my_array[] = { 1,2,3,4,5,6 };
to be treated in files other than foo.c as a declaration of a complete
array type whose size would automatically match the number of items
therein. I've seen no way to define such things which would work as nicely
as that construct could. There are ways of achieving such functionality in
C99 by defining a macro containing all the elements and then using that
both for the initialization and for expressions that compute the size, but
nothing as clean and simple as the above.
> #define INIT(value){ (value), 0, 0} /* braced initialiser */
>
> IMO, also redefining the language (even if it is a new version of C). An
> initialiser with multiple elements is enclosed in {...}. This gets rid
> of the braces.
A macro containing a list of comma-separated items without braces is more
dubious than one which contains the braces, though the former may be needed
in some contexts where two or more arrays need to be initialized with data
which is largely identical.
> #define CAT (PI) /* parenthesised expression */
>
> Inline function.
>
> #define READ_TIME_32() \
> do { \
> DISABLE_INTERRUPTS (); \
> time_now = (uint32_t)TIMER_HI << 16; \
> time_now = time_now | (uint32_t)TIMER_LO; \
> ENABLE_INTERRUPTS (); \
> } while (0) /* example of do-while-zero */
>
> Inline function.
Compilers have a lot of freedom with functions declared inline. Consider
a macro to reverse all the bits in a 32-bit word using a combination of
masks and shifts. Invoking such a macro with a compile-time constant will
yield a compile-time constant result. An inline function, by contrast,
would on many compilers be likely to yield something far less efficient
(even though the function should devolve to a simple constant, many compilers
may decide for each function that it will always be inlined or never be
inlined, and since the combination of shifts and masks necessary to reverse
a non-constant value would be fairly complicated, many compilers would decide
never to inline the function).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-16 10:38 -0800 |
| Message-ID | <lnwpcqq8v7.fsf@kst-u.example.com> |
| In reply to | #104014 |
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?
[...]
--
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]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-02-16 11:55 -0800 |
| Message-ID | <ab4395b0-213c-4c70-beab-7a19ea1f020e@googlegroups.com> |
| In reply to | #104027 |
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. Adding placement new might not be a problem except that the Standard makes no guarantee about the contents of any portion of the newly-selected member--even parts which would share a Common Initial Sequence with the previously accessed member.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-16 12:24 -0800 |
| Message-ID | <lnshndrij7.fsf@kst-u.example.com> |
| In reply to | #104030 |
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. Adding placement new might
> not be a problem except that the Standard makes no guarantee about the
> contents of any portion of the newly-selected member--even parts which
> would share a Common Initial Sequence with the previously accessed member.
C++ has the common initial sequence rule; C++11 9.2p19 [class.mem] and
9.3p1 [class.union].
I don't see anything in the C++ standard that permits writing to one
member of a union and reading another, as C permits, but I could very
easily be missing something.
--
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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-16 21:32 +0100 |
| Message-ID | <o8525p$30h$1@dont-email.me> |
| In reply to | #104030 |
On 16/02/17 20:55, supercat@casperkitty.com wrote: > 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. Adding placement new might > not be a problem except that the Standard makes no guarantee about the > contents of any portion of the newly-selected member--even parts which > would share a Common Initial Sequence with the previously accessed member. > Placement new constructs a new object at a given address. You can't use it as a way to access existing data as though it were a different type. If you have a C++ union containing classes with constructors and destructors, then to change which type you store in a union you must first explicitly destruct the existing member, then use placement new to construct a new one. This is /not/ type-punning - it is the equivalent in C of simply assigning to a different member (since C objects have no constructors or destructors). C++11 and C++14 explicitly allow access to a common initial sequence, just like C. I assume that also applies to earlier C++ standards, but I don't have them handy. 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. However, the reason "type punning" via unions was standardised in C99 is that compilers already implemented it and people relied upon it. I suspect you will find that any C++ compiler will support type punning via unions, at least when constructors and destructors are not involved - if you use type punning to gain access to an invalid object, that will be UB. Certainly C++ does not /require/ that such type punning is UB.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-16 12:55 -0800 |
| Message-ID | <lnk28prh30.fsf@kst-u.example.com> |
| In reply to | #104033 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> However, the reason "type punning" via unions was standardised in C99 is
> that compilers already implemented it and people relied upon it. I
> suspect you will find that any C++ compiler will support type punning
> via unions, at least when constructors and destructors are not involved
> - if you use type punning to gain access to an invalid object, that will
> be UB. Certainly C++ does not /require/ that such type punning is UB.
I'm not sure that last sentence makes sense. Either it's undefined
behavior or it isn't. If the C++ standard doesn't define the behavior,
then it's UB -- even if all implementations behave consistently. UB
doesn't mean "it blows up".
The C++ definition is similar to C's. Quoting C++11:
undefined behavior [defns.undefined]
behavior for which this International Standard imposes no
requirements [ Note: Undefined behavior may be expected when
this International Standard omits any explicit definition
of behavior or when a program uses an erroneous construct
or erroneous data. Permissible undefined behavior ranges from
ignoring the situation completely with unpredictable results, to
behaving during translation or program execution in a documented
manner characteristic of the environment (with or without the
issuance of a diagnostic message), to terminating a translation
or execution (with the issuance of a diagnostic message).
Many erroneous program constructs do not engender undefined
behavior; they are required to be diagnosed. — end note ]
--
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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-02-16 22:41 +0100 |
| Message-ID | <o8566m$gra$1@dont-email.me> |
| In reply to | #104036 |
On 16/02/17 21:55, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> However, the reason "type punning" via unions was standardised in C99 is >> that compilers already implemented it and people relied upon it. I >> suspect you will find that any C++ compiler will support type punning >> via unions, at least when constructors and destructors are not involved >> - if you use type punning to gain access to an invalid object, that will >> be UB. Certainly C++ does not /require/ that such type punning is UB. > > I'm not sure that last sentence makes sense. Either it's undefined > behavior or it isn't. If the C++ standard doesn't define the behavior, > then it's UB -- even if all implementations behave consistently. UB > doesn't mean "it blows up". > Supercat said that it "requires [that it] yields UB", which I interpreted as him thinking the compiler /had/ to leave the behaviour here without definition. It is not defined by the C Standards, but there is no requirement for an implementation to leave it without a definition. > The C++ definition is similar to C's. Quoting C++11: > > undefined behavior [defns.undefined] > > behavior for which this International Standard imposes no > requirements [ Note: Undefined behavior may be expected when > this International Standard omits any explicit definition > of behavior or when a program uses an erroneous construct > or erroneous data. Permissible undefined behavior ranges from > ignoring the situation completely with unpredictable results, to > behaving during translation or program execution in a documented > manner characteristic of the environment (with or without the > issuance of a diagnostic message), to terminating a translation > or execution (with the issuance of a diagnostic message). > Many erroneous program constructs do not engender undefined > behavior; they are required to be diagnosed. — end note ] >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-02-16 14:02 -0800 |
| Message-ID | <lnbmu1rdzc.fsf@kst-u.example.com> |
| In reply to | #104040 |
David Brown <david.brown@hesbynett.no> writes:
> On 16/02/17 21:55, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> However, the reason "type punning" via unions was standardised in C99 is
>>> that compilers already implemented it and people relied upon it. I
>>> suspect you will find that any C++ compiler will support type punning
>>> via unions, at least when constructors and destructors are not involved
>>> - if you use type punning to gain access to an invalid object, that will
>>> be UB. Certainly C++ does not /require/ that such type punning is UB.
>>
>> I'm not sure that last sentence makes sense. Either it's undefined
>> behavior or it isn't. If the C++ standard doesn't define the behavior,
>> then it's UB -- even if all implementations behave consistently. UB
>> doesn't mean "it blows up".
>
> Supercat said that it "requires [that it] yields UB", which I
> interpreted as him thinking the compiler /had/ to leave the behaviour
> here without definition. It is not defined by the C Standards, but
> there is no requirement for an implementation to leave it without a
> definition.
Supercat was either incorrect or stating something trivial, depending on
how you interpret it. If a construct has undefined behavior, that means
only that the standard does not define its behavior. It places no
requirements of any kind on implementations. If a constructs behavior
is not defined by the standard and an implementation chooses to define
its behavior, then it still has "undefined behavior" as the standard
defines and uses that phrase.
I'm not sure what it means for something to "yield UB".
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web