Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Uncle Steve Newsgroups: comp.lang.c Subject: Re: Malloc Query Date: Sun, 22 May 2011 10:01:37 -0400 Organization: Friends of the Galactic Collective Lines: 63 Message-ID: <8eb0bc573c55025-0836f@gmail.com> References: <0.3ac369f64d11bcd06d18.20110519002615BST.87ei3vtwtk.fsf@bsb.me.uk> <98a074c87051012-452fb@gmail.com> <0.bf5e9ff46dfbfc1e78d6.20110519032218BST.87tycrsa3p.fsf@bsb.me.uk> <93omefF1bbU15@mid.individual.net> <93qmsmF1bbU17@mid.individual.net> <93r6sfF1bbU20@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Injection-Info: mx04.eternal-september.org; posting-host="job9yP/rmK/fxQbJrcqEcA"; logging-data="13071"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/N5byu88yzeRTe+DLemIq0" User-Agent: nn 6.7.3 Content-Length: 2290 Cancel-Lock: sha1:Ai/WY4rO+NGOa2CbT2aCuIgLrCs= Xref: x330-a1.tempe.blueboxinc.net comp.lang.c:4510 On Sun, May 22, 2011 at 01:23:26PM +1200, Ian Collins wrote: > On 05/22/11 12:03 PM, Uncle Steve wrote: > >On Sun, May 22, 2011 at 08:50:26AM +1200, Ian Collins wrote: > >>On 05/22/11 03:13 AM, Uncle Steve wrote: > >>>On Sat, May 21, 2011 at 02:30:39PM +1200, Ian Collins wrote: > >>>>On 05/20/11 10:34 AM, Uncle Steve wrote: > >>>>> > >>>>>typedef unsigned long long int T64; > >>>>> > >>>>>#define processcputime(p) > >>>>>\ > >>>> > >>>>Why go the the trouble of declaring this as a messy macro? > >>> > >>>I'm not all that interested in nanosecond resolution for timing > >>>things, so I scaled the resolution down to microseconds and turned it > >>>into a 64-bit quantity so arithmetic calculations would be more > >>>convenient. I suppose it could be a function call, but inline it > >>>probably generates ten or so instructions. > >> > >>No more or less than an inlined function call. > > > >Right, so what's the problem? > > Using a macro where a function would do. IMO, this is a stylistic preference and has no meaningful impact on code quality. > >>>Insulating the actual > >>>system function call also makes porting a little easier. > >> > >>But doing so in a macro makes it harder! > > > >Not really. Maybe what I don't get is what you mean by 'harder'. > >Is 'harder' some ineffable quality that in a more robust age would > >serve to differentiate the men from the boys? I like to think so, but > >I don't think it's a popular view. > > Well there's more to type (all those pesky line continuation characters > to line up), no way to step in if you have a bug you can't easily > diagnose and stylistic limits imposed by a macro. The function would be > more concise if it could return its result. One simply writes a replacement macro if the target platform uses something other than clock_gettime(). If you have to use clock() or gettime() because your system is older, changes are straightforward, and it doesn't matter much whether you're adjusting a macro or function. I agree that line-continuation is a hassle to maintain, but then so is everything. If by 'harder' you mean more robust, I fail to see how. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?