There's quite a few free compilers and tools. I've linked to some on my site. Note that compiling under Windows with a native compiler entails some changes to the code. However, you will find just about any C compiler to be as "informative" as Cygwin's GNU gcc/gdb. That is error messages, stack dumps, debugging are difficult when you don't understand the language or the system.
08 Mar, 2009, David Haley wrote in the 4th comment:
Votes: 0
There's been an alternative to Cygwin that's been discussed a fair bit called AndLinux. It's apparently quite popular with people who use it, although I haven't used it myself (as Linux is my primary desktop). Just ask The_Fury, I'm sure he'll tell you all about it. :smile:
The issue is the poster didn't know what structs or boolean operators were two weeks ago. The damn operating system or compiler doesn't change that. Learning C takes time.
09 Mar, 2009, David Haley wrote in the 6th comment:
Votes: 0
Ah, I hadn't noticed that the idea was to get a more informative compiler/OS. In that case, indeed, the choice of OS and compiler is basically absolutely irrelevant.
The issue is the poster didn't know what structs or boolean operators were two weeks ago. The damn operating system or compiler doesn't change that. Learning C takes time.
I'll second Tyche here, that OS or compiler isn't going to make much of a difference. Take your time with it, it'll come eventually.
The thing that annoys me is errors/bugs like this:
Quote
Mon Mar 9 20:52:21 2009 :: Loaded 1 mobprogs. Mon Mar 9 20:52:21 2009 :: Loaded 1 mobprogs. Mon Mar 9 20:52:21 2009 :: [*****] BUG: Equip_char: already equipped (3). Mon Mar 9 20:52:21 2009 :: ROM is ready to rock on port 9999 (0.0.0.0).
How am I to know what file this is, let alone where in the file…
It looks like a character, probably in this case a mobile is being equipped twice to the same wear location. It's a reset in one of the areas perhaps.
Resets in the area files look like these from midgaard.are. M 0 3069 4 3138 4 * the cityguard E 1 3365 -1 0 * a war banner E 1 3364 -1 1 * a city guard signet ring E 1 3350 -1 16 * a standard issue sword
One of the E resets is loading to the same wear location as a previous one. Not these above.. it's just an example.
Which area file and which mob is unknown, because the error message doesn't say. A better error message would show the name and line of the area file, and the object and mobile vnums. The only thing I see you have to go on is the wear location is number 3. It appears this BUG/error isn't fatal. That is the object just isn't loaded to the mob and things continue.
09 Mar, 2009, boblinski wrote in the 11th comment:
That command will find all the equipment resets to wear location 3 in all your area files.
The search text, '^E +[0-9]+ +[0-9]+ +[-0-9]+ +3', is called a regular expression the pieces of which mean…
'^E' - line starts with E ' +' - one or more spaces '[0-9]+' - one or more digits '[-0-9]+' - one or more digits may be signed '3' - the digit 3
Find me a line starting with E followed by one or more spaces followed by one or more digits followed by one or more spaces followed by one or more digits followed by one or more spaces followed by one or more digits which may be signed followed by one or more spaces followed by a 3.
Ah, I hadn't noticed that the idea was to get a more informative compiler/OS. In that case, indeed, the choice of OS and compiler is basically absolutely irrelevant.
Actually there has been a lot of work lately into more informative compiler error messages, which is one reason I'm looking forward to Clang (http://clang.llvm.org) hitting production quality level. Some GCC errors for example make almost no sense even to me (although I can look at the line of code it complains about and figure it out no problem), and often times compilers through away semantic information that the compiler itself doesn't need, leading to poor error messages. For example, they usually display errors involving code using a typedef that references the original type and not the typedef name, which can make the error far more obscure sounding. Macros also can cause a huge number of errors that make no sense when looking directly at the code. Clang retains more information about the actual source code in its AST and its semantic analyzer uses that information to produce far more user friendly error messages than GCC, Visual C++, or other common compilers ever have. It's especially useful for C++ (which Clang still has very incomplete support for), where error messages often spit out fully-expanded template parameters even though the source code only ever references simple-looking types like std::vector<int> or std::string.
None of that is going to matter in the least if the OP is having problems with the uninformative error messages produced by the MUD itself, of course. :)
12 Mar, 2009, David Haley wrote in the 14th comment:
Votes: 0
One of the things I like about Sun's C++ compiler is that template parameters are given explicitly once in messages, and then referenced as Type0, Type1, etc. So instead of:
a trivial example, but it's awfully useful when your template parameters are complex types, or even more templates. (Think map of string to map of string to vector of string..)
man I wish I knew about the -n option for grep, that would have made things a LOT easier on me. Thanks for the info Tyche.
Just as an aside for boblinsky, the -i option makes it so that your search is case insensitive. meaning you can type grep -i blahblah *.* and it'll return instances of blahblah BLAHblah and other variations on that within the code. Just using grep without the -i means you have to capitalize things correctly.
One of the things I like about Sun's C++ compiler is that template parameters are given explicitly once in messages, and then referenced as Type0, Type1, etc. So instead of:
a trivial example, but it's awfully useful when your template parameters are complex types, or even more templates. (Think map of string to map of string to vector of string..)
That's pretty nice, but couldn't you just use the standard contract of std::map and refer to std::map<int,std::string>::key_type and std::map<int,std::string>::data_type? If you're going to hide the types anyway why not use what the standard exposes? But I see where it may be useful just not in the example you provided.
That's pretty nice, but couldn't you just use the standard contract of std::map and refer to std::map<int,std::string>::key_type and std::map<int,std::string>::data_type? If you're going to hide the types anyway why not use what the standard exposes? But I see where it may be useful just not in the example you provided.
Because the compiler doesn't know about those. The types aren't built-in to the compiler, they're just part of a standard library. Should the compiler see the template types and then search all the typedefs inside the type to see if any match the template type arguments? It might even pick the wrong one in some cases, e.g., if you have a std::map<int, int>, it might either just use key_type for both ints, or the compiler would have to be even smarter and figure out which typedefs map to which template typenames. It would not be a bad thing to do at all: it's just really hard, and there's some corner cases that may not work correctly.
Usually the biggest offender with templates in C++ is the fact that most templates you use are already specialized (sometimes partially). Especially when C++0x is out and allows partial template typedefs. The issue is that developer often uses std::string::iterator and then the compiler starts spitting out errors referencing something like base_iterator<char, std::allocator<char>, std::basic_string<char, std::allocator<char> > >::iterator.
What Clang does (and what I guess maybe Sun's compiler might do?) is that it remembers that you defined the variable in question as a std::string (which is just a typedef) and uses that in the error messages, while most compilers throw away the typedef information during parsing of the AST and so are forced to show the fully expanded type in errors.
Clang does a lot more, too. It's error messages are usually just a lot clearer. Where GCC might say "invalid operand type" Clang might say "cannot use + operator on types (int, struct foo)" and then also shows the line of code with nifty highlighting:
int a = (5 * num) + data; ~~~~~~~~~ ^ ~~~~
13 Mar, 2009, David Haley wrote in the 18th comment:
Votes: 0
Also, I picked that example just because I couldn't think of another example of the types repeating off the top of my head. :redface:
And hey, this Clang compiler sounds utterly awesome…
elanthis said:
The issue is that developer often uses std::string::iterator and then the compiler starts spitting out errors referencing something like base_iterator<char, std::allocator<char>, std::basic_string<char, std::allocator<char> > >::iterator.
Meh, I've always hated that. :mad:
I find that with template-related compiler errors, it's usually easier to get the line number from the error output (if you can find it) and then eyeball it myself, stepping through instantiation in my head if necessary. (Hey, that would be a cool tool: something that lets you interactively expand a template to see what happens…)
I'm currently using Cygwin but I don't find it very informative when it comes to Bugs and Mud-crashes..
Any advice?