Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: High quality resources for learning modern C? Date: Mon, 05 Jun 2017 15:51:23 -0700 Organization: None to speak of Lines: 31 Message-ID: References: <7b9d7ea8-2525-4f97-a0fe-dcf9830d4848@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="f055093848ac1dede5b98e4339e7578c"; logging-data="7857"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+oQdzhu1Kie2WZVW8AE5tt" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:qjPY58KZOVNe75RLJ5Bx539jmy0= sha1:RXz5rPquJgYUmk6dqEPF2iC6sPA= Xref: csiph.com comp.lang.c:111593 bartc writes: [...] > One reason for downloading it again was to see if the preprocessor > handling had changed much since MSVC-2008. I changed the program to: > > #include > int main() > { > printf("Hello, World! %X\n", 0x1234e-4 ); > return 0; > } > > This prints 1234A for the %X item. But some compilers reject 0x1234e-4 > as a valid expression (ie. 0x1234e minus 4) because they say it's a > malformed pp token). Those compilers are correct. It's mildly inconvenient, but it's an unambiguous consequence of the rules specified in the C standard. > But if the mighty Visual C doesn't care, then I'm > not going to either in my own preprocessor. That's up to you. If you want your implementation to violate the standard (because Visual C does so or for any other reason), you're free to accept `0x1234e-4` without complaint as equivalent to `0x1234e - 4`. -- 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"