Chad,
Thank you for your reply. I'd like to offer a few comments from the
viewpoint
of a codebase and semi-experienced MUD developer.
>Please don't make arbitrary statements like "slightly inefficient" etc.
The statement "slightly inefficient" is not arbitrary, especially to
those who
are familiar to Big O analysis. I refer to the code I posted as 'slightly
inefficient' because the STL vector data structure is perhaps not the
optimal
data structure to use for helpfiles, though it be perhaps better than
95% of
choices out there. Why? You said so yourself:
>If there is a simple built in function or library that will work,
>better to use it and spend your time developing new custom features
for your
>program than to spend a lot of extra time and effort to make your own
version
>of the existing code.
I agree wholeheartedly. I love the STL, for instance. In fact, I am
rewriting
my timed events to use D-heaps written with the STL instead of C-style
linked
lists because the code will be _dramatically_ simplified. I also get free
performance: O(n*log n) vs. O(n^2). However, you went on to say:
>They lack the experience to know that the performance diferences
(particularly
>in a mud) will be almost negligable.
It depends. In the instance of high-level languages, I am probably one
of the
stronger advocates--it is simple, straightforward, and the performance
differences are indeed trivial. In fact, I am now writing my server in
C++.
However, when you look at data structures in general, or sort methods,
things
are much different. Take for example a new developer who decides to use
bubble
sorts for all of his sort needs because 1) that's what he learned first,
2) he
doesn't know that bubble sorts are terribly inefficient, and 3) he read
that
"the performance diferences (particularly in a mud) will be almost
negligable",
so he figures it won't matter. A developer should never discard
performance
considerations. A MUD developer in particular has to be even more aware of
performance. MUDs are very dynamic and future-looking in nature. While in
development the MUD may have 3 players at a time and run acceptably.
Will the
code be ready for when there are 20? 50? 100? If not, then that means
even more
work to replace the original code--all the code that was written upon (and
dependent on) the original flawed decision to just "wing it" and "code
anything
that works" results in many more hours of coding, debugging, and testing
than
the original design ever took.
The gist of what I wrote above is this: A good programmer should always
keep his
options open and be eager to learn new, more efficient methods of
dealing with
problems.
>Many mud programmers...would (I'm sure) have a much easier time
developing in a
>higher level language, and would probably encounter a lot less trivial
mistakes
>(memory management, etc) if they were to use something that was easier to
>understand and maintain.
I agree. That's why I posted the code I did. No dynamic allocation. No
pointers. My goal was to post something (hopefully) very easy to
understand.
You finished with:
>P.S. Premature optimization is the root of all evil
Maybe, but good planning is the root of all excellent programs :). No
reason to
intentionally introduce ineffiency into your code. Even novice
programmers know
that.
-- Jeremy
