Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Which code style do you prefer the most? Date: Sat, 01 Mar 2025 21:56:47 -0800 Organization: A noiseless patient Spider Lines: 47 Message-ID: <865xksx9eo.fsf@linuxsc.com> References: <87v7swzzl7.fsf@onesoftnet.eu.org> <87a5a7k0ko.fsf@onesoftnet.eu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Sun, 02 Mar 2025 06:57:09 +0100 (CET) Injection-Info: dont-email.me; posting-host="3262fa73ab11de5fd8cc37f0606a7eed"; logging-data="695078"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX188D9zCOd4xtdiOi++nQmqlyqsanY1oR7I=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:bdQL9VuR8tsXHi7yOdBYa1JebmI= sha1:p2L2I0qT1+Zx3GEzpLiHKquCKIc= Bytes: 2836 bart writes: > On 27/02/2025 12:56, Ar Rakin wrote: > >> [concerning line splicing with \ at end of line] > > Then line-splicing, which combines two lines if the first ends > with \, is done before processing // comments. > >> I am aware that you can do the same thing with strings like this: >> >> fprintf(stderr, "multi\ >> line\ >> strings\ >> are fun."); >> >> I can understand how this might be useful; but with *comments*?? >> Was that actually a thing in the official C standards? > > It's isn't that useful for strings; the following is simpler and > also works: > > "multi" > "line" > "string" Just as a historical note, this construction wasn't available in pre-standard C. So line splicing used to be needed in such cases. > But it is needed for multi-line macros, as C's proprocessor is > strictly line-oriented and a macro definition must fit onto one > line. Since 1989 when the original C standard was done, multi-line macros can be written without needing to use \ for line splicing. I was surprised to learn this when I first saw it. An example: #define MASK_WIDTH( m ) ( 0U + (unsigned)+( /* */ (m) /((m)%32767 +1) /32767 %32767 *15 /* */ + (m) %32767 /((m)%31 +1) /31 %31 *5 /* */ + 4 - 12 / ((m)%31 + 3) /* */)) Yes, it's ugly. Yes, it means line breaks can be put in only at token boundaries (although in practice that limitation is observed anyway). Yes, I know of no production code that uses this technique. Still I think this trick is one worth knowing about.