[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