TECH: STL / Heaps, etc. (was: [MUD-Dev] TECH DGN: a few mud server design questions (long))

[Jon Lambert]

Eli Stevens wrote:
 
> I love the standard template library.  Unabashedly.  ;) Of course,
> it helps that it is for my language of choice and that I like
> templates just a little too much (when templates are your only
> tool, everything looks like a nail :).  I think the STL is a Good
> Thing, but my practical/real world experience is limited.  Are
> there problems with the STL lurking under the surface?  One aspect
> that concerned me was that while it specifies the complexity of a
> given operation, you don't have any control over the coefficients
> involved.  Would it be a bad idea to rely on it too much?

I should say first that my STL experience is only with C++, not with
Java.

STL is great and wonderful.  5 or 6 years ago it wasn't all that
great.  On occasion you'll still find implementations that mess up
or omit particular methods.  In which case you either fix it
yourself or get a fix.  One problem I've noticed is concurrency and
in those cases one is advised to write a wrapper around the
interface you're interested on, or get a wrapper (i.e. RogueWave's
Threads++).  The other problem is portability and how different
compilers handle template instantiation.  CFront, Borland, GPP all
use different methods.

I like RogueWave's STL and the SGI-based STLport.

Don't limit your use of generic programming to the STL.  I've found
so much use for templated code in my own apps that a lot of this
stuff does indeed resemble a nail.

I used to be a hardcore OOP fanatic as embarassingly revealed by
many early posts.  There's little in the way of OOPness in the STL
though.  It's pretty flat.  Yet I've discovered that OOP, generic
programming, components and straight procedural/functional
techniques can all be blended to create programs that are efficient,
readable and maintainable.

I think with today's STL implementations, one has the burden of
showing that "rolling their own" is really a better solution.  Much
of STL is primarily concerned with containers (not that there's not
a lot of other good stuff), and is built on and now includes
iostreams.  I think many programmers are still turned off by C++
streams.  I can't really blame them because they often do get in the
way if you're doing custom network or database code.

An interesting idea would be creating a MUD STL to encapsulate
functionality common to muds.  Like networking, common protocols,
string functions common to muds, undirected graphs, LOS, mapping and
shortest path algorthims, etc.  I think someone claimed to be
working on somthing similar to this.  Anyone remember who and where?
Anyone want to?

--
--* Jon A. Lambert - TychoMUD        Email:jlsysinc at ix.netcom.com *--
--* Mud Server Developer's Page <http://tychomud.home.netcom.com> *--
--* If I had known it was harmless, I would have killed it myself.*--

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev