Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: // comments and \ Date: Tue, 01 Dec 2015 08:55:38 -0800 Organization: None to speak of Lines: 40 Message-ID: References: <87fuzmdznb.fsf@bsb.me.uk> <63922dcf-c5cb-4aae-a271-d1fe0b450603@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="3052"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/UvpeXvl4lF+wR8EFOSNn/" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:8DPS8cMBY8GBi3NluBRxKXSJWoM= sha1:Ls9vKG911dFFk/5u9/n3/syD7ek= Xref: csiph.com comp.lang.c:77528 supercat@casperkitty.com writes: > On Tuesday, December 1, 2015 at 8:14:46 AM UTC-6, Ben Bacarisse wrote: >> It's a consequence of adding // comments into C in 1999 along with the >> principle of least surprise. Ever since ANSI C in 1989 (and probably >> earlier in some implementations) a newline preceded by a \ are ignored. >> This was always permitted in C #define lines, but ANSI C made it a >> general line-continuation mechanism to be performed before almost >> anything else, and just before comment removal. Thus, when // comments >> were added, the current behaviour was the least surprising -- certainly >> the behaviour that needed the fewest special-case changes to the >> existing words. > > I don't know about that--since "//" comments are an entirely new concept, > they could just as well have been defined as being handled before anything > else. If anything, doing that would have made it easier to adapt existing > compiler systems, since all one would need to do is filter the source files > through a utility that strips "//" comments and feed the result into an > existing compiler, rather than having to handle "//" between pre-processing > steps. "//" comments were not an entirely new concept. BCPL had them. Aside from that, "//" commments have to be handled *after* string literals and character constants are identified: puts("// This is not a comment"); It might be possible to rearrange the translation phases (see N1570 5.1.2.2) so that line-splicing and "//" comments interact differently, but it would be difficult, and it would probably mean that "//" comments and "/*...*/" comments would be processed in different phases. The current line-splicing of "//" comments is a problem, but a minor one, and it's likely the cure would be worse than the disease. -- Keith Thompson (The_Other_Keith) kst-u@mib.org 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"