[DGD]FW: [MUD-Dev] C# vs. LPC

[Christopher Allen]

-----Original Message-----
From: mud-dev-admin at kanga.nu [mailto:mud-dev-admin at kanga.nu]On Behalf Of
Travis Casey
Sent: Tuesday, June 27, 2000 11:27 AM
To: Christopher Allen
Subject: Re: [MUD-Dev] C# vs. LPC


Tuesday, June 27, 2000, 12:18:02 PM, Christopher Allen <ChristopherA at skotos.net>
wrote:

> I was wondering if there were any of you c language experts who could
> compare and contrast Microsoft's new C# (cee-sharp) language with
> LPC.

> http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp

> How different are they? How alike? Any worthy things in LPC that should
> be in C#, or worthy things in C# that make sense for LCP?

I'll take a quick shot at it.  Note that while I know LPC quite well,
all I know about C# is what I read on that page and in the two
documents that are downloadable from that page.

The two languages were created with very different purposes in mind --
LPC was created specifically to build text muds, while C# is a
general-purpose language.  One major difference from this that doesn't
show up in the languages themselves is the sorts of environments they
run under.

For example, most LPC engines handle the details of setting up an
initial listening socket and handling incoming telnet connections
for you; all you need to do is write a simple program for the players
to log in through and a way to associate them with their bodies,
shells, or whatever objects represent them in the game.  A C# program
will not, although there may be pre-written classes available for
this.  Similarly, most LPC setups already feature the idea of objects
being containers for one another, implementing it in a way that's
meant to work well for a mud.  C# doesn't -- you'd either have to
set up the code for containers yourself or find a pre-written class
that does it.  Another example is that some LPC setups have built-in
features for implementing creator security.

Both are object-oriented, but LPC enforces this more strongly than C#
seems to, from what I can see.  For example, the only way to change a
variable inside another object in LPC is to call a function in that
object; in C#, you can set a variable inside another object as you
could in C++ -- e.g.:

  Class1 r1 = new Class1();
  r1.myvariable = 123;

C# has many more value types than LPC -- it distinguishes between
unsigned, short, long, etc., where most LPC versions simply have
"int".  C# provides an array type, but the documentation doesn't
indicate whether arrays are dynamically resizable.  LPC arrays are
automatically resized as needed.  C# does not seem to provide any
equivalent to LPC's mappings, although, of course, you could create
one or find one.

Both languages provide automatic garbage collection.  C# has a
mechanism for circumventing that, so that programmers can create code
that allocates and frees memory.

C# provides a goto; whether this is a feature or a bug is a matter of
opinion.  :-)  It also provides a good variety of control statements,
including for, foreach, do, while, and switch.  Most varieties of LPC
have all of these except foreach, and some have the foreach as well.
No variety of LPC that I know of has a goto.

C# provides error handling through both throw and try mechanisms; the
versions of LPC that I know of have only throw, and have a global
catch.  The C# info I have doesn't mention whether catches are global
or local.

C# provides support for event handlers; LPC does not.  However, all
versions of LPC that I know of provide support for timed callbacks;
from what I see, it appears that one would have to either do this
yourself or find a library for it in C#.  Creating an event handler
for LPC would not be difficult; I don't know how difficult creating a
timed callback mechanism for C# would be.

Where LPC uses either function pointers or closures, C# has "delegate"
classes.  Since I've never worked with delegate classes, I can't
comment on any differences in functionality or ease of use.

C# provides "versioning" support -- which, from what I can see,
basically means merely that you have to explicitly say that you want
to override inherited methods, variables, etc.  I don't see this as
likely to be a problem in a typical mud environment.

It also provides namespaces, which allow programmers to have multiple
namespaces and specify which they are using.  Again, I don't see this
as likely to be a problem in a typical mud, especially when using LPC.
(You can't directly reference variables in other objects, so each
object already has its own namespace.)

A lock statement in C# provides mutual exclusion.  Since most LPC
implementations are not threaded, this isn't generally an issue in
LPC.

Both languages allow multiple inheritance.  C# also has the idea of
interfaces, as in Java, and allows objects to implement multiple
interfaces.

Some LPC dialects allow functions to take variable numbers of
arguments; from what I can see, C# does not.  Whether this is a good
thing or not I'll again leave up to the reader.

Most LPC implementations have several built-in functions for string
manipulation, with an emphasis towards breaking up command strings and
parsing them.  (Indeed, at least one LPC implementation implements the
basics of a parser for you.)  What sort of string functions C# provides
is not mentioned in the docs on that web page.

Overall, they both seem to be headed in the same direction -- towards
a more object-oriented and "user-friendly" version of C.  If you're
building a mud, you might want the mud-oriented features of an LPC
implementation -- on the other hand, if you don't like how LPC
implementations handle those, you may not.

--
       |\      _,,,---,,_    Travis S. Casey  <efindel at earthlink.net>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-'
     '---''(_/--'  `-'\_)





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


List config page:  http://list.imaginary.com/mailman/listinfo/dgd