apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: cvs commit: apr/memory/unix apr_pools.c
Date Fri, 08 Oct 2004 15:22:00 GMT
On Fri, 8 Oct 2004 15:08:38 +0100, Joe Orton <jorton@redhat.com> wrote:
> 
> 
> On Fri, Oct 08, 2004 at 09:58:07AM -0400, Allan Edwards wrote:
> > Joe Orton wrote:
> > >>The fact that these casts are unnecessary can be tracked using comments,
> > >>a list of issues in STATUS, or, not wishing to rock the boat, bugzilla.
> > >>Using a macro just obfuscates the code.
> > >
> > >
> > >s/unnecessary/undesirable/
> >
> > I hardly think it is more obfuscating that any
> > macro might be considered to be. The only reasonable
> > alternative in my opinion would be to add a comment
> > line for each cast with some common grep-able
> > string. But to me that is uglier.
> 
> A macro is useful if it abstracts something away.  This macro does not
> abstract anything away.  It expands to apr_uint32_t now, and it can
> *never* expand to anything other than apr_uint32_t.  That is obfuscation
> in my book.

If you agree with the assumption that we can't throw away the reason
for the cast but need something in the source file to help us
remember, then it becomes a question of  the clearest way to preserve
the information.

To me, using a special cast like that is as clear as a comment, more
concise than a comment, and more likely to be consistently applied and
easily found when looking for these problems than a comment.

Mime
View raw message