[MUD-Dev] Re: Modular MUD [Was:Finer points of Telnet programming ...]

Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
Wed Aug 26 08:04:06 CEST 1998


[Caliban Tiresias Darklock:]

 >I don't generally have to reboot either. Visual C++ is pretty smart at
 >catching my bonehead mistakes before I ever run the program. Which is
 >another thing that bugs me about Unix; the development tools are very good
 >at doing what you tell them, but they don't generally tell YOU a damn
 >thing. I don't mind having to sleuth around to find stuff (Windows
 >certainly requires it enough), but I'd rather not have to do it ALL THE
 >TIME. Unix requires me to think of everything myself, and never jogs my
 >memory. Some people work better that way. I'm not one of them. I would
 >certainly be annoyed if Visual C++ popped up a dialog for every error and
 >expected me to fix it immediately, but I like it to sit down there and just
 >tell me what it finds. Ideally it shouldn't find anything, but at least I
 >can tell where I did something strange on purpose... and that's usually a
 >good place for a comment about why I did it.

This has nothing to do with MUD programming, I expect, but I thought
I would comment here - I have used both environments, but only at the
C level (I'm not into C++).

Running gcc on Unix with warnings enabled is about the same as running
VC 5 with warnings enabled - both will tell you about all sorts of
little things. I always run with all warning enabled. If you do your
Unix makes under emacs, it will also take your cursor to the place
of the errors, one at a time. Thus, the two environments are very
similar in that sense.

One difference I have noted is that VC 5 has a bit more trouble dealing
with errors - it usually has extra error indicators after the initial
error, that don't help at all. From a compiler-writer point of view,
it seems to not have an internal 'error' type, and thus issues complaints
about types after a bad symbol, and those are quite unneccessary.

--
Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA




More information about the mud-dev-archive mailing list