Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2001:
[Freeciv-Dev] Re: Map coordinate cleanups.
Home

[Freeciv-Dev] Re: Map coordinate cleanups.

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Cc: Jason Dorje Short <jshort@xxxxxxxxxxxxx>, <freeciv-dev@xxxxxxxxxxx>
Subject: [Freeciv-Dev] Re: Map coordinate cleanups.
From: Justin Moore <justin@xxxxxxxxxxx>
Date: Fri, 17 Aug 2001 12:06:02 -0400 (EDT)

> >Um, all of those reasons are just "it is faster".
>
> Actually they are not. Gaute did a minor oneliner fix and replaced inline
> functionally across the codebase in perhaps a majority of files.
>
> In most cases where these things were written as or included in functions,
> people hand coded the tests rather than calling functions because the
> function "hid" the definition, functions are known to be slow and it was
> only a compare anyway, or similar rationales. The result was a
> proliferation of variants on the basic concepts, bastard fixes for obscure
> bugs and a host of other evils.

   So basically this amounts to "functions cause people to write bad
code"?  This sounds more like a) people just writing sloppy code, and b)
the people with CVS access allowing it.  We've all written our share of
buggy/sub-optimal code (as evidenced by my stellar suggestion about
variables vs #defines ;p) but when it happens the people maintaining the
tree shouldn't let it through.

<noflames>
   To quote Theo de Raadt, "Know your API, know your API, know your API."
</noflames>

> >and I don't look forward
> >to having to replace it later to allow for orthogonal maps.
>
> The macro or the function are just equivalent symbolic names for the API
> with slighly different implementation properties. But there is NOTHING you
> need to change in one case that you will not be changing in the other :-).

   One problem with lengthy macros that has always bugged me is that
they're a real pain to debug with gdb.  You get a segfault and you know
which line it died on, but then you have to figure out where in the macro
the bug is.  Obviously it's possible, but it's a real pain.  A nice thing
about functions is the type checking; if you change declarations or other
function defintitions *too* much elsewhere, it could have a negative
impact on the rest of the code.

   Obviously short one or two line macros are nice -- I'm not arguing that
-- I'm just siding with Kevin and Raimar about correctness and
maintainability over performance.

   As a side note, running the freeciv tree through LCLint even on weak
(http://lclint.cs.virginia.edu) dumps a whole list of minor bugs.

> The advantage of functions is that they are not limited in capability the
> way macros are, and implementation can be far more complex. And any macro
> of more than a page in size is also evil.

   I know some graphics people that would disagree with that last
statement.  I've seen some pretty nasty clipping plane code like that. :)

   BTW, has anyone profiled an actual game?  As in not an all-AI one?  I'd
be interested to see how much time is spent in all these sections you're
trying to optimize as opposed to the select() call in sniff_packets.

-jdm

Department of Computer Science, Duke University, Durham, NC 27708-0129
Email:  justin@xxxxxxxxxxx



[Prev in Thread] Current Thread [Next in Thread]