Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: configure() -- a new C compiler preprocessor and code injection proposal Date: Mon, 31 Aug 2015 11:27:14 -0700 Organization: None to speak of Lines: 23 Message-ID: References: <93b0ff7b-6ee2-48f9-aad4-6e3b91e9ceac@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="10172"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/xyyQgXmiKhG3K62TxYJvE" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:H2mUGclv7LzmID3Td2M4GoP2Rhc= sha1:wRQHcMi9tvVqHNAVAVi7h8wge3w= Xref: csiph.com comp.lang.c:68772 "Morten W. Petersen" writes: [...] > OK I'll have another look at that to see what's going on. I'm still > confident that changing habits a bit will make it possible to avoid > using macros and let the compiler optimize plain C code to the speed > that a macro would have been. Are you assuming that the only purpose of macros is to improve speed? Macros can also provide expressiveness that can't be provided without them. You've seen several examples of that in this thread. It's true that a lot of things that have previously been implemented as macros can reasonably be replaced by inline functions (which C didn't have until C99) -- or by plain functions if performance isn't really critical, or if the compiler can do its own inlining without being told to. -- 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"