Well, the question isn't so much is it possible, the question is really whether or not it's worth it. I wouldn't do it myself, but then again I'm also very happy with my Linux development environment.

I don't know of big downsides to running on a Windows box, although there are issues with things like copyover etc. To be honest I haven't really done it or even thought of it much, because as I said above I'm very comfortable on Linux. :smile:

Yeah, i was afraid someone might say that. :cry:

But, maybe i'll try to figure out how to do it. So if i get it going i'll upload it for anyone that
prefers a window's IDE.

So, what i really want is a clean G++ codebase that includes OLC and colour.
I see that SMAUG has allot of cool stuff, but i cant find one that is ready for G++.

SmaugFUSS compiles with g++.

Really? I saw SmaugFUSS 1.9 compiles in gcc 4+ but thats totally great!

I tried getting QuickMUD to compile in G++ but it was one thing after another. I suppose it would be a good learning experience, but eh, i would rather learn by actually developing.

Thanks again.

Yup, I just downloaded the most recent 1.9 release and its compiler is set to g++. I was pretty sure that this was the case, because I was the one who submitted the patch for the const fix. :tongue:

Actually, it's not really a good learning experience, to be honest. Dealing with this stuff is dealing with lots of technicalities and details, and besides it's easy to subtly shoot yourself in the foot if you're not careful.

Yeah, i agree about the shooting yourself in the foot thing!
I pretty much would comment out one thing and then realize that
that caused 100 more errors. YUCK! :stare:

Anyway, David, I noticed a post about SmaugFuss with Lua integration.
What ever came of that? I know you said you would do it if it was worth doing,
I think that would be awesome. Of course, you probably dont have time to help
one guy out, but maybe you could steer me in the right direction?

I've been playing with Lua integration on my MUD for a while now, and when I'm satisfied with it I would be happy to add it to FUSS as well. Currently it works fairly well actually; I can implement commands in Lua and even do fun things with coroutines like a command "pausing" until you give it more input.

E.g.

> issue create
You need a category; pick one: a b c d
> a
You need a name; please enter it:
> foobar
…

The command is implemented very simply; along the lines of:

function cmd_issue_create(actor, args)
  actor:sendText("You need a category: ")
  local category = WaitForInput(actor)
  actor:sendText("You need a name: ")
  local name = WaitForInput(actor)
end

where WaitForInput takes care of doing things like pausing the coroutine etc.

Without coroutines, this kind of "command pausing" is very nasty to implement and involves all kinds of fun things like substates and so forth. It makes it difficult to follow the logic of the code. As you can see above, this scheme maintains the linearity of the code, which makes it far easier to follow what's going on.

Thats really cool man.
Look forward to the addition if it happens.

real quick, i've noticed that C++ uses const char instead of just char,
well as far as sending a char into a function anyway. Am i correct in thinking that this is done this way because the variable within the function is on the stack? and in that scope constant? Just a little confusing.

In general, if a function is not going to modify a parameter, it should always be passed as constant. It is not only a documentation of intent (which is useful to people trying to understand a function) but also an enforced behavior (which is useful to prevent accidental mistakes).

With correct constness on parameters, you can immediately know which parameters are input and which are output. For example,

memcpy(void* s1, const void* s2, size_t n)

With clearer argument names, like src and dst, it would be obvious which is which. But it's also obvious due to the constness. You can't write something into a const parameter, so the first parameter is necessarily the place you copy into, which makes the second parameter the place you copy from.


Sometimes you don't have a choice about constness. String literals are an example of this:
const char* s = "abc"
Because "abc" is a string literal, the memory is constant. Trying to write to a literal can cause a segmentation fault. There are reasons for why this is; for instance, when you have several copies of a program running, they can share constant memory. If one program were to edit that memory, and everybody is sharing it, they would have mysteriously changing values. (Some operating systems allow this in some circumstances, and on write, copy the memory pages and fiddle with the process's virtual memory table.)


Now, it's not that C++ uses const char* where C doesn't. C could use const char* as well, it's just that for various reasons a lot of code doesn't, and earlier compiler versions did not enforce it. g++ since version 4.something (4.1? maybe even 4.0…) is very strict about const correctness: it will complain if you try to use a const thing as non-const.

The constness doesn't have to do with things being on the stack or not. You can have something on the stack that is const or not const.

void f() {
  char str[100];
  strcpy(str, "abc");
  const char str2[100];
  strcpy(str2, "abc"); // <– error, const violation
  const char* str3 = "abc";
}

All three strings are on the stack, although in the last case it is technically the pointer that is on the stack, with the string characters living in the process's data segment. (Processes have three segments to their memory: the code segment, the data segment, and then all the rest, basically a combination of the stack and the heap.)

Ok, thanks for clarification on the 'const' stuff :smirk:

extern MOB_INDEX_DATA * mob_index_hash [MAX_KEY_HASH];
extern OBJ_INDEX_DATA * obj_index_hash [MAX_KEY_HASH];
extern ROOM_INDEX_DATA * room_index_hash [MAX_KEY_HASH];

This is in merc.h
Am i correct in that hash tables are used instead of linked lists because the key is the vnum?
I know its a newbie dumb question, but I just want to be sure.

An array of link lists is used. The array index, a hash of the vnum.

Hash tables are used because hashes are way faster. Linked lists require a linear search. So if you have 100,000 rooms and the room you want is at the end, a linked list would require you to search through 100,000 rooms to find the one you want. A hash can be as fast as a single lookup, depending on specifics of implementation. An array would be faster still, but those are poor choices for this use case because you might have a 200 rooms but have one room with vnum 1,000,000 and that would require an array 1,000,000 elements long (which would be 4MB of mostly unused memory on a 32-bit system).

In general, if you have a list that you need to search, a linked list is totally the wrong data structure to use. New programmers (and lazy programmers) tend to overuse them because they're the easiest dynamic list to write and use in C. Hash tables and trees and relatively complex to implement, and it's difficult to understand why you'd even want to use them (and which to use when) without a solid education in computer science.

Ahh, I gotcha.
So, an array of linked lists in this case is that each element in the hash is a list?
I dont really understand that, when it says mob_index, does that mean each element
has a list of mobs? if so that would make sense. (To Me :stare:)

It means that the hash table is implemented as an array of hash buckets. When you want to find out where a given element would live in the hash table, you run it through the hash function, giving you a bucket number. Everything in the bucket is stored in the linked list associated with the bucket.

So yes, each bucket has a list of zero or more MOB_INDEX_DATA pointers, except that the list is implemented as part of the MOB_INDEX_DATA structure instead of an actual linked list node (this way of using linked lists kind of drives me nuts, but that's life).

Thank you elanthis, I appreciate you bringing up all those details, but I couldn't help be wonder why you added this last part? I imagine you were speaking in general terms, but by solid education are you referring to a college degree? If so, I agree it makes it more difficult, but I am tenacious and wont stop learning! :tongue: And after your concise explanation, it makes total sense.

Not to put words in his mouth, but I think his point is that, in general, choosing appropriate data structures and implementing them is not easy, and requires a somewhat sophisticated understanding of other parts of computer science (basic algorithms analysis, complexity analysis (kind of the same thing), asymptotic vs. constant-time performance, etc.). A college degree would get you this understanding.

Ahh, i gotcha.
Well, i'm hopefully going to start this year.
So, i'm looking forward to all that good stuff :grinning:

For what it's worth, I've never taken a Computer Science course in my life. Tons of classes in other computer fields, but not CS. You certainly can learn those things on your own, you just have to be prepared to read a lot of very, very, very dry math and CS texts… just for fun. I was a very bored kid, apparently. These days I won't read anything that doesn't involve things blowing up or getting chopped in half. (Hence my reading of a lot of very, very, very dry astronomical texts and martial arts manuals. I'm a very bored adult, apparently.)

What kind of "computer fields" are you referring to outside of computer science? Where I went to school there was no distinction; it was just "computer science" (e.g., no compsci vs. compeng vs. compprog vs. etc.)