[Vesper]

Hey all.

I've been interested in teaching myself how to code for awhile now and well, I went and downloaded Cygwin on my comp. I'm also told I need to dl a codebase after that, which will probably be some sort of ROM.

Now, my question is this: I want to go out and buy the much-needed coding book. But...what exactly is preferred?

C? C+? C++? In terms of wanting to learn to code and possibly write up some snippets for mud's one day, which is suggested?

[Yui Unifex]

Most existing mud codebases have been created using C. So C++ isn't going to help you much if you want to distribute snippets, because some codebases require conversion to be compiled with a C++ compiler. The newer codebases that I see people working on are almost universally written in C++, Java, or a language with greater abstraction possibilities than C.

If you just wish to modify an existing codebase, for example ROM, a book on C would most likely be your best bet.

btw, "C+" doesn't exist =).

[Vesper]

Ahhh...thank you. *grins* And you're right, of course, it doesn't exist, heh...I believe it was "C#" I was trying to think of...

So, that brings up a question of trends: Will the use of "C" eventually fade out...in favor of the newer "C++"...or does the more recent language not really apply to the MUD world?

[Yui Unifex]

I can only speculate, but I believe existing codebases are going to continue on with C. Most of the newer codebases that I see in development are done in C++, with some in Java and other languages. So it then becomes a question of whether or not the newer codebases will surpass the older ones, and I lack the clairvoyance to know that =). But C++ codebases will definately become more common I predict.

It is probably a good idea for you to start with C anyway, because C++ is very similar and will even compile most C code. There are also several C codebases to use as a reference point (although you should be careful about learning habits from them, as they are rather poorly designed). C is also much less complex than C++, so there are fewer areas to get confused about when you're starting out.

C++ is not more complex then C imho. However, because it is an object-orientated programming language, it is definitely allot more abstract and harder to grasp because of it. Still though, if you try the basic of C first, C++ will be a piece of cake because some possibilities in C look quite alike objects in C++ (structs anyone?)

As for which language will fade out, neither of them I believe. C is being used as the standard language for Unix and Unix-like operating systems and C++ is more or less a "standard" language used for various reasons/applications. I don't know about speed differences among C and C++, but both are definitely faster then Java, because Java is basically a souped up scripting language instead of a programming language.

As for compilers, which can be tricky to find, look around on the net for Borland C++ Builder version 3.1. It's good, easy and not all that complicated. DOS based though, so be prepared to work in a 25x40 res with 32 diff colours if you want to use it. It's quite easy to use, does the job, even though it is not so much very legal to find and download.

[KaVir]

Originally Posted by C++ is not more complex then C imho.

C is a relatively simple language (although it still requires a lot of time and effort to learn to use it effectively), while C++ adds a significant amount of complexity.

Originally Posted by However, because it is an object-orientated programming language,

C++ is not an Object Oriented programming language. It is a multi-paradigm programming language that supports OO, as well as other styles of programming. It requires a lot more effort to write OO software in C.

Originally Posted by Still though, if you try the basic of C first, C++ will be a piece of cake

Not true - I have encountered several people who had only learned C++, and they all did extremely poorly when it came to C interview questions (particularly with things like strings).

Regarding which language to learn: If you're only interested in learning so that you can write mud snippets, then I would agree with Unifex and suggest C. In fact I use several (of my own) C snippets in my own C++ codebase - I just encapsulate them in a namespace - even though they were originally designed to work on muds written in C.

[angelbob]

If you're just learning a first language, C is a much better choice than C++. The poster who said that C++ isn't more complex than C has obviously never had to tackle virtual inheritance, virtual functions with multiple inheritance, problems with dynamic casting and typecasts changing pointer values, operator overloading...

C++ takes C as a starting point and adds a huge amount of new stuff. It's more complex. Seriously. It contains all of C as a (small) subset. How can it *not* be more complex?

You can get away with using fewer of the complicated, nasty C++ features if you only use your own code. But if you ever plan to have another coder on your MUD (you do, right?) you'll have to deal with them. And while everybody seems to agree that C++ is a combination of okay stuff and gross, horrible hacks, nobody seems to agree about which is which. So he'll be using some stuff you consider to be gross, horrible hacks.

I believe that C is the clean part of C++, and almost all of the rest is made of gross, horrible hacks :-)

[Lindahl]

angelbob-

Which would you consider cleaner?
----------------------------------------
class IntObject
{
IntObject &operator +=(int val)
{_val += val; return *this;}

operator int( )
{return _val;}

int _val;
};

IntObject i;
int v = i += 3;
-------------------------------
Or?

struct IntObject
{int _val;};

IntObject *PlusEqual( IntObject *i, int val)
{i->_val += val;}

int Value( IntObject *i)
{return i->_val;}

IntObject i;
int v = Value(PlusEqual(&i, 3));
----------------------------------

To me, the C++ version (first version) is a lot cleaner and more intuitive.

I'd have to say that the design details of a program determine which language produces cleaner code (mainly whether the problem is more naturally described as objects (C++), or proceedures ©).

In the case of a MUD, the design is CLEARLY object-oriented (Server, Connection, Player, Character, Object, Room, Area). Thus, using a language that has object-oriented capabilities would most likely produce the cleanest code.

I'm guessing that you confused the cleanliness of a piece of code with complexity of a language.

[angelbob]

First, I note that you're using a complex structure where you should be using an int. Passing a pointer to a structure with a single int makes for ugly C, passing a reference to a structure with an int makes for ugly C++, and passing an int around is pretty clean -- and identical in either language. But I'd say both are quite ugly, and both are about equally ugly, but it's very slightly more obvious what the C version is doing.

Second, by talking about how MUDs are an obvious place to use object-oriented programming I'm assuming you're talking about the objects themselves (like, "physical" in-game objects). I'm with the Skotos folks on this -- data inheritance is appropriate, code inheritance not so much so. Code inheritance is the only kind that C++ provides.

Third, if you're talking about inheritance in the "physical" in-game objects, then you're talking about doing it dynamically if you have any OLC facilities. Any modern MUD does. Unless you recompile on the fly (like DGD does -- I'm actually serious, although C++ isn't a good language for this, nor is C), you're going to have to build your own stuff. So you're back to implementing all your own data inheritance.

I agree that there are a couple of specific instances where C++'s version of OO is cleaner than doing the same thing in C. User interface code (windowing and whatnot) is the only place I've seen where it's consistently true. And yet GTK+, the windowing toolkit for GNOME, uses C instead of C++. Why? Because C++ is incompatible between compilers, doesn't link object code between multiple compilers, has the usual fragile base class problems and can't inherit and runtime. The fully inheritance-based solution used by GTK+ is done in C and built out of macros. Unlike the C++ solution, it links to a variety of languages, allows implementation of new widgets in a variety of languages, doesn't require RTTI (which doesn't link between different C++ compilers) and works quite happily if you add new stuff at runtime.

Fourth: your C solution above is attempting to do operator overloading in C. That's its primary problem. You can do what you're doing relatively cleanly in C, but you can't make it look like C++. Why would you want it to look like C++?

[angelbob]

Here, lemme make it clearer what I mean about the "using a complex structure instead of an int" and "make it look like C++" bits.

Your example could be less trivial -- vectors and matrices are the cleanest example I know of in C++, and the best example of why operator overloading might not suck. Every other example that I know of is thoroughly horrible, and I absolutely include "cin" and "cout" in that. I mean, c'mon, they're using bit-shift operators for input and output. How clean and intuitive is *that*?

It's hard in C and ugly in C++ to pass big complex structures around as though they were regular builtin data types. That's pretty much what you're doing above. You can do the same with matrices and define addition, multiplication and (with some stretching) things like inner products, inversion and solving. Of course, nobody but you will ever guess your operators on the first try for anything except addition and multiplication, and they'll need to check your documentation to see if you're doing real matrix multiplication or just going element-by-element.

So instead of something big and nasty and C-like like this:

Matrix *A,*B,*C;

A = MatrixInit(7,7);
MatrixFileLoad(A, "mydatafile.dat");
B = MatrixInit(7,9);
MatrixFileLoad(B,"myotherdata.dat");
C = MatrixInit(7,9);
MatrixMultiply(C, A, B);

You can instead have something smaller and C++-y like this:

Matrix A(7,7), B(7,9);

A.FileLoad("mydatafile.dat");
B.FileLoad("myotherdata.dat");
C = A * B;

Cleaner, smaller, and not much slower if you do it right. The bit of slowness added is because you'll be copying C after that matrix multiply with its copy constructor. You could avoid even that if your compiler is really clever (it's not -- check the code if you use GCC, or the execution time if you use VC++), and the stack space hit doesn't matter in this day and age, at least for MUDs. I used to work for Palm, I notice these things. Anyway.

I'll mention in passing that the library implementing this stuff will be much nastier in C++ than in C. But you could point out that you only write the library once and you write code with it many times. You'd be right. Of course, you maintain the library and deal with bugfixes constantly, and the C++ version does a lot more under the covers. For instance, if you had a bug in the copy constructor or one of the operators in the C++ version (for instance -- does A *= B work? Maybe...) you'll have a much nastier time tracking them down and finding all the functions that are called. I'd say a good debugger would help you, but GDB and VC++ both have serious issues with a lot of very standard C++, let alone godawful things like most proprietary Unix debuggers.

You can say "but I'd write the library right' or "but I'd debug and test it well". You'd probably be right. Good for you. Now, are you the only one working on your project? I've seen a lot of very bad C++ with very hard-to-find bugs. Much more so even than C, especially if I can use a tool like Purify on both.

[enigma@zebedee]

If planning to code on an LP Mud (or any older mud) then I recommend C as C++ and C# both have significent differences. A lot depends on the mud you want to code on though - I recommend finding and playing the mud before you decide to code for it. Once you know that then the admin there will be able to tell you what language they are using.

Certainly on Zeb we don't let people become coders until they have played the game (the usual rule being at least one character to legend level) and we feel that they are ready for the responsibility.

As a side note C# is basically microsofts bastard cross-breading of C++ and Java. It has some nice features but I don't see it being used much for muds in the immediate future - although I am using it a lot at work.

[Yui Unifex]

Originally Posted by (angelbob @ foo) First, I note that you're using a complex structure where you should be using an int.

I think that much is obvious, but if there were added functionality I'm not so sure that this would be a great idea. If the IntObject were something like CheckedIntObject, which checked assigned values against a valid range and threw an exception when something went out of bounds, it would be a great deal more intuitive and easily extendable with C++ -- after all, it would react exactly like an int, save for the operations one specifies, which makes it easy to typedef and modify if some logic changes.

Originally Posted by (angelbob @ bar) Second, by talking about how MUDs are an obvious place to use object-oriented programming I'm assuming you're talking about the objects themselves (like, "physical" in-game objects). I'm with the Skotos folks on this -- data inheritance is appropriate, code inheritance not so much so. Code inheritance is the only kind that C++ provides.

The objects he mentioned were "Server, Connection, Player, Character, Object, Room, Area". Three of those are not physical objects (Server, Connection, and Player, I think), and depending on the design, physical transformations between the other three may not exist. So data inheritence in that sense is useless because the types do not share data. Since you've stated that you're talking about in-game objects, inheriting data is as easy as writing a copy constructor. I don't think that something so simple needs specific language support. But C will have just as many problems as C++ here -- do you do deep or shallow 'inheritance', and what functions provide it? With C++ you can do deep copying automatically in the copy constructor; this is something that would take one extra step in C, never mind the fact that you'd lose pass-by-value semantics due to the lack of a destructor. IMO, "string" objects are very clearly superior to char * memory pointers because of this.

Originally Posted by (angelbob @ baz) Fourth: your C solution above is attempting to do operator overloading in C. That's its primary problem. You can do what you're doing relatively cleanly in C, but you can't make it look like C++.

Correct -- you would lose functionality because it can't look like C++:
[code] typedef mytype int;
void dosomething (mytype &m) { m = 5; }[/quote]
When that typedef is changed to IntObject (or something more functional, like my above CheckedIntObject), you would have to go back and insert functions to perform all of the assignments.

Originally Posted by (angelbob @ foo) Your example could be less trivial -- vectors and matrices are the cleanest example I know of in C++, and the best example of why operator overloading might not suck.

Not just this, but for templated functions that depend on certain operations working across the board with user-defined as well as built-in types, operator overloading is essential. STL algorithms work on all sorts of types because of this, and it's another thing that C can't achieve.

Originally Posted by (angelbob @ bar) Of course, nobody but you will ever guess your operators on the first try for anything except addition and multiplication, and they'll need to check your documentation to see if you're doing real matrix multiplication or just going element-by-element.

I don't think they'd need to guess -- you would simply overload operator* to handle both matrix and scalar multiplication, so the operations would flow as they do in mathematics; the operations would be type dependant just as they are in the problem domain.

[angelbob]

(Quotes here are from Yui Unifex)

Originally Posted by If the IntObject were something like CheckedIntObject, which checked assigned values against a valid range and threw an exception when something went out of bounds, it would be a great deal more intuitive and easily extendable with C++ -- after all, it would react exactly like an int, save for the operations one specifies, which makes it easy to typedef and modify if some logic changes.

This is true, and I've seen some impressive similar stuff done with using pointers for transparent reference counting. It's pretty nifty as long as no bug ever exists in it (hint -- check every implementation of pointers for refcounting that you use... When reassigning, do they increment the new reference count BEFORE decrementing the old one?).
Of course, if a bug ever happens that doesn't crash your code, you have to debug it. I'm a big fan of knowing when functions are called. C++ experts can generally tell you the order of function calls in, say, this:

C *= myType(9,4,"bob")

It definitely gets hard to follow, though, especially if (in the example above) you haven't defined your own *= operator and C++ has to wing it. It will, in fact, do so, but the choices it makes for this and for typecasting aren't always intuitive, and a lot of stuff (like typecasting) happens silently in conditions that are just weird.

That doesn't address your point, though. Your point is that C++ will fake a builtin data type and make it call arbitrary other functions silently to an extent that C won't.
Yep. You're right. And it's a massive debugging headache that it'll do so.
Perl does this "right", too. Perl is the only language I know with a worse reputation for syntactic and semantic cleanliness than C++. Coincidence?

Originally Posted by The objects he mentioned were "Server, Connection, Player, Character, Object, Room, Area". Three of those are not physical objects

Fair enough. I'd argue that not much inheritance is appropriate for Server, Connection and Player objects -- there usually aren't very many kinds of them. But you're right, they're not physical.

Originally Posted by Since you've stated that you're talking about in-game objects, inheriting data is as easy as writing a copy constructor.

Well, sort of. That doesn't change them if the parent changes, which is my favorite use for data inheritance -- a tree of archetype objects. Skotos' ur-objects are an example of this. Anyway, back to C++.

Originally Posted by But C will have just as many problems as C++ here

Yes. Either one will have to build its own inheritance, effectively. It's just that the C++ people will yell at you for not using the built-in language inheritance and then stonewall when you ask "so what do I do about inheriting at runtime?" :-)

But seriously -- true. I still argue that C++'s extra complexity isn't generally worth the benefit in any environment with more than one coder. When you say that C and C++ break down to the same thing for a given problem, I argue that that supports my argument. They wind up using essentially the same methods to deal with the problem, but C++ has all the extra nastiness you're not using at the moment.

But somebody else on the project may be, and it's allowed to mess you up.

Originally Posted by With C++ you can do deep copying automatically in the copy constructor; this is something that would take one extra step in C, never mind the fact that you'd lose pass-by-value semantics due to the lack of a destructor.

Actually you'd just need an explicit function call rather than implicit one, or a function that copies and passes it back (which is the same thing, basically). But you're right, it wouldn't happen automatically, which can definitely be irritating at times.

Originally Posted by IMO, "string" objects are very clearly superior to char * memory pointers because of this.

I won't argue with you over this one. String should probably have been built into C long ago. Of course, it should also have been built into C++ (or at least the standard library) long ago, and that hasn't happened either.

Originally Posted by Correct -- you would lose functionality because it can't look like C++: Code Sample typedef mytype int; void dosomething (mytype &m) { m = 5; }

Clever. By calling this "lose functionality" you skip over the fact that it's just syntactic sugar. Nonetheless: it's just syntactic sugar. C++ used to be implemented with a preprocessor over C, and you know, it wasn't even a very complicated preprocessor. Big, but not complicated.

Originally Posted by When that typedef is changed to IntObject (or something more functional, like my above CheckedIntObject), you would have to go back and insert functions to perform all of the assignments.

And to get the speed of an unchecked int you'd have to add an extra function call for unchecked assignments and go through the headache of remembering which you're using. Plus, you can detect errors if you get a problem in a function call. How do you detect an error in the middle of "equals"?

Originally Posted by (...I said something about vectors and matrices...) Not just this, but for templated functions that depend on certain operations working across the board with user-defined as well as built-in types, operator overloading is essential. STL algorithms work on all sorts of types because of this, and it's another thing that C can't achieve.

That's true. That's another thing C can't achieve. Looking at the implementation of templates, I frequently sigh in relief that C can't "achieve" that. While this is probably relatively clean with your "checked int" example (when's the last time you genuinely used one of those, BTW?), I'd argue that it's fundamentally backwards to do the same thing with vectors, matrices, or anything where using "+" or "*" is a stretch for the operator involved. It makes for clever, small code (and massive binary size since you're using templates) but you're fundamentally applying very different concepts to a different set of objects using the same syntax. Urgh.

Originally Posted by I don't think they'd need to guess -- you would simply overload operator* to handle both matrix and scalar multiplication, so the operations would flow as they do in mathematics; the operations would be type dependant just as they are in the problem domain.

That's only true in cases where the problem domain is well-defined and well-documented, and already defines + and * unambiguously. There are two ways to multiply a pair of 4x4 matrices -- only one is written as multiplication by actual mathematicians, though they don't actually bother to put a star. In fact, if they *do* put a star it frequently means they're talking about inner product, which is a very different operation.

But for most things, it's a lot less obvious what + or * represent. Using operator overloading for math is reasonably clean. The vast majority of the time it's not used for math.

For instance, have you noticed that cin and cout use the bit-shift operators? Eeeeeeewwwww! And that's just in the standard library! You could argue that it sorta makes sense ("look, they're little arrows. Kinda. And arrows mean input and output. Kinda. And we didn't allow overriding the actual arrow, plus it doesn't come in reverse flavor."). But if you did, I'd laugh at you.

I've found that's a better example of the way people choose and overload operators in the real world, which is why I don't touch other people's C++ code any more. There's one exception, but Tom's even pickier than I am about this stuff and he rewrites everything three times to get a clean design.

[Yui Unifex]

Originally Posted by (angelbob @ foo) That doesn't address your point, though. Your point is that C++ will fake a builtin data type and make it call arbitrary other functions silently to an extent that C won't. Yep. You're right. And it's a massive debugging headache that it'll do so.

I don't seem to have any troubles with it. gdb treats user-defined operators the same as other functions. (more on this below)

Originally Posted by (angelbob @ bar) Well, sort of. That doesn't change them if the parent changes, which is my favorite use for data inheritance -- a tree of archetype objects. Skotos' ur-objects are an example of this.

Not sure what you mean here. In code, copy constructors cascade parent copy constructors down the line. If it's in-game data that's dealt with via an encapsulated datatype, the copy constructor should handle copying it.

Originally Posted by (angelbob @ baz) Actually you'd just need an explicit function call rather than implicit one, or a function that copies and passes it back (which is the same thing, basically).

Right -- it's an extra step in userspace.

Originally Posted by (Yui Unifex @ foo) Correct -- you would lose functionality because it can't look like C++: Code Sample typedef mytype int; void dosomething (mytype &m) { m = 5; }

Originally Posted by (angelbob @ foo) Clever. By calling this "lose functionality" you skip over the fact that it's just syntactic sugar. Nonetheless: it's just syntactic sugar.

No, it's a legitimate concern. I can write a library of code using these templates (supposing for the moment that C had templates) and never have to worry about the user being able use it with built-in types as well as user-define types. This bit of "syntactic sugar" is very important in reducing the amount of duplicated code and thus errors.

Originally Posted by (Yui Unifex @ bar) When that typedef is changed to IntObject (or something more functional, like my above CheckedIntObject), you would have to go back and insert functions to perform all of the assignments.

Originally Posted by (angelbob @ bar) And to get the speed of an unchecked int you'd have to add an extra function call for unchecked assignments and go through the headache of remembering which you're using.

I'm sorry? To get the speed of an unchecked int you would use an unchecked int as the template argument. The "headache of remembering what you're using" can be easily alleviated by a quick dosage of glancing up at your variable declarations =).

Originally Posted by (angelbob @ baz) How do you detect an error in the middle of "equals"?

Use a debugger =). (From above) gdb allows debugging of operator=() just as it does an equals() function. So long as one remembers that operators can be overloaded and assert their assumptions, everything should be fine.

Originally Posted by (angelbob @ foo) I'd argue that it's fundamentally backwards to do the same thing with vectors, matrices, or anything where using "+" or "*" is a stretch for the operator involved.

Oh indeed -- if the operation is not clear then they should be renamed to alleviate this problem. This applies to both overloaded operators and function names, of course =).

Originally Posted by (angelbob @ bar) While this is probably relatively clean with your "checked int" example (when's the last time you genuinely used one of those, BTW?)

Just recently, that's why it popped in my mind =). I was just writing a spacial system module where my coordinate-types are templated. However I was having a problem with my movement setting my coordinates out of the bounds of the node in which I was currently located. A quick CheckedFloat object thrown into the template for my coord (which normally uses regular floats) and I was able to find the problem in a few minutes.

Originally Posted by (angelbob @ baz) There are two ways to multiply a pair of 4x4 matrices -- only one is written as multiplication by actual mathematicians, though they don't actually bother to put a star. In fact, if they *do* put a star it frequently means they're talking about inner product, which is a very different operation.

IMO, it should match the way the problem domain works as closely as possible. If it's not possible to match the problem domain, then making up an operator is as you say, likely to cause pain. But this isn't a problem with operator overloading, this is a problem of the discipline of the coder. To argue that C++ or even Perl facilitates undisciplined coding is disingenious because one could easily apply those arguments as reasoning for why everybody should use VB.

Originally Posted by (angelbob @ foo) But for most things, it's a lot less obvious what + or * represent. Using operator overloading for math is reasonably clean. The vast majority of the time it's not used for math.

You don't have to use it for operations you don't embrace =). If someone on your project uses it against your will then that's an issue that you two need to handle, not a programming language designer. A document on coding standards is important for large projects, and if it's a point of ire for developers then things should be clarified in this document, rather than spoiling the broth by restricting the entire language. This is a big complaint I have about Java.

Originally Posted by (angelbob @ bar) For instance, have you noticed that cin and cout use the bit-shift operators? Eeeeeeewwwww!

<grins> The methods I've seen for doing that kind of output have been:
+ operator (Supported by C++)
& operator (VB)
. operator (PHP)
<< operator (C++)

What operator or method (if it's not using operators) would you suggest be used for stream input?