Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!feeder.news-service.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Ian Collins Newsgroups: comp.lang.c Subject: Re: Malloc Query Date: Mon, 23 May 2011 19:24:11 +1200 Lines: 70 Message-ID: <93ugcsFt2pU6@mid.individual.net> References: <0.3ac369f64d11bcd06d18.20110519002615BST.87ei3vtwtk.fsf@bsb.me.uk> <98a074c87051012-452fb@gmail.com> <0.bf5e9ff46dfbfc1e78d6.20110519032218BST.87tycrsa3p.fsf@bsb.me.uk> <2b5874771e1859c-5f9fd@gmail.com> <22a91a32-b2c6-4ce1-bb2b-23c2455bc195@z13g2000yqg.googlegroups.com> <708913a057f3f9c-34aa7@gmail.com> <0.47b2d301a43a01009630.20110522231836BST.87fwo6nzur.fsf@bsb.me.uk> <21ceccb2e03a4dc-edfd3@gmail.com> <93tk6hFt2pU3@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net D4gNrTNDsFGDE/YhnKdj+AK1oj9iF8plyez3ZnUH6LejbUcqTt Cancel-Lock: sha1:1BLV4H+c8ddG2F04R8//BxM8TK0= User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.9) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.4 In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.lang.c:4554 On 05/23/11 05:57 PM, Uncle Steve wrote: > On Mon, May 23, 2011 at 11:22:57AM +1200, Ian Collins wrote: >> On 05/23/11 11:18 AM, Uncle Steve wrote: >>> On Sun, May 22, 2011 at 1u1:18:36PM +0100, Ben Bacarisse wrote: >>>> Uncle Steve writes: >>>> >>>>> On Sun, May 22, 2011 at 02:49:51AM -0700, luser- -droog wrote: >>>>>> >>>>>> I've been using integer offsets instead of pointers a lot lately and >>>>>> I think you might be better off using the array formula explicitly: >>>>>> >>>>>> #define arena_obj_addr(x, n) ((void *) (x->arena + n * x->obj_size)) >>>> >>>> Everyone is taking chances here. The x and n should be in parentheses >>>> so that the macro expands as expected. This is one reason why functions >>>> are usually preferred. >>> >>> For a long time I've thought macros were preferable to functions for >>> the reason that a function call has to save registers, stuff it's >>> arguments on the >>> stack, and so on. Macros should just fold into the program text, but >>> today inline functions are just as fast as macros. It has become a >>> matter of preference. gcc even has the ability to use register >>> calling conventions for function calls in some circumstances. The >>> distinction between a macro and a function call is becoming moot. >> >> No it isn't. All the disadvantages of function like macros still exist, >> but the single (possible) disadvantage of function calls has gone. > > Not so fast, Mr. Collins. Macros are useful in numerous situations > where function calls would be inefficient. The only real use for macros is passing __FILE__ and __LINE__ to debug logs! > For my purposes, it is > sometimes nice to write a macro which uses conditionals to select a > particular code path through the macro. If the conditional can be > resolved at compile-time, the dead code branches in the macro are > pruned, saving space. A similarly structured function call won't be > optimized in this fashion unless (maybe) it is inlined. Why not? Whether the function is called or in line, the conditional compiles are still there. > Not enough? Is it smart to rely on the compiler to optimize the crap > out of everything, or is it better to write efficient code at the > outset? Inlining is a very simple optimisation. You also overlook the opposite optimisation - not inlining. There are situations where a smaller executable performs better (or even fit the target device!). The compiler should be able to judge where it is appropriate to inline. Compilers targeted at embedded devices often have options to tune these heuristics. Decent compilers for hosted environments offer profile feedback to further tune optimisations. In short, the more choice you give the compiler, the better job it can do. > There are a number of C compilers out there that are not gcc, > and which may or may not generate equivalent code for otherwise > similar macros/functions. I'm O.K. with peppering my code with > well-designed macros and ignoring functions for simple common > procedures, but then I'm biased that way from habit. I guess working with C++ for many years has biased me the other way. Aggressive inlining has long been a feature of C++ compilers. It used to be a unique feature, but those days are long past. -- Ian Collins